CSRF у мобилном развоју: суштина, типови напада и методе заштите

Шта је CSRF напад?

CSRF (Cross-Site Request Forgery) је напад у којем нападач ствара фалсификовани захтев и приморава прегледач жртве да га пошаље на циљни сервер. Сервер извршава захтев јер прима валидне cookie-credential податке тренутне сесије корисника. Напад је могућ јер прегледач аутоматски додаје колачиће сваком захтеву ка циљном домену, без обзира на то са које странице је захтев послат. Корисник можда није ни видео страницу нападача — довољно је учитати скривени <img>, <form> или <iframe> са злонамерним URL-ом. CSRF не краде податке директно — напад извршава радње у име жртве (state-changing operations), попут трансфера новца, промене лозинке или брисања налога.

Које операције су најрањивије?

CSRF напади су усмерени искључиво на операције које мењају стање — GET захтеве са споредним ефектима, POST, PUT и DELETE. На пример, захтев за промену адресе е-поште у личном налогу: ако сервер прихвати захтев без провере порекла, нападач може да замени своју адресу и покрене ресетовање лозинке. Напад је посебно опасан за банкарске системе, администраторске панеле и друштвене мреже, где једна радња има озбиљне последице. API-ји мобилних апликација који користе колачиће за аутентификацију такође су подложни CSRF-у ако не примењују додатне провере.

Ко је у зони ризика?

Под напад падају сваке веб апликације и API-ји где се аутентификација заснива на колачићима, а сервер не проверава порекло захтева. Мобилне апликације које користе WebView за ауторизацију путем веб форми такође су рањиве: компонента прегледача аутоматски шаље колачиће, а нападач може да убаци злонамерни захтев кроз позадинско учитавање. Према HackerOne (2025), око 12% свих извештаја о рањивостима у веб апликацијама односи се на недостатак заштите од CSRF-а.

Шта чини CSRF опасним?

Главна карактеристика CSRF-а је невидљивост за жртву. Корисник можда ни не сумња да се напад догодио: фалсификовани захтев се извршава у позадини, а интерфејс апликације не показује знакове провале. Једини начин да се открије CSRF је праћење серверских дневника или изненадне промене на налогу. Поред тога, CSRF се лако комбинује са другим рањивостима, попут XSS-а или отворених преусмеравања, што вишеструко повећава штету.

Како функционише CSRF напад?

CSRF напад се састоји од три обавезна услова: жртва је ауторизована на циљном сајту, сервер користи cookie аутентификацију, а захтев нападача је усмерен на action 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-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-базираним сесијама. Према 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-а за одређени origin захтева путем 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 напада без значајног утицаја на 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 захтевима и не искључује се политикама прегледача. Имплементација: бела листа дозвољених origin-а, поређење са тренутном вредношћу заглавља. Метод је ефикасан, али сложен са мобилним апликацијама где 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 за веб садржај.