Магазин
Меню
XSS (міжсайтовий скриптинг) – один із різновидів атак на веб-системи, що передбачає впровадження шкідливого коду на певну сторінку сайту та взаємодію цього коду з віддаленим сервером зловмисників при відкритті сторінки користувачем.
Термін з англійської розшифровується як Cross-Site Scripting, але отримав абревіатуру XSS, щоб не було плутанини з CSS (каскадні таблиці стилів).
Як працює міжсайтовий скриптинг
Основна мета міжсайтового скриптингу – крадіжка cookies користувачів за допомогою вбудованого на сервері скрипту з подальшою вибіркою необхідних даних та використанням їх для наступних атак та зломів. Зловмисник здійснює атаку користувачів не безпосередньо, а з використанням уразливостей веб-сайту, який відвідують жертви, та впроваджує спеціальний JavaScript. У браузері в користувачів цей код відображається як єдина частина сайту. При цьому відвідуваний ресурс є співучасником XSS-атаки.
Якщо порівнювати з SQL-ін’єкціями, XSS безпечний для сервера, але несе загрозу для користувачів зараженого ресурсу або сторінки. Однак, якщо до зловмисника потраплять cookies адміністратора, можна отримати доступ до панелі керування сайтом та його вмісту.
Методика атаки
Запуск шкідливого коду JavaScript можливий тільки в браузері жертви, тому сайт, на який користувач зайде, повинен мати вразливість до XSS. Для атаки зловмисник спочатку перевіряє ресурси на наявність уразливостей через XSS, використовуючи автоматизовані скрипти або ручний режим пошуку. Зазвичай це стандартні форми, які можуть надсилати та приймати запити (коментарі, пошук, зворотний зв’язок).
Проводиться повний збір сторінок із формами введення, і кожна сканується на наявність уразливостей. Наприклад, у нас є сторінка “Пошук” на сайті. Для перевірки вразливості XSS достатньо ввести запит:
<script>alert(“cookie: “+document.cookie)</script>
Якщо на екрані з’явиться повідомлення, ви виявили пролом в безпеці. В іншому випадку система відобразить сторінку з результатами пошуку. Основні популярні CMS вже давно втратили подібні проблеми, але через можливість розширення функціоналу за рахунок модулів і плагінів, створюваних сторонніми розробниками, шанси на використання вразливостей XSS зростають у рази, особливо в Joomla, DLE, Bitrix, WordPress. Найчастіше XSS-уразливості перевіряються у браузері Internet Explorer.
Ще один можливий варіант пошуку – використання сторінок, які опрацьовують GET-запити. Допустимо, у нас є посилання виду: https://site.ua/catalog?p=8
В адресному рядку замість ідентифікатора (8) додаємо скрипт – “><script>alert(“cookie: “+document.cookie)</script>”, в результаті чого отримуємо посилання такого виду: https://site.ua/catalog? p="><script>alert("cookie:”+document.cookie)</script>
Якщо сторінка має вразливість XSS, на екрані з’явиться повідомлення такого самого плану, як у першому випадку.
Для пошуку «дір» на сайті існує безліч готових скриптів і запитів, і якщо жоден з них не підходить, значить ресурс надійно захищений від подібних атак.
Загальна класифікація
Чіткої класифікації для міжсайтового скриптингу не існує, але експертами по всьому світу виділено три основні типи.
Збережені XSS (постійні). Один із найнебезпечніших типів уразливостей, оскільки дозволяє зловмиснику отримати доступ до сервера і вже з нього керувати шкідливим кодом (видаляти, модифікувати). Щоразу при зверненні до сайту виконується заздалегідь завантажений код, що працює автоматично. В основному таким вразливостями зазнають форуми, портали, блоги, де є можливість коментування в HTML без обмежень. Шкідливі скрипти з легкістю можуть бути вбудовані як у текст, так і картинки, малюнки.
Відбиті XSS (непостійні). У цьому випадку шкідливий рядок виступає в ролі запиту жертви до зараженого сайту. Працює цей принцип за наступною схемою:
- Зловмисник заздалегідь створює URL-посилання, яке міститиме шкідливий код і відправляє його своїй жертві.
- Вона надсилає цей URL-запит на сайт (переходить за посиланням).
- Сайт автоматично бере дані зі шкідливого рядка та підставляє у вигляді модифікованої URL-відповіді жертві.
- У результаті в браузері у жертви виконується шкідливий скрипт, який міститься у відповіді, а зловмисник отримує всі cookies цього користувача.
DOM моделі. У цьому варіанті можливе використання як збережених XSS, так і відбитих. Суть полягає в наступному:
- Зловмисник створює URL-адресу, яка заздалегідь містить шкідливий код, і надсилає його електронною поштою або будь-яким іншим способом користувачеві.
- Людина переходить за цим посиланням, заражений сайт приймає запит, крім шкідливого рядка.
- На сторінці користувача виконується сценарій, в результаті чого завантажується шкідливий скрипт і зловмисник отримує cookies.
Види XSS за способом взаємодії
Оскільки основна мета зловмисника – запустити шкідливий скрипт на комп’ютері жертви, існує ще й два основні типи XSS-атак за способом взаємодії.
- Пасивні. Від жертви потрібна певна дія, щоб викликати обробник подій та запустити шкідливий скрипт у встановленій формі. Для цього використовується соціальна інженерія, наприклад, відправлення електронного листа із закликом перейти за посиланням і натиснути на певну область на сайті. Як тільки користувач наведе на потрібний об’єкт і натисне на нього, запуститься шкідливий скрипт. Якщо ж жертва не діє, код не буде активовано.
- Активні. Зловмиснику не потрібно заманювати жертву за спеціальними посиланнями, оскільки код вбудовується в базах даних або в якому-небудь файлі на сервері. Від користувача не вимагається активності. У формах введення, як правило, встановлений спеціальний обробник подій, що автоматично активується при попаданні на цю сторінку. У результаті всі користувачі, які перейшли за цим посиланням, стануть жертвами зловмисника.
Як перевірити сайт на наявність вразливостей XSS та захистити його
Для швидкої перевірки сайту на наявність вразливостей XSS можна скористатися спеціалізованими сервісами, які автоматично проведуть сканування сторінки. В обов’язковому порядку потрібно перевіряти всі URL, де можливе надсилання даних з боку користувача (форми коментарів, зворотний зв’язок, пошук). Як приклад, можете використовувати https://xss-scanner.com, але не варто обмежуватися лише одним інструментом.
Подібні сервіси не дають повної гарантії успіху, тому рекомендуємо перевіряти знайдені сторінки в ручному режимі та обов’язково виключити всі небезпечні спецсимволи, замінивши їх безпечними. Йдеться про дужки < і >, у яких і прописуються всі зарезервовані мовою html-запити та теги.
Наприклад, для швидкої фільтрації та автоматичної заміни спецсимволів < і > ви можете використовувати наступний код на сайті:
$filter = array(“<“, “>”);
$_GET[‘q’]=str_replace ($filter, “|”, $_GET[‘q’]).
Декілька порад щодо запобігання використанню XSS на вашому сайті:
- Встановіть систему безпеки UKEY SECURITY, вона в автоматичному режимі розпізнає та блокує XSS-загрози.
- Якщо на вашому сайті включено введення користувача, повинно виконуватися кодування.
- Якщо кодування неможливе або недоречне в деяких ситуаціях, замінюйте його або доповнюйте валідацією.
- Безпечна обробка даних повинна виконуватись у коді не лише на стороні вашого web-сервера, а й на стороні користувача (клієнта).
- Якщо використовуєте популярні CMS, наприклад WordPress, Bitrix, Joomla, регулярно оновлюйте версії движка та всіх встановлених модулів та плагінів. За умовчанням більшість найпоширеніших систем для керування сайтів захищені від використання XSS, а ось сторонні плагіни з неперевірених джерел можуть містити вразливість.