
- •Содержание
- •Введение
- •Определение и общие сведения о xss
- •Проведение xss-атаки методом get-запроса
- •Проведение xss-атаки методом рost-запроса
- •Проведение xss-атаки методом trace
- •Проведение xss-атаки через протокол data
- •Проведение xss-атаки через Flash-анимации
- •Проведение xss-атаки через dom
- •Как проверить, что сайт защищен от xss
- •Защита от xss - атак
Как проверить, что сайт защищен от xss
Логическим завершением защиты сайта является проверка его защищенности от атак XSS. Как и защита сайта от XSS, проверку степени защиты можно проводить вручную (трудный способ), либо с помощью автоматизированного средства оценки уязвимости Web-приложений. Такой инструмент снимет с вас нагрузку, связанную с проверкой. Эта программа перемещается по сайту и запускает все известные ей варианты для всех скриптов, которые она обнаруживает. При этом пробуются все параметры, заголовки и пути. В обоих методах каждый ввод в приложение (параметры всех скриптов, заголовки HTTP, пути) проверяется с максимально возможным количеством вариантов. И если ответная страница содержит код JavaScript в контексте, где браузер может его выполнить, то появляется сообщение об уязвимости к XSS. Например, при отправке следующего текста:
<script>alert(document.cookie)</script> |
каждому параметру каждого скрипта (через браузер с возможностями работы с JavaScript, чтобы выявить простейший вид уязвимости к XSS) браузер вызовет окно JavaScript Alert, если текст интерпретирован как код JavaScript. Конечно, есть несколько вариантов. Поэтому тестировать только этот вариант недостаточно. И, как вы уже узнали, можно вставлять код JavaScript в различные поля запроса: параметры, заголовки HTTP и путь. Однако в некоторых случаях (особенно с заголовком HTTP Referer) выполнять атаку с помощью браузера неудобно.
Защита от xss - атак
Следующая практика поможет уменьшить риск XSS-атаки:
Фильтруйте внешние данные
Как упоминалось ранее, фильтрация данных является обязательной для любого исполняемого кода. При проверке внешних данных вы будете смягчать большинство проблем с межсайтовым скриптингом. Используйте функциюhtmlspecialchars() или htmlentities для фильтрации данных.
Используйте подход "белого" списка
Вместо того, чтобы определять некорректные данные, используйте список допустимых данных применяя регулярные выражения. Это значит, что вместо того чтобы запрещать некоторые данные, лучше ограничить ввод только допустимыми. Например, для проверки электронной почты используйте регулярное выражение /^[0-9a-z\_\.\-]+@([\-a-z0-9]+\.)+[a-z]{2,}$/i, и в случае несоответствия с образцом завершайте работу скрипта.
Используйте строгие имена переменных
Именование переменных по определенному правилу поможет вам избежать путаницы при разработке. Я добавляю к проверенным переменным _check, чтобы в дальнейшем не пропустить нефильтрованые данные. Отсутствие ясности кода и пораждает такие уязвимости.
Эффективная защита от XSS-атаки через DOM:
1. Избегать перезаписи документа на стороне клиента, переадресацию или другие подобные действия, использующие данные на стороне клиента. Большинство этих действий может быть выполнено с использованием динамических страниц (на стороне сервера).
2. Анализ и повышение защищенности кода (Javascript) на стороне клиента. Ссылки на объекты DOM, на которые может влиять пользователь (атакующий), должны быть тщательно проверены. Особое внимание нужно уделять следующим объектам (но не ограничиваться ими):
document.URL
document.URLUnencoded
document.location (и его свойства)
document.referrer
window.location (и его свойства)
Обратите внимание: на свойства объектов document и window можно сослаться несколькими способами: явно (пример - window.location), неявно (пример - location) или через получения дескриптора и использования его (пример - handle_to_some_window.location).
Особое внимание нужно уделить коду, где модифицируется DOM, явно или есть потенциальная возможность, а также через прямой доступ к HTML или через доступ непосредственно к DOM.
3. Использовать строгие правила IPS, в которых, к примеру, странице welcome.html разрешено получать один единственный параметр, имеющий имя “name”, значение которого проверяется, и любое несоответствие (включая избыточные параметры или отсутствие параметров) приводит к отказу в обслуживании оригинальной страницы, также как и любое другой нарушение (например, заголовки Authorization или Referer, содержащие проблематичные данные). Хотя в некоторых случаях даже такие меры не гарантируют полную защиту от атаки.