В кінці минулого тижня компанія Microsoft, нарешті, поділилася новою інформацією про нові функції Internet Explorer 8, покликаних підвищити рівень безпеки самого популярного браузера. І сьогодні ми розповімо про одну з цих функцій - фільтрі XSS.
Привіт, я Девід Росс (David Ross), програмний інженер безпеки в команді SWI. Я радий можливості написати гостьову статтю в блозі IE, щоб представити вам спільну роботу, яку команда SWI провела з командою Internet Explorer.
Сьогодні ми представляємо інформацію про нову функцію IE8, яка робить реалізацію (Type-1) XSS-атаки в Internet Explorer 8 набагато більш складним завданням. XSS-витоку типу Type-1 складають більшу частину від усієї кількості оголошених вразливостей, тому все частіше використовуються жартома або заради прибутку.
Кількість повідомлених XSS-витоків на популярних сайтах останнім часом різко зросла - MITRE повідомляють, що XSS-уразливість на даний момент представляють самий часто публікується клас вразливостей. Зовсім недавно сайти типу XSSed.com почали збирати і публікувати десятки тисяч Type-1 XSS-вразливостей, присутніх на різноманітних сайтах.
Хоча для розробників існує безліч чудових інструментів, які допомагають пом'якшити XSS-атаки в їх сайтах або додатках, ці інструменти не задовольняють потреби звичайного користувача щодо захисту їх самих від XSS, коли вони подорожують в мережі.
XSS-фільтр: як це працює
XSS-фільтр працює як компонент IE8, який переглядає всі запити і відповіді, що проходять через браузер. Коли фільтр виявляє XSS в міжсайтовий запиті, він виявляє і нейтралізує атаку, якщо вона залежить від відповіді сервера. Користувачам не ставлять питання, на які вони не можуть відповісти - IE просто блокує шкідливий скрипт від виконання.
З новим XSS-фільтром користувачі IE8 Beta 2, які зіткнуться з Type-1 XSS-атакою, побачать приблизно таке попередження.
Сторінка була модифікована і XSS-атака була заблокована. В даному випадку XSS-фільтр виявив атаку міжсайтового скриптинга в URL. Фільтр нейтралізувати атаку, так як ідентифікований скрипт відсилав дані на сторінку відповіді. В даному випадку фільтр ефективний без модифікації початкового запиту до сервера або блокування всього запиту.
Як можна зрозуміти, є безліч цікавих і тонких сценаріїв, які фільтр повинен обробляти правильно. Ось деякі з них.
- Фільтр повинен бути ефективний, навіть якщо атака спрямована на артефакт часто використовуваних робочих середовищ веб-додатків. Наприклад, чи буде атака помічена, якщо певний символ в запиті було втрачено або модифікований при повторному запиті?
- При фільтрації наш код не повинен надати новий сценарій для атаки, яка б відрізнялася від існуючої. Наприклад, уявіть, що фільтр можна змусити нейтралізувати закриває тег SCRIPT. В такому випадку недовірених контент з сайту пізніше може бути запущений як скрипт.
І, звичайно, на додаток до всього цього нам потрібно ефективно боротися з усіма векторами XSS-атак, які ще не були закриті іншими способами скорочення поверхні для XSS-атаки.
Сумісність критична. Ця функція була розроблена з розумінням того, що якщо ми збираємося «зламати веб», то ми не можемо включити цю функцію за замовчуванням. Або якщо ми так зробимо, то люди її вимкнуть і не отримають від неї ніяких переваг. Ми дійсно хочемо надати максимум максимальній кількості користувачів.
З огляду на зовсім незначну несумісність з сайтами і вплив на продуктивність, факт того, що наш фільтр ефективно блокує часто використовуваний шаблон «>
Якщо ви пропустили першу частину цієї серії, будь ласка, прочитайте її по посиланню Використання інструменту Exchange Server Remote Connectivity Analyzer Tool (Частина. [+]