XSS napadi: Kako napadači izvršavaju kod u vašem browseru

Šta je XSS?

Cross-Site Scripting (XSS) je napad u kome napadač ubacuje maliciozni JavaScript kod u web stranicu koju drugi korisnici posećuju. Browser žrtve izvršava taj kod u kontekstu pouzdanog sajta — što znači da kod ima pristup kolačićima, session tokenima, sadržaju stranice i može slati zahteve u ime korisnika.

XSS je posebno opasan jer radi na strani klijenta: server može biti potpuno siguran, a napad se i dalje dešava u browseru korisnika.

Tri tipa XSS napada

1. Reflected XSS

Maliciozni kod se prosleđuje kroz URL parametar, server ga uključuje u odgovor bez sanitizacije, i browser ga izvršava. Napad se "odbija" od servera ka korisniku.

Primer: https://sajt.rs/pretraga?q=<script>alert(1)</script>

Ako server prikaže vrednost parametra q direktno na stranici, script se izvršava. Napadač širi link žrtvama putem phishing emailova.

2. Stored XSS

Najopasniji tip: maliciozni kod se čuva u bazi podataka (komentar, profil, poruka) i prikazuje se svim korisnicima koji posete tu stranicu — bez ikakve akcije napadača nakon inicijalnog unosa.

Stored XSS napad na WordPress komentar može kompromitovati sesije svih administratora koji pregledaju komentare. Jedan napadač, hiljade žrtava.

3. DOM-based XSS

Napad se dešava isključivo na strani klijenta: JavaScript kod na stranici uzima podatke iz URL-a ili drugog izvora i dinamički upisuje ih u DOM bez sanitizacije, bez ikakvog zahteva ka serveru. Teško ga je detektovati statičkim skeniranjem.

// Ranjivi kod:
document.getElementById('output').innerHTML = location.hash.slice(1);
// URL: https://sajt.rs/page#<img src=x onerror=alert(1)>

Šta napadač može da uradi

Session hijacking: Krađa session cookie-ja i preuzimanje naloga
Keylogging: Snimanje svega što korisnik kuca (lozinke, podaci kartice)
Phishing: Prikazivanje lažnih formi za logovanje unutar pravog sajta
Defacement: Menjanje sadržaja stranice
Malware distribucija: Preusmeravanje korisnika na sajtove sa malwareom
CSRF bypass: Izvođenje akcija u ime korisnika (promena lozinke, plaćanje)

Odbrana od XSS-a

Output encoding

Svaki korisnički unos koji se prikazuje u HTML-u mora biti enkodiran. < postaje <, > postaje >. Moderni templating engine-i (Jinja2, Twig, Handlebars) ovo rade automatski — ali pazi na | safe ili innerHTML operacije.

Content Security Policy (CSP)

CSP zaglavlje govori browseru koji JavaScript sme da izvrši. Sa strogim CSP-om koji zabranjuje inline skripte, većina XSS napada je neutralisana čak i ako je ranjivost prisutna.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'

HttpOnly i Secure kolačići

HttpOnly atribut sprečava JavaScript da čita session cookie — čak i pri uspešnom XSS napadu, napadač ne može ukrasti session token.

Validacija unosa

Odbijte unos koji ne odgovara očekivanom formatu. Za HTML sadržaj koji mora biti dozvoljen (rich text editor), koristite proverene sanitizacione biblioteke poput DOMPurify.

Redovni assessment

Shieldome Scout testira reflektovani XSS šaljući benigne probe markere i analizirajući da li se pojavljuju u HTML odgovoru bez enkodiranja — sve bez aktivnih exploit payloada.

Proverite bezbednost vašeg sajta

Profesionalna procena ranjivosti. OWASP Top 10, dark web monitoring, PDF izveštaj za 2–3 radna dana.

Zatražite procenu →

← Blog

What Is XSS?

Cross-Site Scripting (XSS) is an attack where an attacker injects malicious JavaScript code into a web page visited by other users. The victim's browser executes that code in the context of a trusted site — meaning the code has access to cookies, session tokens, page content, and can send requests on behalf of the user.

XSS is particularly dangerous because it works on the client side: the server may be completely secure, but the attack still happens in the user's browser.

Three Types of XSS Attacks

1. Reflected XSS

Malicious code is passed through a URL parameter, the server includes it in the response without sanitization, and the browser executes it. The attack "reflects" from the server to the user.

Example: https://site.com/search?q=<script>alert(1)</script>

If the server displays the value of the q parameter directly on the page, the script executes. The attacker distributes the link to victims through phishing emails.

2. Stored XSS

The most dangerous type: malicious code is stored in a database (comment, profile, message) and displayed to all users who visit that page — without any action from the attacker after the initial submission.

A Stored XSS attack on a WordPress comment can compromise the sessions of all administrators who review comments. One attacker, thousands of victims.

3. DOM-based XSS

The attack happens entirely on the client side: JavaScript code on the page takes data from the URL or another source and dynamically writes it to the DOM without sanitization, without any request to the server. This is difficult to detect with static scanning.

// Vulnerable code:
document.getElementById('output').innerHTML = location.hash.slice(1);
// URL: https://site.com/page#<img src=x onerror=alert(1)>

What an Attacker Can Do

Session hijacking: Stealing session cookies and taking over accounts
Keylogging: Recording everything the user types (passwords, card details)
Phishing: Displaying fake login forms inside the real site
Defacement: Modifying page content
Malware distribution: Redirecting users to malware sites
CSRF bypass: Performing actions on behalf of users (password change, payment)

Defending Against XSS

Output Encoding

Every user input displayed in HTML must be encoded. < becomes <, > becomes >. Modern templating engines (Jinja2, Twig, Handlebars) do this automatically — but watch out for | safe or innerHTML operations.

Content Security Policy (CSP)

The CSP header tells the browser which JavaScript may execute. With a strict CSP that prohibits inline scripts, most XSS attacks are neutralized even if the vulnerability is present.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'

HttpOnly and Secure Cookies

The HttpOnly attribute prevents JavaScript from reading session cookies — even with a successful XSS attack, the attacker cannot steal the session token.

Input Validation

Reject input that does not match the expected format. For HTML content that must be allowed (rich text editors), use proven sanitization libraries like DOMPurify.

Regular Assessment

Shieldome Scout tests for reflected XSS by sending benign probe markers and analyzing whether they appear in HTML responses without encoding — all without active exploit payloads.

Check Your Website Security

Professional vulnerability assessment. OWASP Top 10, dark web monitoring, PDF report in 2–3 business days.

Request Assessment →