Как защититься от xss атаки и устранить уязвимость. Хранимые XSS-атаки и защита от них (удаляем javascript из html в браузере) Защита от xss атак
Всем привет! В этой статье мы рассмотрим, что такое XSS-атака и как от нее защититься .
Что такое XSS?XSS(Cross Site Scripting) - межсайтовый скриптинг. С помощью XSS-уязвимостей обычно злоумышленники крадут cookies пользователей, используя вставки javascript кода. Данный вид атаки практически безопасен для сервера, но очень опасен для пользователей.
Как защититься от XSS?Обычно подобную уязвимость можно найти в формах или в get запросах. Например, у нас есть форма поиска на сайте. Попробуйте ввести туда подобную команду:
alert("cookies: " + document.cookie)
Если вы увидите всплывающее окно с информацией о cookies , значит форма подвержена атаке.
То же самое можно проделать и для get запросов. Просто подставьте вместо нужного значения уже известную нам команду:
Http://site.ru/script?query=alert("cookies: " + document.cookie)
На самом деле существуют многие разновидности кода, встраивая который в формы или запросы можно получить доступ к информации на сайте, но нам, как разработчикам, важно не это, а то, как от этой атаки защититься. Давайте об этом и поговорим.
Как защититься от XSS?Чтобы защититься от XSS , нужно просто заменить все опасные символы на безопасные.
$strainer = array("");
$_GET["query"] = str_replace($strainer, "|", $_GET["query"]);
Чтобы использовать стрейнер для каждого символа, можно написать функцию.
И эта статья обещает быть информативной, особенно для новичков.
И чтобы было представление о XSS, я разделю статью на 2 части, где в 1ом разберем, что за зверь этот XSS. А во втором рассмотрим, как она эксплуатируется в PHP и как от этого защититься.
– XSS. Что такое?
Теория
Cross Site Scripting - тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. А знаете почему не CSS? Правильно, потому что эта аббревиатура занята каскадными стилями.
Вообще XSS делится на 2 типа:
- Reflected (непостоянные).
Давайте разберем этот тип подробнее. Этот тип XSS самый популярный, да и самый часто встречающийся среди всех инъекций. Тип атаки довольно простой, срабатывает и отсутствии фильтрации входных данных, чаще всего через какие-то формы на сайте. Например,
Site.ru/search.php?q=alert(‘r0hack’)
Получается, если эта поступающая строка не будет фильтроваться на стороне сервака, то получаем сообщение «r0hack». Ну и что скажете вы, ничего же страшного. А нет, ведь таким образом мы можем украсть куки авторизации пользователя. Давайте для примера разберем 1 таск с рут ми. Хотя ее можно отнести к обоим типам атаки, но в этом примере, можно увидеть, как мы можем стырить куки пользователя, ну и как работают stored тип.
- Stored (хранимые). В этом случае, мы можем загрузить свой код на сервер и каждый раз при открытии страницы с данным кодом, она запускается и наносит сокрушительный удар, например, как я говорил выше, ворует куки и можем выдать себя за другого пользователя. А теперь давайте разберем таск, про который я писал выше.
Скрыто от гостей
И как видим в задании сказано украсть куки администратора и зайти с их помощью.
И дали простенький форум, где можем отправлять сообщения. Ну тут сразу можно понять, что сообщение нужно отправить скрипт, при клике на который мы получим куки. Специально для такие целей мы можно использовать, например сайт
Скрыто от гостей
Где она формирует ссылку, и при переходе по которому крадет данные заголовков, куки и все такое. Давайте так и сделаем, и замаскируем наше сообщение под фотографию и отправим.
Здесь формируем, такой скрипт для отправки:
document.write("
После чего отправляем, и когда админом страница будет открыта, мы получаем куки:
И если эти данные мы подставим в куки, то статус посетителя поменяется на Admin.
На этом про XSS говорить закончим, если что-то непонятно спрашивайте или гуглите, инфы много.
– Эксплуатация XSS уязвимостей в PHP
Давайте сразу перейдем к практике и посмотрим, при каком случае, XSS атака может сработать.
У нас имеется такой кусок кода, который не экранирует исходящие данные:
$query = $_GET["query"] ?? 0; echo "Найдено: ". $query;
И как вы видите, в данном случае наш скрипт срабатывает.
– Как обезопасить PHP от XSS
И как закрыть эксплуатацию данной уязвимости, предельно просто все это делается, это просто экранируем:
$query = $_GET["query"] ?? 0; $query = htmlspecialchars($query, ENT_QUOTES); echo "Найдено: ". $query;
И наш скрипт мы получаем, как обычный текст, благодаря htmlspecialchars, ENT_QUOTES - преобразует как двойные, так и одинарные кавычки. И будет вам счастье.
Ну для примера, еще какой-нибудь немецкий сайт:
На этом с XSS закончу. Надеюсь получилось не плохо. Вопросы пишите в комментах. Спасибо.
Создание функционирующего веб-приложения – это только полдела. Современные онлайн-сервисы и веб-приложения, помимо собственного контента, хранят данные пользователей. Защита этих данных зависит от правильно написанного кода с точки зрения надёжности и безопасности.Большинство уязвимостей связано с неправильной обработкой данных, получаемых извне, или недостаточно строгой их проверкой. Одной из таких уязвимостей является межсайтовое выполнение сценариев (Сross Site Sсriрting, XSS), которая может привести к дефейсу сайта, перенаправлению пользователя на зараженный ресурс, вставке в веб-ресурс вредоносного кода, краже COOKIE-файлов, сессии и прочей информации. Противостоять XSS своими сила поможет применение лучших практик и рекомендаций по безопасному программированию, о которых и пойдет речь ниже.
1. Используйте экранирование входных\выходных данных. Применяйте встроенные функции для очистки кода от вредоносных скриптов. К ним относятся такие функции как htmlspecialchar(), htmlentities() и strip_tags().Примеры использования:
$name = strip_tags($_POST["name"]);
$name = htmlentities($_POST["name"], ENT_QUOTES, "UTF-8");
$name = htmlspecialchars($_POST["name"], ENT_QUOTES);
Встроенные функции PHP, в отличие от самописных, работают гораздо быстрее, а также имеют меньше ошибок безопасности и уязвимостей, т.к. постоянно совершенствуются. Также рекомендуется использовать специальные библиотеки, построенные на основе встроенных функций и фильтров. В качестве примера можно привести OWASP Enterprise Security API (ESAPI), HTML Purifier, Reform, ModSecurity.
Для того чтобы библиотека работала правильно, её нужно предварительно настроить!
2.
Используйте подход «белые списки». Подход работает по принципу «что не разрешено, то запрещено». Это стандартный механизм валидации полей для проверки всех входных данных, включая заголовки, куки, строки запросов, скрытые поля, а также длина полей форм, их тип, синтаксис, допустимые символы и другие правила, прежде чем принять данные, которые будут сохраненные и отображены на сайте. Например, если в поле нужно указать фамилию, необходимо разрешить только буквы, дефис и пробелы. Если отклонить все остальное, то фамилия д’Арк будет отклонена - лучше отклонить достоверную информацию, чем принять вредоносные данные.
К сожалению, со своей задачей встроенные фильтры валидации данных PHP не справляются, поэтому рекомендуется писать собственные фильтры и «допиливать» их по мере необходимости. Таким образом, со временем ваши входные методы фильтрации будут усовершенствованы. Стоит также не забывать, что существует слишком много типов активного содержимого и способов кодирования для обхода подобных фильтров. По этой же причине не используйте проверку по «черному списку».
3.
Указывайте кодировку на каждой веб-странице. Для каждой веб-страницы необходимо указывать кодировку (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
Пример использования:
Сharset
или в файле.htaccess веб-сервера Apache дописать строчку:
AddDefaultCharset UTF-8
Если в http-заголовке или в метатегах кодировка не указана, браузер пытается сам определить кодировку страницы. Стандарт HTML 5 не рекомендует использовать такие кодировки, которые включают JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), а также кодировки, основанные на ISO-2022 и EBCDIC. Кроме того, веб-разработчики не должны использовать CESU-8, UTF-7, BOCU-1 и кодировки SCSU. Эти кодировки никогда не предназначались для веб-контента. В случае если тег расположен до тега и заполняется пользовательскими данными, злоумышленник может вставить вредоносный html-код в кодировке UTF-7, обойдя, таким образом, фильтрацию таких символов, как ‘