Использование заголовков безопасности является важным звеном в защите сайта и его посетителей от хакерских атак. В прошлой статье про из рубрики по защите и безопасности я обещал регулярно публиковать записи на эту тему. Сегодня я расскажу про защиту от XSS атаки.
Что такое XSS-атака
Межсайтовый скриптинг (Cross Site Scripting) — это уязвимость, которая позволяет злоумышленнику внедрить вредоносный код (обычно HTML или JavaScript) в содержимое сайта. Вредоносный код выполняется в браузере пользователя, который просматривает зараженную страницу сайта.
Злоумышленники могут эксплуатировать различные уязвимости. Наибольшее распространение получили два типа атаки:
- Отражённая (Reflected XSS) — самый распространенный непостоянный тип атаки, требующий выполнения определённого действия со стороны пользователя.
- Хранимая (Persistent XSS) — постоянный тип атаки с внедрением вредоносного кода на сервер, не требует вмешательства пользователя.
Отражённая XSS-атака
Срабатывает при переходе пользователя по специально подготовленной ссылке, которая отправляет запрос на сайт с уязвимостью. Данная уязвимость обычно является результатом недостаточной фильтрации входящих запросов, что позволяет манипулировать функциями и активировать вредоносные скрипты.
- Злоумышленник внедряет в гиперссылку вредоносный скрипт, позволяющий просматривать cookies пользовательской сессии, и отправляет жертве по электронной почте или другим средствам коммуникации.
- При переходе по ссылке пользователь становится захваченным.
- Скрипт выполняется в браузере пользователя.
- Браузер отправляет cookies злоумышленнику, обеспечивая доступ к личным данным пользователя.
Хранимая XSS-атака
Для успешного выполнения хранимой атаки злоумышленнику достаточно найти уязвимость на сайте и разместить на своём сервере вредоносный скрипт. Затем на сайте размещается тег
Данный скрипт вызывает окно с надписью «ЭТО XSS-УЯЗВИМОСТЬ!!!». Браузер пользователя воспринимает и выполняет этот скрипт как часть легитимного кода сайта.
Типы XSS-уязвимостей
Не все уязвимости XSS одинаковы, их существует множество типов. Здесь перечислены типы и способы их взаимодействия:
Рисунок 3. Типы XSS-уязвимостей
Уязвимости, вызванные кодом на стороне сервера (Java, PHP, .NET и т. д.):
Традиционные XSS-атаки:
- Отраженные (непостоянные). Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке. Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
- Хранимые (постоянные). Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.
Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.):
Также известные как DOM-модели:
- Отраженные (непостоянные). То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
- Хранимые (постоянные). Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.
Уязвимости, вызванные инфраструктурой (браузер, плагины, сервера и т. д.):
Встречаются очень редко, но являются более опасными:
- Инфраструктура на стороне клиента. Происходит, когда вредоносная составляющая производит какие-либо манипуляции с функционалом браузера, например с его XSS-фильтром и т.п.
- Инфраструктура на стороне сервера. Возникает, когда веб-сервер некорректно обрабатывает запросы, позволяя модифицировать их.
- Сеть. Происходит, когда возможно внедриться в связь между клиентом и сервером.
Уязвимости, вызванные пользователем:
- Само-XSS. Часто происходит в результате социальной инженерии, когда пользователь случайно запускает вредоносный код в своем браузере.
В чем опасность XSS?
Как можно защитить свой сайт от XSS? Как проверить код на наличие уязвимости? Существуют технологии вроде Sucuri Firewall, специально разработанные для того, чтобы избежать подобных атак. Но если вы разработчик, вы, безусловно, захотите узнать подробнее, как идентифицировать и устранить XSS-уязвимости. Об этом мы поговорим в следующей части статьи, посвященной XSS.
Межсайтовый скриптинг (сокращенно XSS) - широко распространенная уязвимость, затрагивающая множество веб-приложений. Она позволяет злоумышленнику внедрить вредоносный код в веб-сайт таким образом, что браузер пользователя, зашедшего на сайт, выполнит этот код.
Обычно для эксплуатации подобной уязвимости требуется определенное взаимодействие с пользователем: либо его заманивают на зараженный сайт при помощи социальной инженерии, либо просто ждут, пока тот сам посетит данный сайт. Поэтому разработчики часто не воспринимают всерьез XSS-уязвимости.
Но если их не устранять, это может нести серьезную угрозу безопасности.
Представим, что мы находимся в панели администратора WordPress, добавляем новый контент. Если мы используем для этого уязвимый к XSS плагин, он может заставить браузер создать нового администратора, видоизменить контент и выполнить другие вредоносные действия. Межсайтовый скриптинг предоставляет злоумышленнику практически полный контроль над самым важным программным обеспечением в наши дни - браузером.
XSS: Уязвимость для инъекции
Любой веб-сайт или приложение имеет несколько мест ввода данных -полей формы до самого URL. Простейший пример вводимых данных - когда мы вписываем имя пользователя и пароль в форму:
Наше имя будет храниться в базе данных сайта для последующего взаимодействия с нами. Наверняка, когда вы проходили авторизацию на каком-либо сайте, вы видели персональное приветствие в стиле «Добро пожаловать, Илья».
Именно для таких целей имена пользователей хранятся в базе данных.
Инъекцией называется процедура, когда вместо имени или пароля вводится специальная последовательность символов, заставляющая сервер или браузер отреагировать определенным, нужным злоумышленнику образом.
Межсайтовым скриптингом называется инъекция, внедряющая код, который будет выполнять действия в браузере от имени веб-сайта. Это может происходить как с уведомлением пользователя, так и в фоновом режиме, без его ведома.
Традиционные XSS-атаки:
Отраженные (непостоянные).
Отраженная XSS-атака срабатывает, когда пользователь переходит по специально подготовленной ссылке.
Эти уязвимости появляются, когда данные, предоставленные веб-клиентом, чаще всего в параметрах HTTP-запроса или в форме HTML, исполняются непосредственно серверными скриптами для синтаксического анализа и отображения страницы результатов для этого клиента, без надлежащей обработки.
Хранимые (постоянные).
Хранимые XSS возможны, когда злоумышленнику удается внедрить на сервер вредоносный код, выполняющийся в браузере каждый раз при обращении к оригинальной странице. Классическим примером этой уязвимости являются форумы, на которых разрешено оставлять комментарии в HTML-формате.
Уязвимости, вызванные кодом на стороне клиента (JavaScript, Visual Basic, Flash и т. д.):
Также известные как DOM-модели:
Отраженные (непостоянные).
То же самое, что и в случае с серверной стороной, только в этом случае атака возможна благодаря тому, что код обрабатывается браузером.
Хранимые (постоянные).
Аналогичны хранимым XSS на стороне сервера, только в этом случае вредоносная составляющая сохраняется на клиентской стороне, используя хранилище браузера.
Примеры XSS уязвимостей.
Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:
Http://www.site.com/page.php?var=
Существует два типа XSS уязвимостей - пассивная и активная.
Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.
Пример пассивной уязвимости можно посмотреть в самом начале статьи. Тут уже нужна социальная инженерия, например, важное письмо от администрации сайта с просьбой проверить настройки своего аккаунта, после восстановления с бэкапа. Соответственно, нужно знать адрес жертвы или просто устроить спам-рассылку или разместить пост на каком-нибудь форуме, да еще и не факт что жертвы окажутся наивными и перейдут по вашей ссылке.
Причем пассивной уязвимости могут быть подвержены как POST так и GET-параметры. С POST-параметрами, понятно, придется идти на ухищрения. Например, переадресация с сайта злоумышленника.