Виключно соціальний XSS - Strictly social XSS

22:49 28.10.2011

Раніше я вже розповідав про різні класи Сross-Site Scripting уразливостей, в тому числі про багато класів XSS створених мною. В останнє я розповідав про Міжпрограмний XSS (Cross-Application Scripting), а стосовно класів XSS створених мною - про Міжмовний XSS (Cross-Language Scripting). А зараз розповім вам про ще один тип XSS уразливостей. Даний клас я створив ще у вересні 2007 року (хоча знаходив такі дірки й раніше) і ось нарешті дістався до написання детальної статті про нього.

Це Виключно соціальний XSS - Strictly social XSS. Який я анонсував ще в 2007 році і зараз розповів про нього детально. 23.09.2007 я знайшов Cross-Site Scripting уразливість в Mozilla та Firefox, яку я оприлюднив на початку жовтня. Яку я відніс до типу Strictly social XSS. І відтоді я неодноразово використовував термін Strictly social XSS для подібних уразливостей, активно його пропагуючи.

Якщо у вересні 2007 я знайшов можливість даної атаки через протокол gopher, то вже 09.02.2008 я виявив можливість використання протоколів http, https і ftp. Про що я писав в записі Cross-Site Scripting з UTF-7 в Mozilla та Firefox. В усіх цих випадках, атака відбувался при відвіданні спеціальної сторінки з UTF-7 текстом (це могла бути як reflected, так і persistent атака), де потрібно було змусити жертву встановити UTF-7 кодування в браузері (вибравши відповідний пункт меню). Що можна було зробити використовуючи методи соціальної інженерії, як я показав на прикладах XSS атак для різних протоколів.

gopher:///1+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-
gopher:///1Turn%20on%20UTF-7%20to%20view%20this%20message%20+ADw-SCRIPT+AD4-alert('XSS')+ADw-/SCRIPT+AD4-

Враховуючи, що атаку можна було провести на будь-який gopher, http, https і ftp ресурс (що виводив UTF-7 текст, вказаний в URL, у відповіді на запит), то це була універсальна Strictly social XSS уразливість. Також зазначу, що якщо в 2007 році Мозіла проігнорувала цю уразливість, то вже восени 2008 року, Мозіла втихаря виправила цю уразливість в Firefox 3.0.2.

Особливості Strictly social XSS.

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

Серед браузерів, що мали подібні дірки, є Mozilla та Firefox, про які я згадував вище, та Internet Explorer через атаку через вгадування протоколу в IE6. Серед подібних дірок на сайтах зустрічаються специфічні для окремих сайтів та такі, що поширені на багатьох сайтах, а також такі, що вимагають використання функціоналу браузера (але при цьому дірка специфічна для сайта, а не для браузера). Наприклад, уразливість на craigslist.org, що я знайшов 01.11.2007.

Дірка на craigslist.org вимагала для атаки змусити користувача вибрати необхідний пункт меню в браузері (якщо Site Navigation Bar виключений, як це часто буває). А якщо він був включений у користувача (Show Always, або Show Only As Needed), то лише залишалось змусити користувача зробити клік в меню Site Navigation Bar в браузері. Для запуску JavaSript коду потрібно було в Site Navigation Bar в меню More вибрати RSS фід сайта. Атака могла спрацювати в браузерах, що підтримують Site Navigation Bar, таких як Mozilla, Firefox та Opera.

Окрім вищезгаданих випадків, також подібні уразливості трапляються в плагінах для браузерів, такому як Flash (зокрема в контенті для цього плагіна - флешках). Що дозволяє проводити дані атаки в усіх браузерах, тобто ці уразливості є кросбраузерними і можуть мати місце на будь-яких сайтах з уразливими флешками. Про приклади таких масових XSS я писав у статтях XSS уразливості в 8 мільйонах флеш файлах та XSS уразливості в 34 мільйонах флеш файлах. В усіх цих випадках необхідно було клікнути на флешку для запуску JavaScript коду.

Обробники подій.

Існують такі XSS уразливості, які спрацьовують через обробники подій, зокрема тих, що працють не автоматично, а при деяких діях користувача. Як то при кліку, при наведенню курсору чи при інших подіях (як event-ів, що існують в стандарті HTML, так і власних подій розробників браузерів, що підтримуються лише браузерами даних компаній). Такі уразливості відомі вже давно, задовго до створення мною класу Виключно соціальних XSS, і за звичай їх відносили до reflected XSS уразливостей (а деякі розробники навіть не вважали їх за XSS і не виправляли).

При створенні даного класу XSS уразливостей я додав всі такі XSS через обробники подій до нього. Тому що дані уразливості вимагають додаткових дій користувача, що відповідає визначенню Strictly social XSS. Тобто не тільки нові дірки, знайдені мною і наведені в цій статті, я відніс до цього класу, але й старі XSS дірки, що працють при onClick, onMouseOver та інших подіях. Таким чином подібні дірки через обробники подій подібно відносити до цього класу.

При цьому трапляються випадки, коли на сайті є фільтрація (вбудована в сайт чи WAF) і не можна використати звичайну відбиту XSS, а зате можна використати обробники подій. Це той випадок, коли reflected XSS замінюється на Strictly social XSS для обходу фільтрації. На протязі багатьох років я неодноразово використовув Виключно соціальний XSS для обходу WAF, в тому числі ModSecurity.

Різновиди Strictly social XSS.

Бувають наступні види Виключно соціального XSS:

  • Strictly social XSS reflected.
  • Strictly social XSS persistent.
  • Strictly social XSS DOM based.
  • Strictly social XSS local.
  • Strictly social XSS reflected self-contained.
  • Strictly social XSS persistent self-contained.

Strictly social XSS reflected.

Strictly social XSS reflected представляє собою лінку з JavaScript/VBScript кодом.

Прикладами такої XSS є уразливість на tinyurl.com, уразливості в 8 мільйонах флеш банерах та уразливості в WP-Cumulus для WordPress і десятках портів WP-Cumulus для різних движків, які разом використовуються на приблизно 34000000 веб сайтах.

Strictly social XSS persistent.

Strictly social XSS persistent представляє собою лінку з JavaScript/VBScript кодом.

Прикладом такої XSS є уразливість на tinyurl.com та уразливість в WordPress.

Strictly social XSS DOM based.

Strictly social XSS DOM based представляє собою включення JavaScript/VBScript коду в обробник події, такої як натискання кнопки (onClick) чи іншої події.

Прикладами такої XSS є уразливості в Joomla та Joostina, на yandex.ru, images.yandex.ru та market.yandex.ru, afisha.yandex.ru та video.i.ua.

Strictly social XSS local.

Strictly social XSS local представляє собою подібну XSS в локальному додатку, зокрема в браузері. Про даний різновид я вже детально писав в статті Local XSS - Локальний XSS.

Прикладами такої XSS є уразливості в Mozilla та Firefox, в Mozilla та Firefox через редиректори, в Internet Explorer 6, на search.yahoo.com та craigslist.org.

Strictly social XSS reflected self-contained.

Strictly social XSS reflected self-contained представляє собою лінку з data з JavaScript кодом.

Прикладом такої XSS є уразливість на www.s-cars.org.

Strictly social XSS persistent self-contained.

Strictly social XSS persistent self-contained представляє собою лінку з data з JavaScript кодом.

Прикладами такої XSS є уразливості на tinyurl.com та уразливість в WordPress.

Використання Strictly social XSS разом з додатковими техніками атаки.

Враховуючи, що для виконання JS/VBS коду при Strictly social XSS уразливості потрібні додаткові дії користувача, це ускладнює атаку. Для спрощення атаки, аж до повної її автоматизації (подібно до reflected XSS), для цього можна використати додаткові техніки атаки. Зокрема такі техніки як ClickJacking, MouseOverJacking та атаку через буфер обміну.

Якщо для атаки жертві потрібно зробити клік, то можна використати ClickJacking (розроблений Джеремією та Робертом).

Якщо для атаки жертві потрібно зробити наведення мишею, то можна використати MouseOverJacking (розроблений мною).

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


Одна відповідь на “Виключно соціальний XSS - Strictly social XSS”

  1. MustLive каже:

    You can read this article on English: Strictly social XSS.

Leave a Reply

You must be logged in to post a comment.