Десятая глава. Межсайтовый скриптинг (XSS)

Автор: Peter Yaworski

Переводчик: Летучий дракон

Протокол: CC BY-NC-SA 4.0

Описание

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

alert('XSS');

Этот код вызывает функцию alert языка JavaScript и создаёт простое всплывающее окно с текстом «XSS». В предыдущей версии этой книги я рекомендовал использовать этот пример в отчётах. Однако один очень успешный хакер сказал мне, что это плохой пример, потому что получатель уязвимости обычно не осознаёт серьёзность проблемы и может получить низкую награду из-за безобидного примера.

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

Это должно включать в себя определение того, какой тип XSS вы обнаружили, включая:

• Отражённый XSS: эти атаки не являются постоянными, то есть XSS передаётся и выполняется через простые запросы и ответы.

• Хранимый XSS: эти атаки являются постоянными или сохранёнными и выполняются позже при загрузке страницы для неосведомлённого пользователя.

• Само XSS: эти атаки также не являются постоянными и обычно используются в качестве шутки над пользователями, заставляя их выполнять XSS самостоятельно.

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

Если вы обнаружите сценарий, в котором Self XSS может быть выполнен, но не сохранён, вам следует подумать, можно ли его использовать, и есть ли что-то, что можно объединить, чтобы он больше не был Self XSS?

Одним из самых известных примеров использования XSS является червь Samy Kamkar MySpace. В октябре 2005 года Samy использовал уязвимость хранимого XSS на MySpace, которая позволяла ему загружать код JavaScript. Этот код впоследствии выполнялся любым пользователем, просматривающим страницу профиля Samy, превращая любого друга Samy в своего друга. Однако более того, этот код также копировал себя на страницу нового друга Samy, так что любой, кто просматривал страницу нового друга, использовал следующий текст для обновления своей страницы профиля: «but most of all, samy is my hero» («Самое главное, Сэми — мой герой»).

Хотя использование Samy не было полностью злонамеренным, использование XSS позволило ему украсть пользовательские данные, пароли и банковскую информацию. Хотя это имеет потенциальные последствия, исправление уязвимостей XSS обычно довольно просто, требуя от разработчика программного обеспечения экранировать вводимые пользователем данные во время рендеринга (аналогично HTML-инъекциям). Некоторые сайты также будут обрезать потенциально вредоносные символы при отправке злоумышленниками.

Ссылка

См. OWASP XSS Filter Evasion Cheat Sheet.

Примеры

1. Shopify Wholesale

Сложность: низкая

URL: wholesale.shopify.com

Ссылка на отчёт: https://hackerone.com/reports/106293

Дата отчёта: 21 декабря 2015 г.

Награда: $500

Описание:

Сайт Shopify Wholesale представляет собой простую страницу с различными операциями вызова — ввод названия товара и нажатие кнопки «поиск товара», вот скриншот:

Скриншот сайта Shopify Wholesale

Здесь уязвимость XSS заключается в том, что текст, который вы вводите в поле поиска, не экранируется, поэтому любой введённый вами код JavaScript будет выполнен. Вот текст, раскрытый в уязвимости: test’;alert(‘XSS’);’.

Причина, по которой это работает, заключается в том, что Shopify получает пользовательский ввод, выполняет поисковый запрос, и если результат не возвращается, Shopify печатает сообщение, говорящее, что название не найдено, а затем повторно печатает пользовательский ввод без какого-либо экранирования. Поэтому введённый код JavaScript печатается на странице, и браузер интерпретирует его как код JavaScript и выполняет его.

Важный вывод

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

Уязвимости XSS не обязательно должны быть сложными. Эта уязвимость — самое основное, что вы найдёте — простое текстовое поле ввода, которое не обрабатывает пользовательский ввод. Оно было обнаружено 21 декабря 2015 года и получило награду в размере 500 долларов. Всё, что ему нужно, — это мышление хакера.

2. Shopify Gift Card Shopping Cart

Сложность: низкая

URL: hardware.shopify.com/cart

Ссылка на отчёт: https://hackerone.com/reports/95089

Дата отчёта: 21 октября 2015 г.

Награда: $500

Описание:

На сайте Shopify Gift Card пользователи могут использовать HTML-формы для создания собственных подарочных карт, включая поля загрузки, текстовые поля и другие. Вот скриншот:

Скриншот формы подарочной карты Shopify

Уязвимость XSS здесь возникает при вводе JavaScript в поле имени файла изображения. После выполнения через прокси-сервер появляется простая задача. Итак, исходный файл формы будет содержать:

Content-Disposition: form-data; name="properties[Artwork file]"

Который будет интерпретирован и изменён на:

Content-Disposition: form-data; name="properties[Artwork file<img src='test' onm\ ouseover='alert(2)'>]";

Важные выводы

Здесь есть две вещи, на которые следует обратить внимание, которые помогут вам при поиске уязвимостей XSS:

1. На самом деле уязвимость находится не в самом поле файла, а в атрибуте имени поля. Поэтому, когда вы ищете возможности XSS, помните, что нужно проверять все доступные входные значения.

2. Здесь значение отправляется после прохождения через прокси. В некоторых сценариях это является ключевым моментом, поскольку клиент (ваш браузер) может иметь код JavaScript для проверки значений перед отправкой на сервер, поскольку они считают, что код JavaScript браузера уже проверил ввод до получения сервером.

Фактически, всякий раз, когда вы видите проверку в реальном времени в вашем браузере, это сигнал к тому, что вам нужно протестировать это поле! Разработчики могут совершить эту ошибку, полагая, что после того, как эти значения будут отправлены на сервер, они не будут проверены на наличие вредоносного кода, поскольку считают, что проверка была выполнена кодом JavaScript браузера до того, как значения были получены сервером.

3. Shopify Currency Format

Сложность: низкая

URL: SITE.myshopify.com/admin/settings/generalt

Ссылка на отчёт: https://hackerone.com/reports/104359

Дата отчёта: 9 декабря 2015 г.

Награда: $1000

Описание:

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

Другими словами, злонамеренный пользователь может создать магазин и изменить формат валюты на следующее:

Формат валюты Shopify

Затем пользователь может активировать канал продаж в социальной сети. Примером в отчёте являются Facebook и Twitter, и когда пользователь нажимает на опцию канала продаж, JavaScript выполняется, создавая уязвимость XSS.

Важный вывод

Уязвимость XSS возникает, когда код JavaScript отображается небезопасно. Текст может использоваться на нескольких страницах сайта, поэтому каждый должен быть проверен. Здесь Shopify не включает XSS в магазине и на кассе, потому что пользователи разрешены для использования JavaScript на своих магазинах. Легко пропустить эту уязвимость, прежде чем рассматривать, используется ли она на внешних страницах социальных сетей. Перевод текста на русский язык:

HTML из состояния с checked значением перешёл в состояние без значения, но всё ещё содержит знак равенства.

Это выглядит безобидно, но согласно HTML-спецификации, браузер будет рассматривать CHECKED как имеющий значение NAME="check", и у этого input-тега есть третий атрибут box, который не имеет значения. Это относится к атрибутам без кавычек, поскольку HTML допускает ноль или более пробелов вокруг знака равенства.

Чтобы использовать это, Jouko отправил следующий тег IMG:

<img ismap='xxx' itemtype='yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//'>

Yahoo Mail преобразует его в:

<img ismap=itemtype=yyy style=width:100%;height:100%;position:fixed;left:0px;top:0px; onmouseover=alert(/XSS/)//>

Таким образом, браузер отобразит тег IMG, который занимает весь экран браузера, и при наведении курсора мыши на изображение будет выполняться JavaScript.

Важный вывод

Передача неправильно отформатированного или повреждённого HTML является эффективным способом тестирования того, как сайт обрабатывает ввод данных. Для хакера важно учитывать то, что разработчики могли упустить из виду. Например, используя обычный тег изображения, что произойдёт, если вы передадите два src-атрибута? Как он будет отображаться?

5. Поиск изображений Google

Сложность: средняя

URL: images.google.com

Ссылка на отчёт: http://zombiehelp54.blogspot.ca/2015/09/how-i-found-xss-vulnerability-in-google.html

Дата отчёта: 2015.09.12

Награда: неизвестна

Описание:

В 2015 году Махмуд Джамал использовал Google Images для поиска уязвимости в системе безопасности в рамках программы HackerOne. Во время просмотра он заметил интересные вещи в URL-адресе Google Images.

http://www.google.com/imgres?imgurl=https://lh3.googleuser.com/...

Он обратил внимание на наличие ссылки imgurl в фактическом URL. Когда он навёл курсор мыши на уменьшенное изображение, Махмуд заметил, что якорь href-атрибут содержит тот же URL. Поэтому он попытался изменить параметр на javascript:alert(1), и заметил, что href якоря также изменился на то же значение.

Махмуд был очень взволнован этим открытием и нажал на ссылку, но JavaScript не выполнился, потому что Google изменил URL. В результате код Google при нажатии кнопки мыши через onmousedown JavaScript-обратный вызов изменил URL.

Учитывая это, Махмуд решил использовать клавиатуру и попытался использовать клавишу TAB для переключения по странице. Когда он добрался до кнопки «View Image», это вызвало JavaScript и создало уязвимость XSS. Вот изображение:

Уязвимость XSS в Google

Важный вывод

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

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

6. Google Tagmanager — XSS хранения

Сложность: средняя

URL: tagmanager.google.com

Ссылка на отчёт: https://blog.it-securityguard.com/bugbounty-the-5000-google-xss

Дата отчёта: 2014.10.31

Награда: $5000

Описание:

В октябре 2014 года Патрик Ферхебах обнаружил уязвимость хранения XSS на Google. Интересная часть этого отчёта заключается в том, как ему удалось обойти защиту Google.

Google Tagmanager — это инструмент SEO, который упрощает добавление и обновление тегов на сайте, включая отслеживание конверсий, анализ сайта, ремаркетинг и многое другое. Для этого у него есть множество форм для взаимодействия с пользователями. Поэтому Патрик попытался ввести полезную нагрузку XSS в поле формы, похожее на #><img src=/ onerror=alert(3)>. Если бы это было принято, это закрыло бы существующий HTML >, а затем попыталось загрузить несуществующее изображение, которое выполнило бы onerror JavaScript alert(3).

Однако это не сработало. Google разумно обработал ввод. Патрик заметил альтернативный вариант — Google предоставляет возможность загружать файлы JSON с несколькими тегами. Поэтому он скачал пример и загрузил его:

"data": { 
    "name": "#"><img src=/ onerror=alert(3)>", 
    "type": "AUTO_EVENT_VAR", 
    "autoEventVarMacro": { 
        "varType": "HISTORY_NEW_URL_FRAGMENT" 
    } 
}

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

Важный вывод

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

Резюме

Уязвимости XSS представляют собой реальную угрозу для разработчиков сайтов и продолжают существовать на сайтах, часто оставаясь незамеченными. Обычно достаточно отправить вызов метода JavaScript alert, например, alert('test'), чтобы проверить, есть ли уязвимость на поле ввода. Кроме того, вы можете комбинировать его с HTML-инъекцией и отправлять закодированные ASCII-символы для наблюдения за тем, отображаются ли они и интерпретируются ли.

При поиске уязвимостей XSS следует помнить о некоторых вещах:

1. Тестируйте всё

Независимо от того, какой сайт вы просматриваете и когда вы его просматриваете, всегда будьте готовы к поиску уязвимостей! Не думайте, что сайт слишком большой или сложный, чтобы иметь уязвимости. Возможность может быть прямо перед вами, ожидая вашего теста, как это было с wholesale.shopify.com. Уязвимость Google Tagmanager хранения XSS возникла в результате поиска альтернативных способов добавления тегов на сайт.

2. Уязвимости могут существовать в любом поле формы

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

3. Всегда используйте HTML-прокси во время тестирования

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

4. Уязвимости XSS возникают во время рендеринга

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

5. Проверяйте неожиданные значения

Не всегда предоставляйте ожидаемые типы значений. Когда была обнаружена уязвимость HTML Yahoo Mail, были предоставлены неожиданные атрибуты HTML IMG. Выйдите за рамки привычного мышления и подумайте о том, что разработчик хочет найти, а затем попробуйте предоставить некоторые вещи, которые не соответствуют этим ожиданиям. Это включает в себя поиск новых способов выполнения потенциального JavaScript, таких как обход события onmousemove Google Images.