CSRF в мобільній розробці: суть, типи атак та методи захисту

Що таке CSRF-атака?

CSRF (Cross-Site Request Forgery) — це атака, при якій зловмисник створює підроблений запит і змушує браузер жертви надіслати його на цільовий сервер. Сервер виконує запит, оскільки отримує валідні cookie-облікові дані поточної сесії користувача. Атака можлива, оскільки браузер автоматично додає кукі до кожного запиту на цільовий домен, незалежно від того, з якої сторінки було надіслано запит. Користувач може навіть не бачити сторінку зловмисника — достатньо завантажити прихований <img>, <form> або <iframe> зі шкідливим URL. CSRF не викрадає дані безпосередньо — атака виконує дії від імені жертви (state-changing operations), такі як переказ коштів, зміна пароля або видалення акаунта.

Які операції найбільш уразливі?

CSRF-атаки спрямовані виключно на операції, що змінюють стан — GET-запити з побічними ефектами, POST, PUT та DELETE. Наприклад, запит на зміну електронної адреси в особистому кабінеті: якщо сервер приймає запит без перевірки походження, зловмисник може підставити свою пошту та ініціювати скидання пароля. Атака особливо небезпечна для банківських систем, панелей адміністратора та соціальних мереж, де одна дія має серйозні наслідки. API мобільних додатків, що використовують кукі для аутентифікації, також схильні до CSRF, якщо не застосовують додаткові перевірки.

Хто в зоні ризику?

Під атаку потрапляють будь-які веб-додатки та API, де аутентифікація заснована на cookie, а сервер не перевіряє походження запиту. Мобільні додатки, що використовують WebView для авторизації через веб-форми, також уразливі: браузерний компонент автоматично відправляє кукі, і зловмисник може внести шкідливий запит через фонове завантаження. За даними HackerOne (2025), близько 12% усіх звітів про уразливості у веб-додатках пов'язані з відсутністю захисту від CSRF.

Що робить CSRF небезпечним?

Головна особливість CSRF — непомітність для жертви. Користувач може навіть не підозрювати, що атака відбулася: підроблений запит виконується у фоновому режимі, а інтерфейс додатка не показує ознак зламу. Єдиний спосіб виявити CSRF — моніторинг серверних логів або раптові зміни в обліковому записі. Крім того, CSRF легко комбінується з іншими уразливостями, такими як XSS або відкриті перенаправлення, що багаторазово підсилює шкоду.

Як працює CSRF-атака?

CSRF-атака складається з трьох обов'язкових умов: жертва авторизована на цільовому сайті, сервер використовує cookie-аутентифікацію, а запит зловмисника направлений на action-URL. Зловмисник створює HTML-сторінку з формою, скриптом або зображенням, чий атрибут src вказує на цільовий URL. Браузер жертви завантажує цю сторінку і автоматично надсилає запит на сервер разом із cookie поточної сесії. Сервер отримує валідні кукі, не перевіряє джерело запиту і виконує операцію.

<!-- Пример CSRF-атаки через скрытую форму -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Після завантаження сторінки скрипт негайно надсилає форму. Браузер прикріплює cookie сесії користувача до POST-запиту на bank.example.com. Сервер банку перевіряє кукі, переконується, що користувач автентифікований, і виконує переказ на рахунок зловмисника. Жертва бачить порожню або легітимну сторінку, а кошти вже списані.

Роль браузера в CSRF

Ключова особливість протоколу HTTP — відсутність вбудованої перевірки джерела запиту. Браузер додає кукі до запиту, якщо домен запиту збігається з доменом кукі. Зловмиснику не потрібно знати вміст кукі — браузер робить це автоматично. Same-origin policy не захищає від CSRF, оскільки атака направлена на сервер, а не на читання відповіді. Механізми на кшталт CORS також безсильні: CSRF-запити зазвичай не потребують читання відповіді, щоб завдати шкоди.

Основні типи CSRF-атак

CSRF-атаки класифікуються за способом доставки шкідливого запиту. Кожен тип використовує різний HTML-елемент для надсилання запиту, але всі покладаються на автоматичне відправлення cookie браузером. Вибір методу залежить від цілей атакуючого: GET-based атаки потребують менше коду, POST-based надійніше обходять деякі захисти, а XMLHttpRequest-based дозволяють маніпулювати заголовками.

GET-based CSRF

Найпростіший метод: зловмисник розміщує на сторінці <img> з URL, що містить параметри запиту. Браузер завантажує зображення і надсилає GET-запит на сервер. Наприклад, <img src="https://api.example.com/delete?postId=123" /> видаляє запис, якщо сервер обробляє DELETE через GET. Незважаючи на очевидну небезпеку, деякі API досі використовують GET для операцій видалення або оновлення.

POST-based CSRF

Якщо сервер приймає тільки POST-запити, зловмисник створює приховану форму з методом POST і автоматично надсилає її через JavaScript. Форма не відображається на екрані (всі <input> мають type="hidden"), а autofocus + .submit() спрацьовує без кліку користувача. POST-based атаки не працюють, якщо сервер перевіряє заголовок Content-Type, але більшість API приймають стандартний application/x-www-form-urlencoded.

XHR-based CSRF (з CORS)

XMLHttpRequest або Fetch API дозволяють надсилати запити з довільними заголовками. Якщо сервер налаштував CORS надто широко (Access-Control-Allow-Origin: *), зловмисник може надіслати будь-який запит і прочитати відповідь. Однак для CSRF-атаки читання відповіді не обов'язкове — достатньо виконати дію. Сучасні браузери надсилають preflight-запит OPTIONS перед нестандартними запитами, що може заблокувати XHR-based CSRF, якщо сервер правильно налаштований.

CSRF в мобільних додатках

Мобільні додатки менш уразливі до CSRF, ніж веб-сайти, оскільки нативні додатки рідко використовують cookie-аутентифікацію. Натомість мобільні API частіше застосовують токени в заголовку Authorization (Bearer-токени, JWT). Однак є сценарії, де CSRF-атака можлива: WebView з веб-логіном, гібридні додатки та API з cookie-based сесіями. За даними TechCrunch (2025), близько 18% публічних API мобільних додатків все ще підтримують сесійні кукі.

CSRF через WebView

Багато додатків відкривають веб-сторінки в WebView — авторизацію через OAuth, платіжні форми, перегляд контенту. WebView — це повноцінний браузер всередині додатка, який зберігає сесійні кукі. Якщо зловмисник знаходить спосіб завантажити свій URL в WebView (через відкрите перенаправлення або Deep Link), він може виконати CSRF-атаку точно так само, як у звичайному браузері. Захист — використання Chrome Custom Tabs або SFSafariViewController замість WebView для критичних операцій.

CSRF в API з JWT-аутентифікацією

JWT-токени зазвичай зберігаються в localStorage або в пам'яті додатка і не відправляються автоматично — розробник явно додає заголовок Authorization до кожного запиту. Це робить класичну CSRF-атаку неможливою. Однак якщо додаток зберігає JWT в cookie (що рідкість, але трапляється), ризик повертається. Додатковий захист — прив'язка JWT до конкретного origin запиту через claim azp або aud, що запобігає використанню токена на іншому домені.

// Приклад серверної перевірки CSRF-токена в Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Генерація CSRF-токена при логіні
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Методи захисту від CSRF

Сучасний захист від CSRF базується на трьох рівнях: серверні CSRF-токени, атрибут SameSite для cookie та перевірка заголовка Origin. Комбінація цих методів забезпечує захист від 99% CSRF-атак без істотного впливу на UX. Вибір конкретного підходу залежить від архітектури додатка: веб-сайту достатньо SameSite=Lax, API мобільного додатка потребує токенів у заголовках.

CSRF-токени (синхронізатор)

Стандартний метод: сервер генерує унікальний токен, прив'язує його до сесії користувача і передає клієнту. Клієнт включає токен у кожен запит, що змінює стан (у прихованому полі форми або заголовку X-CSRF-Token). Сервер звіряє отриманий токен з тим, що зберігається в сесії. Токен має бути криптостійким, випадковим, довжиною не менше 32 байт і змінюватися при кожній сесії або операції. Термін життя токена — не більше кількох годин.

SameSite Cookie

Атрибут SameSite для кукі обмежує відправлення кукі при крос-доменних запитах. Значення Lax дозволяє відправлення кукі тільки для навігаційних GET-запитів верхнього рівня — цього достатньо для більшості сайтів. Strict блокує кукі для всіх крос-доменних запитів, включаючи навігацію: користувачеві доведеться заново авторизуватися при переході з іншого сайту. За даними Chrome Platform Status (2026), SameSite=Lax за замовчуванням ввімкнений у всіх сучасних браузерах, що знизило кількість CSRF-атак на 67%.

Перевірка Origin та Referer

Сервер може перевіряти заголовки Origin або Referer вхідного запиту. Якщо запит прийшов з іншого домену — він блокується. Origin надійніший за Referer, оскільки завжди присутній у POST-запитах і не відключається політиками браузера. Реалізація: білий список дозволених origins, порівняння з поточним значенням заголовка. Метод ефективний, але складний з мобільними додатками, де заголовки Origin можуть бути відсутні або підроблятися.

// Приклад перевірки CSRF-токена в Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Метод, що не потребує зберігання токена на сервері: сервер встановлює cookie з випадковим значенням, клієнт читає значення з cookie і надсилає його назад у заголовку або тілі запиту. Сервер порівнює обидва значення. Якщо зловмисник не може читати cookie (Same-origin policy), він не зможе підробити токен. Метод простіший у реалізації, ніж синхронізатор, але вимагає HTTPS для захисту cookie від перехоплення.

• CSRF-токени — золотий стандарт: надійні, перевірені часом, підтримуються всіма фреймворками
• SameSite=Lax — мінімальний захист для веб-додатків: безкоштовно, автоматично, не потребує коду
• Перевірка Origin — додатковий рівень: блокує атаки до перевірки токена
• Double Submit — для REST API без server-side сесій: ефективний на HTTPS
• Кастомні заголовки — X-Requested-With: XMLHttpRequest блокує прості CSRF-форми

Відмінність між CSRF та XSS

CSRF та XSS — різні типи атак, які часто плутають. CSRF експлуатує довіру сервера до браузера користувача: сервер виконує команду зловмисника, тому що запит надходить з валідними кукі. XSS експлуатує довіру браузера до контенту сервера: браузер виконує скрипт, вбудований зловмисником у сторінку. CSRF не потребує внесення коду на цільовому сайті — достатньо надіслати запит з іншого домену. XSS, навпаки, потребує знайти спосіб внести свій JavaScript у HTML-код сторінки. При цьому XSS може обходити CSRF-захист: вбудований скрипт читає CSRF-токен зі сторінки і надсилає його разом із запитом.

Розуміння різниці між CSRF та XSS критично важливе для побудови багаторівневого захисту. CSRF-токени не захищають від XSS, а CSP (Content Security Policy) не захищає від CSRF. Тільки комбінація методів забезпечує безпеку додатка від обох типів атак. У мобільних додатках з WebView ризики подвоюються, тому розробникам рекомендується застосовувати як мінімум CSRF-токени для API-запитів та Content Security Policy для веб-контенту.