Содержание
Уязвимости межсайтового скриптинга являются сегодня самой большой проблемой безопасности сайта. Исследования показали, что они поразительно распространены — 55% веб-сайтов содержали уязвимости XSS в 2011 году, согласно последнему отчету White Hat Security, выпущенному в июне 2012 года. Хотя большинство людей слышали о компьютерных вирусах
и другие подобные проблемы, уязвимости XSS остаются неизвестными для среднего человека.
Уязвимость межсайтового скриптинга позволяет злоумышленнику выполнить произвольный код JavaScript (с другого сайта) на веб-странице. Код выполняется на веб-странице в браузере пользователя.
Пример — червь Twitter StalkDaily
Давайте посмотрим на XSS-атаку, которая произошла в прошлом с Twitter. В 2009 году червь StalkDaily
распространился по всему твиттеру. Когда пользователь Twitter заходил на страницу профиля зараженного пользователя, его страница профиля также заражалась, распространяя червя. Червь также рассылал твиты с каждого зараженного аккаунта.
Итак, как именно работал червь StalkDaily? Кто-то взломал веб-серверы Twitter? Не совсем — хотя это был своего рода взлом.
Каждый пользователь Twitter может установить небольшую биографию на странице своего профиля. Пользователи вводят текст в поле профиля, и после сохранения профиля текст отображается на странице профиля. Кто-то понял, что Twitter неправильно очищает ввод текста из биобокса (мы вернемся к этому позже) — он просто поместил текстовые пользователи, введенные непосредственно в исходный код веб-страницы. Это позволило пользователю ввести тег HTML, который загружает файл JavaScript со стороннего веб-сервера.
Когда другой пользователь Twitter зашел на страницу зараженного профиля, его браузер загрузил скрипт. Сценарий имел полный доступ ко всему, что использовался на странице официальным кодом Twitter, поэтому он мог запрашивать cookie-файл пользователя Twitter (в котором хранится состояние входа пользователя) и имя пользователя из браузера. Затем сценарий отправил эту информацию обратно на сторонний веб-сервер. С этими подробностями сторонний веб-сервер может аутентифицироваться как пользователь Twitter, изменять биографию пользователя для распространения червя и отправлять твиты из учетной записи пользователя.
Как разработчики могут предотвратить атаки XSS
Одно простое правило позволяет веб-разработчикам
для предотвращения атак с использованием межсайтовых сценариев: не доверяйте никаким данным, поступающим от пользователей. Например, в случае с Twitter они не должны были доверять текстовым пользователям, введенным в их биобоксы. Твиттер должен был взять текст и «очистить» или «избежать» его — например, должен быть изменен на <скрипт> — он будет отображаться как на странице, но не будет работать как 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 полностью — Хотя здесь, в MakeUseOf, нам не особенно нравится NoScript
Отключение JavaScript полностью исключает атаки XSS. К сожалению, отключение JavaScript также устраняет множество других вещей, которые нам нравятся в современном Интернете, и многие сайты не будут работать должным образом без включенного JavaScript.
Был ли у вас опыт работы с XSS-атаками? Оставьте комментарий и поделитесь своим опытом — если у вас есть какие-либо вопросы об уязвимостях XSS, мы также будем рады ответить на них.
Image Credit: 3D-коммуникация с помощью Shutterstock
