XSSI (Cross-Site Script Inclusion)
Basic Information
Cross-Site Script Inclusion (XSSI) — це вразливість, яка виникає через природу тегу script
в HTML. На відміну від більшості ресурсів, які підлягають Політиці одного походження (SOP), скрипти можуть бути включені з різних доменів. Ця поведінка призначена для полегшення використання бібліотек та інших ресурсів, розміщених на різних серверах, але також вводить потенційний ризик безпеки.
Key Characteristics of XSSI:
Bypass of SOP: Скрипти звільнені від Політики одного походження, що дозволяє їх включення між доменами.
Data Exposure: Зловмисник може використати цю поведінку для читання даних, завантажених через тег
script
.Impact on Dynamic JavaScript/JSONP: XSSI особливо актуально для динамічного JavaScript або JSON з доповненням (JSONP). Ці технології часто використовують інформацію "ambient-authority" (таку як куки) для аутентифікації. Коли запит скрипта надсилається на інший хост, ці облікові дані (наприклад, куки) автоматично включаються в запит.
Authentication Token Leakage: Якщо зловмисник може обманути браузер користувача, щоб той надіслав запит на скрипт з сервера, який він контролює, він може отримати доступ до чутливої інформації, що міститься в цих запитах.
Types
Static JavaScript - Це представляє собою звичайну форму XSSI.
Static JavaScript with Authentication - Цей тип відрізняється тим, що вимагає аутентифікації для доступу.
Dynamic JavaScript - Включає JavaScript, який динамічно генерує контент.
Non-JavaScript - Відноситься до вразливостей, які не пов'язані безпосередньо з JavaScript.
Наступна інформація є резюме https://www.scip.ch/en/?labs.20160414. Перевірте її для отримання додаткових деталей.
Regular XSSI
У цьому підході приватна інформація вбудована в глобально доступний JavaScript файл. Зловмисники можуть виявити ці файли, використовуючи методи, такі як читання файлів, пошук за ключовими словами або регулярні вирази. Після знаходження скрипт, що містить приватну інформацію, може бути включений у шкідливий контент, що дозволяє несанкціонований доступ до чутливих даних. Приклад техніки експлуатації наведено нижче:
Dynamic-JavaScript-based-XSSI та Authenticated-JavaScript-XSSI
Ці типи атак XSSI передбачають динамічне додавання конфіденційної інформації до скрипту у відповідь на запит користувача. Виявлення може бути виконано шляхом надсилання запитів з і без куків та порівняння відповідей. Якщо інформація відрізняється, це може вказувати на наявність конфіденційної інформації. Цей процес можна автоматизувати за допомогою інструментів, таких як DetectDynamicJS розширення Burp.
Якщо конфіденційні дані зберігаються в глобальній змінній, їх можна експлуатувати, використовуючи подібні методи до тих, що використовуються в Regular XSSI. Однак, якщо конфіденційні дані включені у відповідь JSONP, зловмисники можуть перехопити функцію зворотного виклику, щоб отримати інформацію. Це можна зробити, маніпулюючи глобальними об'єктами або налаштувавши функцію, яка буде виконана відповіддю JSONP, як показано нижче:
Для змінних, які не знаходяться в глобальному просторі імен, підробка прототипу іноді може бути використана. Ця техніка використовує дизайн JavaScript, де інтерпретація коду передбачає проходження по ланцюгу прототипів для знаходження викликаної властивості. Перезаписуючи певні функції, такі як Array
's slice
, зловмисники можуть отримати доступ до не-глобальних змінних і витікати їх:
Додаткові деталі про вектори атак можна знайти в роботі дослідника безпеки Sebastian Lekies, який веде список векторів.
Non-Script-XSSI
Дослідження Такеші Теради вводить ще одну форму XSSI, де файли Non-Script, такі як CSV, витікають між джерелами, будучи включеними як джерела в тег script
. Історичні випадки XSSI, такі як атака Джеремії Гроссмана 2006 року для читання повного адресного довідника Google та витік даних JSON Джо Уокера 2007 року, підкреслюють серйозність цих загроз. Крім того, Гарет Хейз описує варіант атаки, що включає закодований у UTF-7 JSON для виходу з формату JSON та виконання скриптів, ефективний у певних браузерах:
Last updated