CSRF sa mobile development: esensya, mga uri ng pag-atake at paraan ng proteksyon

Ano ang CSRF attack?

Ang CSRF (Cross-Site Request Forgery) ay isang pag-atake kung saan lumilikha ang umaatake ng isang pekeng kahilingan at pinipilit ang browser ng biktima na ipadala ito sa target na server. Isinasagawa ng server ang kahilingan dahil natatanggap nito ang mga wastong cookie-credentials ng kasalukuyang session ng gumagamit. Posible ang pag-atake dahil awtomatikong nagdaragdag ang browser ng mga cookie sa bawat kahilingan sa target na domain, anuman ang pahina kung saan ipinadala ang kahilingan. Maaaring hindi pa nakita ng gumagamit ang pahina ng umaatake — sapat na ang mag-load ng nakatagong <img>, <form> o <iframe> na may mapaminsalang URL. Hindi direktang nagnanakaw ng data ang CSRF — ang pag-atake ay nagsasagawa ng mga aksyon sa ngalan ng biktima (mga operasyong nagbabago ng estado), tulad ng paglipat ng pera, pagpapalit ng password, o pagtanggal ng account.

Aling mga operasyon ang pinaka-mahina?

Ang mga pag-atake ng CSRF ay eksklusibong nakatuon sa mga operasyong nagbabago ng estado — mga GET request na may mga side effect, POST, PUT at DELETE. Halimbawa, isang kahilingang baguhin ang email address sa personal na account: kung tatanggapin ng server ang kahilingan nang hindi sinusuri ang pinagmulan, maaaring palitan ng umaatake ang kanyang sariling email at magpasimula ng pag-reset ng password. Ang pag-atake ay partikular na mapanganib para sa mga sistema ng bangko, admin panel, at social network, kung saan ang isang aksyon ay may malalang kahihinatnan. Ang mga API ng mobile application na gumagamit ng cookies para sa authentication ay madaling kapitan sa CSRF kung hindi sila naglalapat ng karagdagang pagsusuri.

Sino ang nasa peligro?

Lahat ng web application at API kung saan ang authentication ay batay sa cookie at hindi sinusuri ng server ang pinagmulan ng kahilingan ay nasa panganib. Ang mga mobile application na gumagamit ng WebView para sa awtorisasyon sa pamamagitan ng web form ay mahina rin: awtomatikong nagpapadala ang component ng browser ng mga cookie, at maaaring mag-inject ng mapaminsalang kahilingan ang umaatake sa pamamagitan ng background loading. Ayon sa HackerOne (2025), humigit-kumulang 12% ng lahat ng ulat ng kahinaan sa mga web application ay may kaugnayan sa kawalan ng proteksyon sa CSRF.

Ano ang nagpapadelikado sa CSRF?

Ang pangunahing katangian ng CSRF ay hindi ito nakikita ng biktima. Maaaring hindi man lang pinaghihinalaan ng gumagamit na naganap ang pag-atake: ang pekeng kahilingan ay isinasagawa sa background, at ang interface ng application ay hindi nagpapakita ng mga senyales ng pagpasok. Ang tanging paraan upang matukoy ang CSRF ay ang pag-monitor ng mga server log o biglaang pagbabago sa account. Bilang karagdagan, ang CSRF ay madaling pinagsama sa iba pang mga kahinaan, tulad ng XSS o bukas na redirect, na nagpapalaki ng pinsala nang maraming beses.

Paano gumagana ang CSRF attack?

Ang CSRF attack ay binubuo ng tatlong sapilitang kondisyon: ang biktima ay awtorisado sa target na site, ang server ay gumagamit ng cookie authentication, at ang kahilingan ng umaatake ay nakadirekta sa action URL. Lumilikha ang umaatake ng HTML page na may form, script, o larawan na ang src attribute ay tumuturo sa target na URL. Ang browser ng biktima ay naglo-load ng page na ito at awtomatikong nagpapadala ng kahilingan sa server kasama ang cookie ng kasalukuyang session. Ang server ay tumatanggap ng wastong cookies, hindi sinusuri ang pinagmulan ng kahilingan, at isinasagawa ang operasyon.

<!-- Halimbawa ng CSRF attack sa pamamagitan ng nakatagong form -->
<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>

Pagkatapos mag-load ng page, agad na ipinapadala ng script ang form. Isinasama ng browser ang session cookie ng gumagamit sa POST request sa bank.example.com. Sinusuri ng server ng bangko ang cookie, tinitiyak na ang gumagamit ay naka-authenticate, at isinasagawa ang paglipat sa account ng umaatake. Ang biktima ay nakakakita ng walang laman o lehitimong page, at ang pera ay nailipat na.

Ang papel ng browser sa CSRF

Ang pangunahing katangian ng HTTP protocol — kawalan ng built-in na pagsusuri ng pinagmulan ng kahilingan. Ang browser ay nagdaragdag ng cookie sa kahilingan kung ang domain ng kahilingan ay tumutugma sa domain ng cookie. Hindi kailangang malaman ng umaatake ang nilalaman ng cookie — awtomatikong ginagawa ito ng browser. Hindi pinoprotektahan ng Same-origin policy laban sa CSRF dahil ang pag-atake ay nakatuon sa server, hindi sa pagbabasa ng tugon. Ang mga mekanismo tulad ng CORS ay walang silbi rin: ang mga CSRF request ay karaniwang hindi nangangailangan ng pagbabasa ng tugon upang magdulot ng pinsala.

Mga pangunahing uri ng CSRF attacks

Ang mga CSRF attack ay inuuri batay sa paraan ng paghahatid ng mapaminsalang kahilingan. Ang bawat uri ay gumagamit ng iba't ibang HTML element para magpadala ng kahilingan, ngunit lahat ay umaasa sa awtomatikong pagpapadala ng cookie ng browser. Ang pagpili ng pamamaraan ay depende sa mga layunin ng umaatake: ang mga GET-based attack ay nangangailangan ng mas kaunting code, ang POST-based ay mas mapagkakatiwalaang lumalampas sa ilang proteksyon, at ang XMLHttpRequest-based ay nagpapahintulot sa pagmamanipula ng mga header.

GET-based CSRF

Ang pinakasimpleng paraan: ang umaatake ay naglalagay ng <img> sa page na may URL na naglalaman ng mga parameter ng kahilingan. Nilolo-load ng browser ang imahe at nagpapadala ng GET request sa server. Halimbawa, <img src="https://api.example.com/delete?postId=123" /> ay nagtatanggal ng entry kung pinoproseso ng server ang DELETE sa pamamagitan ng GET. Sa kabila ng malinaw na panganib, ang ilang API ay gumagamit pa rin ng GET para sa mga operasyon ng pagtanggal o pag-update.

POST-based CSRF

Kung ang server ay tumatanggap lamang ng mga POST request, ang umaatake ay lumilikha ng nakatagong form na may POST method at awtomatikong ipinapadala ito sa pamamagitan ng JavaScript. Ang form ay hindi ipinapakita sa screen (lahat ng <input> ay may type="hidden"), at ang autofocus + .submit() ay gumagana nang walang pag-click ng gumagamit. Ang POST-based attack ay hindi gumagana kung sinusuri ng server ang Content-Type header, ngunit karamihan sa mga API ay tumatanggap ng karaniwang application/x-www-form-urlencoded.

XHR-based CSRF (may CORS)

Ang XMLHttpRequest o Fetch API ay nagpapahintulot sa pagpapadala ng mga kahilingan na may arbitrary headers. Kung ang server ay nag-configure ng CORS nang masyadong malawak (Access-Control-Allow-Origin: *), ang umaatake ay maaaring magpadala ng anumang kahilingan at basahin ang tugon. Gayunpaman, para sa isang CSRF attack, hindi kinakailangan ang pagbabasa ng tugon — sapat na ang pagsasagawa ng aksyon. Ang mga modernong browser ay nagpapadala ng preflight request OPTIONS bago ang mga hindi karaniwang kahilingan, na maaaring humarang sa XHR-based CSRF kung ang server ay naka-configure nang tama.

CSRF sa mga mobile application

Ang mga mobile application ay mas madaling kapitan sa CSRF kaysa sa mga website, dahil ang mga native application ay bihirang gumagamit ng cookie authentication. Sa halip, ang mga mobile API ay mas madalas na naglalapat ng mga token sa Authorization header (Bearer tokens, JWT). Gayunpaman may mga senaryo kung saan posible ang CSRF attack: WebView na may web login, hybrid application, at API na may cookie-based na session. Ayon sa TechCrunch (2025), humigit-kumulang 18% ng mga pampublikong API ng mobile application ay sumusuporta pa rin sa session cookies.

CSRF sa pamamagitan ng WebView

Maraming application ang nagbubukas ng mga web page sa WebView — awtorisasyon sa pamamagitan ng OAuth, mga form ng pagbabayad, pagtingin ng nilalaman. Ang WebView ay isang ganap na browser sa loob ng application na nag-iimbak ng session cookies. Kung ang umaatake ay makahanap ng paraan upang i-load ang kanyang URL sa WebView (sa pamamagitan ng bukas na redirect o Deep Link), maaari siyang magsagawa ng CSRF attack nang eksakto tulad sa isang regular na browser. Proteksyon — paggamit ng Chrome Custom Tabs o SFSafariViewController sa halip na WebView para sa mga kritikal na operasyon.

CSRF sa API na may JWT authentication

Ang mga JWT token ay karaniwang iniimbak sa localStorage o sa memorya ng application at hindi awtomatikong ipinapadala — ang developer ay tahasang nagdaragdag ng Authorization header sa bawat kahilingan. Ginagawa nitong imposible ang klasikong CSRF attack. Gayunpaman kung ang application ay nag-iimbak ng JWT sa cookie (bihira ngunit nangyayari), babalik ang panganib. Karagdagang proteksyon — pagtali ng JWT sa isang tiyak na origin ng kahilingan sa pamamagitan ng azp o aud claim, na pumipigil sa paggamit ng token sa ibang domain.

// Halimbawa ng server-side CSRF token validation sa 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();
};

// Pagbuo ng CSRF token sa pag-login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Mga paraan ng proteksyon laban sa CSRF

Ang modernong proteksyon laban sa CSRF ay batay sa tatlong antas: server-side CSRF tokens, SameSite attribute para sa cookie, at pag-verify ng Origin header. Ang kumbinasyon ng mga pamamaraang ito ay nagbibigay ng proteksyon laban sa 99% ng mga CSRF attack nang walang makabuluhang epekto sa UX. Ang pagpili ng tiyak na diskarte ay depende sa arkitektura ng application: ang isang website ay sapat na ang SameSite=Lax, ang API ng isang mobile application ay nangangailangan ng mga token sa headers.

CSRF tokens (synchronizer)

Karaniwang paraan: ang server ay bumubuo ng natatanging token, itinatali ito sa session ng gumagamit, at ipinapadala ito sa client. Isinasama ng client ang token sa bawat kahilingang nagbabago ng estado (sa nakatagong field ng form o X-CSRF-Token header). Inihahambing ng server ang natanggap na token sa naka-imbak sa session. Ang token ay dapat na ligtas sa kriptograpiya, random, hindi bababa sa 32 byte ang haba, at magbago sa bawat session o operasyon. Ang buhay ng token — hindi hihigit sa ilang oras.

SameSite Cookie

Ang SameSite attribute para sa cookie ay naglilimita sa pagpapadala ng cookie sa mga cross-domain na kahilingan. Ang halagang Lax ay nagpapahintulot sa pagpapadala ng cookie lamang para sa mga navigational GET request ng pinakamataas na antas — ito ay sapat para sa karamihan ng mga site. Hinaharang ng Strict ang cookie para sa lahat ng cross-domain na kahilingan, kabilang ang nabigasyon: ang gumagamit ay kailangang mag-log in muli kapag lumipat mula sa ibang site. Ayon sa Chrome Platform Status (2026), ang SameSite=Lax ay naka-default na naka-activate sa lahat ng modernong browser, na nagbawas ng bilang ng mga CSRF attack ng 67%.

Pag-verify ng Origin at Referer

Maaaring suriin ng server ang Origin o Referer headers ng papasok na kahilingan. Kung ang kahilingan ay nagmula sa ibang domain — ito ay haharangin. Ang Origin ay mas maaasahan kaysa sa Referer dahil ito ay palaging naroroon sa mga POST request at hindi pinapatay ng mga patakaran ng browser. Implementasyon: isang puting listahan ng mga pinapayagang origin, paghahambing sa kasalukuyang halaga ng header. Ang pamamaraan ay epektibo ngunit kumplikado sa mga mobile application kung saan ang Origin headers ay maaaring wala o peke.

// Halimbawa ng CSRF token validation sa 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

Isang paraan na hindi nangangailangan ng pag-iimbak ng token sa server: ang server ay nagtatakda ng cookie na may random na halaga, binabasa ng client ang halaga mula sa cookie at ipinapadala ito pabalik sa header o body ng kahilingan. Inihahambing ng server ang parehong halaga. Kung hindi mababasa ng umaatake ang cookie (Same-origin policy), hindi niya pekein ang token. Ang pamamaraan ay mas madaling ipatupad kaysa sa synchronizer, ngunit nangangailangan ng HTTPS upang protektahan ang cookie mula sa panghihimasok.

• CSRF tokens — ang gintong pamantayan: maaasahan, nasubok sa panahon, suportado ng lahat ng frameworks
• SameSite=Lax — minimal na proteksyon para sa web application: libre, awtomatiko, hindi nangangailangan ng code
• Pag-verify ng Origin — karagdagang antas: humaharang sa mga pag-atake bago ang pag-verify ng token
• Double Submit — para sa REST API na walang server-side session: epektibo sa HTTPS
• Custom headers — X-Requested-With: XMLHttpRequest humaharang sa mga simpleng CSRF form

Pagkakaiba sa pagitan ng CSRF at XSS

Ang CSRF at XSS ay magkaibang uri ng pag-atake na madalas na ikinalilito. CSRF ay nagsasamantala sa tiwala ng server sa browser ng gumagamit: isinasagawa ng server ang utos ng umaatake dahil ang kahilingan ay dumarating na may wastong cookies. XSS ay nagsasamantala sa tiwala ng browser sa nilalaman ng server: isinasagawa ng browser ang script na ininject ng umaatake sa page. Ang CSRF ay hindi nangangailangan ng pag-inject ng code sa target na site — sapat na ang magpadala ng kahilingan mula sa ibang domain. Ang XSS, sa kabaligtaran, ay nangangailangan ng paghahanap ng paraan upang i-inject ang sariling JavaScript sa HTML code ng page. Bilang karagdagan, maaaring lampasan ng XSS ang proteksyon ng CSRF: binabasa ng injected na script ang CSRF token mula sa page at ipinapadala ito kasama ng kahilingan.

Ang pag-unawa sa pagkakaiba sa pagitan ng CSRF at XSS ay kritikal para sa pagbuo ng multi-layered na proteksyon. Ang CSRF tokens ay hindi nagpoprotekta laban sa XSS, at ang CSP (Content Security Policy) ay hindi nagpoprotekta laban sa CSRF. Tanging ang kumbinasyon ng mga pamamaraan ang nagsisiguro ng seguridad ng application laban sa parehong uri ng pag-atake. Sa mga mobile application na may WebView, dumodoble ang mga panganib, kaya inirerekomenda sa mga developer na maglapat ng hindi bababa sa CSRF tokens para sa API requests at Content Security Policy para sa web content.