Уязвимости межсайтового скриптинга являются сегодня самой большой проблемой безопасности сайта. Исследования показали, что они шокирующе распространены — 55% веб-сайтов содержали уязвимости XSS в 2011 году, согласно последнему отчету White Hat Security, выпущенному в июне 2012 года. Хотя большинство людей слышали о компьютерных вирусах, и другие подобные проблемы, уязвимости XSS остаются неизвестными для среднего человека.
Уязвимость межсайтового скриптинга позволяет злоумышленнику выполнять произвольный код JavaScript (с другого сайта) на веб-странице. Код выполняется на веб-странице в браузере пользователя.
Пример — червь Twitter StalkDaily
Давайте посмотрим на XSS-атаку, которая произошла в прошлом с Twitter. В 2009 году червь StalkDaily В червем распространяются по всему Твиттеру. Когда пользователь Twitter заходил на страницу профиля зараженного пользователя, его страница профиля также заражалась, распространяя червя. Червь также рассылал твиты с каждого зараженного аккаунта.
Итак, как именно работал червь StalkDaily? Кто-то взломал веб-серверы Twitter? Не совсем — хотя это был своего рода взлом.
Каждый пользователь Twitter может установить небольшую биографию на странице своего профиля. Пользователи вводят текст в поле профиля, и после сохранения профиля текст появляется на странице его профиля. Кто-то понял, что Твиттер неправильно очищает ввод текста из биобокса (мы вернемся к этому позже) — он просто поместил текстовые пользователи, введенные непосредственно в исходный код веб-страницы. Это позволило пользователю ввести тег HTML <script>, который загружает файл JavaScript со стороннего веб-сервера.
Когда другой пользователь Twitter зашел на страницу зараженного профиля, его браузер загрузил скрипт. Сценарий имел полный доступ ко всему, что использовался на странице официальным кодом Twitter, поэтому он мог запрашивать cookie-файл пользователя (в котором хранится состояние входа пользователя) и имя пользователя из браузера. Затем сценарий отправил эту информацию обратно на сторонний веб-сервер. С этими подробностями сторонний веб-сервер может аутентифицироваться как пользователь Twitter, изменять биографию пользователя для распространения червя и отправлять твиты из учетной записи пользователя.
Как разработчики могут предотвратить атаки XSS
Одно простое правило позволяет веб-разработчикам чтобы предотвратить межсайтовый скриптинг: не доверяйте никаким данным, поступающим от пользователей. Например, в случае с Twitter им не следовало доверять текстовым пользователям, введенным в их биобоксы. Twitter должен был взять текст и «санировать» или «экранировать» его — например, <script> должен быть заменен на & lt; script & gt; — он будет отображаться как <script> на странице, но не будет работать как HTML-код.
Аналогичным образом, веб-сайт онлайн-покупок, такой как Amazon не следует доверять представленным пользователями отзывам — следует дезинфицировать весь текст обзора, чтобы гарантировать его безопасность.
Есть и другие методы, которые разработчики могут использовать для защиты от атак XSS, например, спецификация политики безопасности контента W3C позволяет веб-разработчикам ограничивать веб-приложение только загрузкой сценариев с определенных URL-адресов. Разработчики также могут установить HttpOnly для своих файлов cookie, что препятствует доступу скриптов к ним.
XSS Plus Другие уязвимости
Атаки XSS могут быть особенно опасными в сочетании с другими уязвимостями. Например, атака XSS может загрузить сценарий, который использует уязвимость безопасности в веб-браузере или плагинах. такие как Flash или Java. Если злоумышленник скомпрометировал страницу с обзором продукта на веб-сайте интернет-магазина, он может загрузить код, который использует уязвимость, и поставить под угрозу каждый непатчированный компьютер, который просматривает страницу продукта. Это делает разработчиков особенно важными для защиты своих сайтов от атак XSS.
Как вы можете предотвратить атаки XSS
Если вы дошли до этого момента, вам, вероятно, интересно, что вы — как пользователь — можете сделать, чтобы предотвратить атаки XSS. Плохая новость заключается в том, что, по большей части, веб-разработчики — те, кто должен сделать это правильно. Тем не менее, есть еще несколько вещей, которые вы можете сделать:
- Постоянно обновляйте ваш браузер и плагины. — Мало того, что последние исправления безопасности помогут смягчить атаки XSS, основанные на этих уязвимостях, чтобы вырваться из вашего браузера, новые браузеры имеют большую защиту от атак XSS, чем старые. Более новые браузеры включают поддержку веб-функций, таких как Content Security Policy (упомянутых выше), которые позволяют разработчикам лучше защищать свои веб-сайты. Они также включают меры против XSS — например, Chrome и другие браузеры на основе WebKit, такие как Safari, включают XSS Auditor, который пытается идентифицировать и блокировать атаки XSS. Internet Explorer даже включает свою собственную контрмеру, названную XSS Filter .
- Отключите JavaScript полностью — хотя нам не особенно нравится NoScript здесь, в , , отключение JavaScript полностью исключает атаки XSS. К сожалению, отключение JavaScript также устраняет множество других вещей, которые нам нравятся в современном Интернете, и многие сайты не будут работать должным образом без включенного JavaScript.
Был ли у вас опыт работы с XSS-атаками? Оставьте комментарий и поделитесь своим опытом — если у вас есть какие-либо вопросы об уязвимостях XSS, мы также будем рады ответить на них.
Image Credit: 3D-коммуникация с помощью Shutterstock