CSRF в мобилната разработка: същност, типове атаки и методи за защита

Какво е CSRF атака?

CSRF (Cross-Site Request Forgery) е атака, при която нападателят създава фалшива заявка и принуждава браузъра на жертвата да я изпрати до целевия сървър. Сървърът изпълнява заявката, защото получава валидни бисквитени идентификационни данни на текущата сесия на потребителя. Атаката е възможна, защото браузърът автоматично добавя бисквитки към всяка заявка към целевия домейн, независимо от коя страница е изпратена заявката. Потребителят може дори да не е видял страницата на нападателя — достатъчно е да се зареди скрит <img>, <form> или <iframe> със злонамерен URL. CSRF не краде данни директно — атаката извършва действия от името на жертвата (операции за промяна на състоянието), като превод на пари, смяна на парола или изтриване на акаунт.

Кои операции са най-уязвими?

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

Кой е в риск?

Всички уеб приложения и API-та, където автентикацията се основава на бисквитки и сървърът не проверява произхода на заявката, са изложени на атака. Мобилните приложения, използващи WebView за авторизация чрез уеб формуляри, също са уязвими: компонентът на браузъра автоматично изпраща бисквитки и нападателят може да инжектира злонамерена заявка чрез фоново зареждане. Според HackerOne (2025), около 12% от всички доклади за уязвимости в уеб приложенията са свързани с липсата на защита срещу CSRF.

Какво прави CSRF опасен?

Основната характеристика на CSRF е невидимостта за жертвата. Потребителят може дори да не подозира, че атаката е станала: фалшивата заявка се изпълнява на заден план и интерфейсът на приложението не показва признаци на проникване. Единственият начин за откриване на CSRF е мониторинг на сървърните логове или внезапни промени в акаунта. Освен това, CSRF лесно се комбинира с други уязвимости, като XSS или отворени пренасочвания, което многократно увеличава щетите.

Как работи CSRF атаката?

CSRF атаката се състои от три задължителни условия: жертвата е авторизирана на целевия сайт, сървърът използва бисквитена автентикация и заявката на нападателя е насочена към URL на действието. Нападателят създава HTML страница с формуляр, скрипт или изображение, чийто атрибут src сочи към целевия URL. Браузърът на жертвата зарежда тази страница и автоматично изпраща заявката до сървъра заедно с бисквитката на текущата сесия. Сървърът получава валидни бисквитки, не проверява източника на заявката и изпълнява операцията.

<!-- Пример 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>

След зареждане на страницата, скриптът незабавно изпраща формуляра. Браузърът прикрепя сесийната бисквитка на потребителя към POST заявката до bank.example.com. Сървърът на банката проверява бисквитката, потвърждава, че потребителят е автентикиран, и извършва превода към сметката на нападателя. Жертвата вижда празна или легитимна страница, а парите вече са преведени.

Ролята на браузъра в CSRF

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

Основни типове CSRF атаки

CSRF атаките се класифицират според метода на доставяне на злонамерената заявка. Всеки тип използва различен HTML елемент за изпращане на заявката, но всички разчитат на автоматичното изпращане на бисквитки от браузъра. Изборът на метод зависи от целите на нападателя: GET-базираните атаки изискват по-малко код, POST-базираните по-надеждно заобикалят някои защити, а XMLHttpRequest-базираните позволяват манипулиране на хедъри.

GET-базиран CSRF

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

POST-базиран CSRF

Ако сървърът приема само POST заявки, нападателят създава скрит формуляр с POST метод и го изпраща автоматично чрез JavaScript. Формулярът не се показва на екрана (всички <input> имат type="hidden"), а autofocus + .submit() работи без кликване на потребителя. POST-базираните атаки не работят, ако сървърът проверява Content-Type хедъра, но повечето API-та приемат стандартния application/x-www-form-urlencoded.

XHR-базиран CSRF (с CORS)

XMLHttpRequest или Fetch API позволяват изпращане на заявки с произволни хедъри. Ако сървърът е конфигурирал CORS твърде широко (Access-Control-Allow-Origin: *), нападателят може да изпрати всякаква заявка и да прочете отговора. Въпреки това, за CSRF атака четенето на отговора не е необходимо — достатъчно е извършването на действието. Съвременните браузъри изпращат preflight заявка OPTIONS преди нестандартни заявки, което може да блокира XHR-базиран CSRF, ако сървърът е правилно конфигуриран.

CSRF в мобилните приложения

Мобилните приложения са по-малко податливи на CSRF от уебсайтовете, защото нативните приложения рядко използват бисквитена автентикация. Вместо това, мобилните API-та по-често прилагат токени в Authorization хедъра (Bearer токени, JWT). Съществуват обаче сценарии, при които CSRF атака е възможна: WebView с уеб вход, хибридни приложения и API-та с бисквитено-базирани сесии. Според 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 в бисквитка (което е рядко, но се случва), рискът се връща. Допълнителна защита — обвързване на JWT с конкретен произход на заявката чрез 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 за бисквитки и проверка на Origin хедъра. Комбинацията от тези методи осигурява защита от 99% от CSRF атаките без съществено влияние върху потребителското изживяване. Изборът на конкретен подход зависи от архитектурата на приложението: за уебсайт е достатъчен 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

Метод, който не изисква съхранение на токена на сървъра: сървърът задава бисквитка с произволна стойност, клиентът чете стойността от бисквитката и я изпраща обратно в хедъра или тялото на заявката. Сървърът сравнява и двете стойности. Ако нападателят не може да чете бисквитката (Same-origin policy), няма да може да фалшифицира токена. Методът е по-лесен за имплементиране от синхронизатора, но изисква HTTPS за защита на бисквитката от прихващане.

• CSRF токени — златен стандарт: надеждни, изпитани във времето, поддържани от всички рамки
• SameSite=Lax — минимална защита за уеб приложения: безплатно, автоматично, не изисква код
• Проверка на Origin — допълнително ниво: блокира атаките преди проверка на токена
• Double Submit — за REST API без сървърни сесии: ефективен на 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 за уеб съдържание.