Категории
Оглавление

XSS-атака

Що ви знаєте про XSS-атаки? З їх допомогою шкідливий код можна без особливих проблем впровадити на сайт і отримати доступ до сервера. Тому новий матеріал буде вкрай корисним для вебмайстрів усіх рівнів. Клікаємо за посиланням нижче, переходимо та читаємо.

Що таке XSS-атака

XSS-атака — це один із видів атак на онлайн-системи, який перекладається як «міжсайтовий скриптинг». Такі атаки мають на увазі впровадження вірусу в код сайту-жертви з подальшим отриманням доступу до віддаленого сервера після відкриття зараженої сторінки користувачем. Взагалі абревіатура розшифровується, як Cross-Site Scripting, але прийнято говорити саме «XSS-атака», адже інакше виникне плутанина з CSS.

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

Ключова мета XSS – вкрасти cookie користувача за допомогою вбудованого на сервер скрипту. Після отримання цих даних зловмисник проводить їх вибірку, сортування, а потім використовує для подальших атак та зламів із застосуванням іншого програмного забезпечення та підходів. При цьому атака виконується не безпосередньо, а через «дірки» (уразливості) сайту, на який заходять користувачі-жертви. При цьому атакований сайт стає по суті мимовільним співучасником злочину.

XSS-атаки безпечні для сервера, де знаходиться сайт, але несуть загрозу безпосередньо відвідувачам цього сайту. Але трапляється і таке, що зловмиснику вдається вкрасти дані адміністратора зараженого ресурсу і, як наслідок, він отримує повний доступ до адмінки та вмісту сайту. Крім того, якщо пошукові системи виявлять на сайті шкідливий код, цьому проекту 100% загрожує песимізація.

Метод реалізації XSS-атаки

Шкідливий код для здійснення міжсайтового скриптингу пишеться мовою JavaScript і запуститися він може лише у браузері жертви. Тому ресурс, який відкриває користувач, повинен бути незахищеним від XSS (бути вразливим до таких атак).

Тому, щоб зробити XSS, насамперед зловмисник проводить пошук сайтів, вразливих до скриптингу. Робиться це вручну через пошук, або за допомогою автоматизованих додатків. Як правило, тестуються стандартні форми, через які виконується відправка/прийом запитів: система пошуку по сайту, коментарі, зворотний зв’язок тощо. Зазвичай зловмисники перевіряють на вразливість до XSS через Internet Explorer.

У ході такого «дослідження» виконується збір даних зі сторінок із формами введення та кожна з таких сторінок сканується на наявність уразливостей до XSS. Наприклад, на вашому сайті є сторінка для пошуку по блозі. Щоб перевірити її на вразливість до скрипту, потрібно використати запит:

<script>alert(“cookie: “+document.cookie)</script>

Якщо на дисплеї з’являється вікно з повідомленням про виявлену вразливість, потрібно терміново вживати заходів. Якщо пролому немає, ви просто побачите звичну сторінку з пошуком.

Якщо сайт управляється якоюсь популярною CMS, то проломи бути не повинно, тому що сучасні системи керування контентом сайту надійно захищені від XSS. Але, якщо ви розширювали функціональні можливості свого сайту за допомогою будь-яких плагінів, модулів та доповнень, розроблених сторонніми веб-програмістами, є ризик виявлення вразливості до XSS. А особливо це стосується доробок для WordPress, Joomla, DLE та Bitrix.

Альтернативний варіант пошуку пролому на сайті – використання сторінок, що працюють із GET-запитами. Наприклад, маємо посилання http://site.com/catalog?p=7. У браузерному рядку замість ідентифікатора «7» ми вписуємо скрипт “><script>alert(“cookie: “+document.cookie)</script>”, після чого отримуємо посилання виду http://site.com/catalog?p=” ><script>alert(“cookie: “+document.cookie)</script>. Якщо на цій сторінці буде виявлено вразливість, на дисплеї з’явиться повідомлення з інформацією.

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

Класифікація XSS

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

1. Постійні (збережені)

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

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

2. Непостійні (відбиті)

У такому разі шкідливий скрипт відіграє роль запиту жертви до сайту з вірусом. Все функціонує за такою схемою:

  • Зловмисником формується УРЛ, що містить шкідливий код.
  • Цей УРЛ відправляється жертві, яка кликає ним і переходить на сайт.
  • Сайт автоматично отримує інформацію зі шкідливого УРЛу та підставляє жертві відповідь у вигляді модифікованого УРЛу.
  • В результаті браузер на комп’ютері жертви виконує скрипт зловмисниками і отримує всі куки користувача.

3. DOM

Це певний суміщений варіант, що передбачає використання і непостійних, і постійних XSS-атак. Працює така методика так:

  • Зловмисником формується посилання, на яке заздалегідь «вішується» шкідливий код.
  • Це посилання відправляється потенційній жертві будь-яким доступним методом: електронною поштою, через месенджер, чат тощо.
  • Жертва кликає за посиланням та переходить на заражений сайт. Цей сайт приймає запит без шкідливого рядка.
  • На стороні користувача виконується шкідливий код, завантажується скрипт і зловмиснику стають доступні куки жертви.

Типи XSS за методом взаємодії

У зловмисника є одна головна мета – змусити жертву запустити шкідливий код на своєму комп’ютері. І спираючись на цей факт, можна виділити ще два види XSS-атак – за методом взаємодії.

Активні

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

Наприклад, форми введення даних. Зазвичай вони мають певні обробники подій, які автоматично запускаються, коли користувач відкриває сторінку. І як підсумок – абсолютно всі користувачі, які відкриють цю сторінку, стануть жертвами зловмисника.

Пасивні

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

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

Перевірка сайту на наявність уразливості до XSS та захист від атак

Щоб швидко перевірити свій сайт на вразливість до XSS-атак, можна використовувати спеціальні сервіси, які автоматично просканують ресурс та всі його сторінки. Обов’язково потрібно перевіряти всі посилання сайту, які використовуються для відправки даних з боку відвідувача (форми зворотного зв’язку, будь-які інші форми, поля для коментування, рядок пошуку і т.п.). Але тут важливо розуміти, що обмежуватись якимось одним сервісом не можна. Тобто тут потрібен комплексний підхід – так само, як при аудиті сайту.

Також потрібно розуміти, що ніякі сервіси не здатні дати максимально повну інформацію про ресурс та його «дірки», тому додатково слід протестувати потенційно вразливі сторінки вручну. Паралельно потрібно прибрати всі небезпечні спецсимволи, замінивши їх на альтернативні безпечні (наприклад, дужки <>, в яких прописуються HTML-теги та запити). Якщо таких символів дуже багато, можна виконати швидку фільтрацію та автозаміну. Для цього використовуйте на своєму сайті код:

$filter = array(“<“, “>”);

$_GET[‘q’]=str_replace ($filter, “|”, $_GET[‘q’]).

Ще кілька корисних порад щодо «збереження» свого проекту від XSS-атак:

  • Якщо на сторінках ресурсу використовується введення даних з боку користувача, обов’язково потрібно включити кодування цих даних.
  • Якщо з якихось причин кодування використовувати не можна (наприклад, це просто недоречно у конкретному випадку), потрібно замінити його на валідацію.
  • Обробка даних завжди повинна виконуватись у коді максимально безпечно. І це стосується не лише сервера, на якому працює сайт, а й браузера клієнта.
  • Використовуючи для керування сайтом одну з найпопулярніших CMS (WordPress, Joomla, Bitrix і т.п.), потрібно постійно оновлювати двигун і всі встановлені на ньому додатки, плагіни, модулі, розширення тощо. І пам’ятайте – всі сучасні системи для керування контентом сайту вже мають вбудований захист від XSS-атак, але плагіни та інші допоміжні «плюшки» можуть не мати такого захисту. Тому завантажувати доповнення потрібно лише з перевірених джерел.