This page has been robot translated, sorry for typos if any. Original content here.

Cross Domain Scripting

Вступ.

Ідея написати цю статтю мене прийшла в голову після того, як знадобилося дати одному новачкові посилання на докладний і зрозуміле пояснення цього терміна. Полазити по пошуковим системам, я з подивом виявив, що знайти таку статтю досить непросто. Термін або не пояснювався взагалі, або в двох словах і по-англійськи :) . Тим часом в Windows уразливості такого типу виявляються досить часто і вони більш ніж серйозні! Тому в цій статті я спробував якомога детальніше і зрозуміліше описати цей тип атак, особливості експлуатації даного типу вразливостей і захисту від них, навести конкретні приклади. Стаття писалася в основному, звичайно, для новачків, але, сподіваюся, буде чимось корисна і для більш досвідчених читачів.

Що таке Cross Domain Scripting?

Спочатку Cross-Domain Scripting (CDS) був пов'язаний з недоліками в моделі безпеки всім відомого «ослика» aka Internet Explorer (IE). Однак, тому що архітектурні особливості сучасних браузерів не сильно відрізняються один від одного, то атакам даного типу в даний час піддаються практично всі відомі веб-браузери. Проте, існуючі відмінності між програмами цього класу призводять до того, що найчастіше знайдений CDS є «браузерозавісімим», тобто, наприклад, працює на IE, але не працює на Opera або навпаки.
В основі вразливостей типу CDS лежить поняття «домену». В даному контексті сенс цього поняття дещо відрізняється від загальноприйнятого. "Домен" - це вже не просто адреса сайту в Інтернеті, і навіть не «область простору ієрархічних імен мережі Інтернет», - дане поняття означає деяку «межу безпеки» (security boundary), виходити за яку не дозволено жодному призначеному для користувача скрипту.
В основі моделі безпеки будь-якого веб-браузера лежить той принцип, що ресурси різних доменів (сторінки, скрипти і т.д.) не можуть жодним чином перетинатися один з одним, тобто отримувати доступ до внутрішнього вмісту і даними один одного. Якби це було можливо, то, наприклад, скрипт на домашній сторінці юного хакера Васі міг би отримати доступ до даних поштової скриньки на Mail.Ru нічого не підозрює користувача, якого Вася заманив на свою сторінку. Ось було б веселощі :) ! Більш того, згідно архітектурі Windows і концепціям побудови сучасних браузерів, будь-який мережевий ресурс в локальній мережі і власна файлова система клієнта це теж «домени», а значить до них можливе звернення з скриптів точно так же, як до будь-якого ресурсу в Інтернеті! Власне саме локальна файлова система клієнта і є найчастіше метою cross-domain атак.
У той же час взаємодія між собою ресурсів (сторінок і скриптів) всередині домену (і всіх його субдоменів!) Концепцією безпеки Microsoft дозволено і в принципі ніяк не обмежена. Важко судити правильно це чи ні, але те, що так простіше :) і при цьому розширюються можливості веб-серфінгу, - це точно.
Так що ж таке Cross-Domain Scripting? У контексті всього вищесказаного цей термін можна перекласти як - «междоменной скриптинг», тобто «Перетин скриптом кордонів домену» - порушення тієї заповітної лінії безпеки, вихід за яку дає доступ до даних інших доменів, в тому числі до локальної файлової системи клієнта. Таке порушення найчастіше супроводжується можливістю записувати і виконувати довільний HTML і Java код в контексті інших доменів, читати дані інших доменів (наприклад, форми з паролями або файли на системі клієнта) і навіть виконувати довільні команди на віддаленому комп'ютері.
Часто поняття «cross-domain scripting» підміняють поняттям «cross site scripting» (XSS). Дійсно, часто буває, що зовнішні прояви цих вразливостей дуже схожі, - особливо, коли в результаті CDS відбувається вставка Java-коду в контекст іншого домену. Однак, незважаючи на схожість, суть цих вразливостей різна:
По-перше, область дії XSS по визначенню обмежена одним доменом. У той час, як CDS в загальному випадку піддаються всі домени + локальна файлова система клієнта.
По-друге, причина XSS уразливостей криється в помилках скриптів, розташованих на сервері, і, як правило, полягає в недостатній фільтрації даних, отриманих від користувача. Джерело CDS вразливостей - клієнтське програмне забезпечення (браузер і операційна система), і він зазвичай ніяк не пов'язаний з одними даними.
Ну і не треба забувати, що рівень небезпеки від успішної експлуатації зловмисником XSS набагато нижче, ніж від CDS. Адже в першому випадку, як максимум, відбудеться витік конфіденційних даних користувача (паролі і т.д.), причому лише з одного сайту, а при CDS можливо викрадення конфіденційний даних з будь-яких сайтів, а часто і виконання довільних команд на системі клієнта, що дозволяє взяти над нею повний контроль.

Як це працює?

Так чому ж стає можливим даний тип атак? Причина полягає в тому, що та сама «лінія безпеки» між доменами створюється штучно, що всю роботу по запобіганню междоменной скриптинга виконує веб-браузер і його компоненти - немає архітектурних обмежень. А значить, завжди є ймовірність помилки в процедурах перевірки, можливість їх обійти, що в даний час з успіхом і робиться.
За більш ніж десятирічну історію використання веб-браузерів було знайдено безліч способів подолати заповітну межу домену. Однак більшість з них можна умовно розділити на два класи:
1.Експлуатація помилок безпеки в об'єктно-орієнтованої моделі браузерів;
2.Використання проміжної ланки для виконання атаки.
Розглянемо докладніше ці класи атак.
В основі першого лежить яскраво виражена об'єктно-орієнтована архітектура сучасних браузерів і віртуальної машини Java. Дійсно, все, що ми бачимо на екрані веб-браузера, це об'єкти певних класів з їх властивостями, подіями і методами. Використовуючи цю об'єктно-орієнтовану модель і скрипти Java, ми можемо звертатися до будь-якого елементу завантаженої в браузер сторінки, читати і записувати в неї дані, відкривати нові вікна і т.д. Більш того, за допомогою скриптів можливо часткове управління елементами самого веб-браузера і навіть діями користувача: переміщення «Вперед» / «Назад» по сторінках, додавання в «Вибране» і т.п.
Однак окремі вікна або елементи сторінки в веб-браузері можуть належати різним доменів, а значить потрібно припиняти звернення до них. Не можна допустити, щоб користувальницький скрипт, відкривши інший домен в новому вікні браузера, мав можливість що-небудь записати туди або вважати звідти. Не можна допустити, щоб скрипт на сторінці з фреймом, куди довантажуючи ресурс з іншого домену, зміг звертатися до цього кадру і отримувати доступ до його даних. Більш того, витік даних від одного домену до іншого можлива не тільки через властивості, але і через методи і події об'єктів! Скажімо скрипт на сторінці юного хакера Васі, куди він заманив нічого не підозрює користувача, не повинен «знати» які клавіші той натискає, коли вводить пароль для входу в Mail.Ru, відкритий в іншому вікні браузера. Ну і таких прикладів можна навести дуже багато!
На жаль, а може і на щастя;), такі перевірки безпеки часто виконуються некоректно, а іноді і відсутні зовсім! Тому стає можливим звертатися до елементів сторінок з інших доменів, зчитувати з них дані, записувати свій Java код в контекст інших доменів і т.д. Через досить складної архітектури об'єктно-орієнтованої моделі такі «дірки» в ній знаходяться досить часто. Нижче наведено приклад даного класу атак (Приклад 1).
Для виконання атак другого класу використовується деякий проміжну ланку. Що робити, коли пряме звернення до іншого домену заборонено? Правильно! Йти в обхід! А раптом є хтось йди щось, кому це звернення не заборонено, і воно зможе вважати звідти дані і передати нам, або навпаки - записати наші дані в контекст іншого домену. Найбільш вразливою з цієї точки зору виявляється технологія ActiveX від Microsoft. Технологія ActiveX надає в розпорядження користувача об'єкти, їх властивості та методи, які використовуються операційною системою для будь-яких допоміжних цілей. Наприклад, для перегляду через веб-браузер файлів довідки Windows (* .chm) використовується HTML Help ActiveX компонент. Чи не правда зручно? Однак найчастіше об'єкти ActiveX виконують роль свого роду «троянських коней»! Справа в тому, що існує спосіб керувати цими компонентами (завантажувати, звертатися до їх властивостей і методів) через веб-сторінку. Для цього використовується тег. Але ж часто ці ActiveX об'єкти містять методи маніпуляцій з файлової системою, запуску додатків, навігації по веб-сторінкам і т.д. Т.ч. з'являється можливість ззовні виробляти всі ці дії і більш того здійснювати повноцінний обмін даними з жертвою! Наприклад, читати вміст локальних файлів клієнта і відправляти назад скрипту ці дані, або за допомогою ActiveX об'єкта відкривати інший домен і записувати в його контекст свій Java код. Саме за допомогою даного класу атак іноді вдається домогтися виконання довільного коду (запуску cmd.exe з потрібними параметрами) на системі клієнта. В даний час даний тип CDS також широко поширений і постійно знаходять нові вразливі ActiveX об'єкти. Нижче наведено приклад такої вразливості (Приклад 2).
Крім розглянутих класів CDS існують і інші способи обходу междоменной обмежень. Правда, найчастіше ці способи є досить екзотичними і зустрічаються нечасто. Наприклад, виявлена ​​в липні 2004 року Cross-Cookie вразливість (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Вона дозволяла при певних умовах отримувати доступ (читати / записувати) до кукам інших доменів. Причому це був один з небагатьох випадків, коли уразливими виявилися багато браузери: IE, Mozilla, Opera, Konqueror.
Т.ч. CDS є в даний час дуже поширеним типом атак і постійно виявляються нові способи експлуатації цих вразливостей ( «вектора атак»).

приклади CDS

Щоб все описане вище було зрозуміліше - розглянемо пару прикладів реальних CDS вразливостей. Всі вони були знайдені в Internet Explorer і дозволяють вставляти свій Java код в контекст інших доменів. Зазвичай це використовується для розкрадання кукисов або виконання довільних дій в рамках поточної сесії користувача.

Приклад 1. Similar Method Name Redirection Cross Domain Vulnerability - CAN-2004-0727 (MS04-038)

Ця вразливість була виявлена ​​в липні 2004 року і пов'язана помилкою безпеки в об'єктно-орієнтованої моделі IE (1-ий клас CDS вразливостей з розглянутих вище).
Суть її в наступному. Як відомо, щоб завантажити в поточне вікно браузера іншу сторінку (можливо з іншого домену), можна використовувати властивість location.href або метод location.assign (). Однак, після завантаження необхідної сторінки подальше виконання Java коду поточного скрипта неможливо - інакше скрипт міг би довантажити Mail.Ru і виконати в контексті цього домену довільні дії. Однак виявилося можливим обійти це обмеження шляхом перенаправлення (перенаправлення) методу location.assign () на точно такий же, але іншого вікна (адже у нас об'єктно-орієнтована модель і ми можемо привласнювати методи різних об'єктів один одному). В результаті з'явилася можливість виконувати Java код в контексті поточного вікна, але вже після завантаження необхідної сторінки - що й було потрібно! Наступний скрипт виконує необхідні дії:


w = window.open ( "jаvascript: setInterval (function () {try {x = opener.location.href;} catch (e) {location.assign ( 'jаvascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";


Спочатку відкривається нове вікно, яке в циклі чекає завантаження сторінки (в нашому випадку з localhost) в головне (поточний) вікно. Тим часом скрипт перепризначає методи location.assign () та почне завантажувати в головне вікно необхідної сторінки (localhost). Як тільки завантаження закінчується, в циклі нового вікна спрацьовує тригер, методом assign () вставляється Jаva код (через перепризначення методів вставка відбувається в контекст головного вікна) і нове вікно тут же закривається. В результаті виконання скрипта в контексті localhost виповнюється dоcument.cookie.
Мабуть розробники Microsoft не передбачили можливість редиректу функцій і не вставили перевірку безпеки (або вставили некоректно) в дану подію. Для експлуатації даної уразливості необхідно, щоб в браузері був дозволений Active scripting. Почитати докладніше про цю уразливість і знайти робочий приклад експлойта ви можете тут: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Приклад 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN -2004-1319 (MS05-013)

Дана уразливість була виявлена ​​в кінці минулого року, але виправлена ​​лише в лютому. Вона відноситься до 2-го типу CDS атак з розглянутих вище, тобто використовує проміжну ланку (DHTML ActiveX) для проведення атаки. Для успішної експлуатації уразливості необхідно виконати наступну послідовність дій:
1.Загрузіть DHTML ActiveX. Це робиться за допомогою тега.




2.Загрузіть в ActiveX об'єкт потрібну нам сторінку (довільний домен). Це робиться шляхом виконання в контексті DHTML ActiveX нашого скрипта.

exploit.DOM.Sсript.execSсript ( "window.name =" new "; open (" http: // localhost "," new ");");

3.Ну а після цього вже можна вставляти наш HTML і Java код. Він буде виконуватися в контексті завантаженого домену. Все просто до неподобства :) !

exploit.DOM.Sсript.execSсript ( "alert (document.cookie)");

Які ж причини даної уразливості? Я б виділив їх дві:
По-перше, можливість ззовні виконувати довільні скрипти всередині ActiveX об'єкта - на мій погляд, це дуже велика вільність!
По-друге, при завантаженні сторінки в DHTML ActiveX туди завантажується ВСЕ - навіть кукіси! Питання: навіщо? Даний ActiveX об'єкт може використовуватися для редагування сторінок і навіщо там потрібні кукіси - незрозуміло ...
Природно, для експлуатації цієї уразливості необхідно, щоб в браузері було дозволено виконання ActiveX. Почитати докладніше про цю уразливість і знайти робочий приклад експлойта ви можете тут: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Як захиститися?

Захиститися від междоменной скриптинга не так просто. Оскільки варіанти експлуатації ( «вектора атак») цих вразливостей дуже різноманітні, то більшість заходів будуть мати досить обмежений і тимчасовий характер. Перекрити всі «вектора атак» практично неможливо. Тому я дам кілька рекомендацій, які здатні лише знизити ризик успішної атаки, але не захистити повністю.
1.Соблюденіе обережності при веб-серфінгу.
Для успішного виконання майже всіх різновидів CDS необхідно спочатку заманити нічого не підозрює користувача на сторінку-експлойт, після чого він піддасться даної атаці. Не можна довіряти посиланнях, як би ненароком, підкинути в розмові, різним «домашнім сторінкам» і т.п. Це напевно головна рекомендація з усіх. На жаль грамотно застосована XSS може перекреслити всю обережність.
2.Оператівная установка латочок для операційної системи і браузера.
Зазвичай для всіх опублікованих в Інтернеті вразливостей виробник (навіть Microsoft :) ) В короткі терміни випускає виправлення (латку). Воно захистить від даної конкретної уразливості, але не від інших, ще не найденнихJ (або знайдених, але не доданих розголосу). Природно, розглянуті в прикладах уразливості вже давно виправлені Microsoft, і хто захотів, той уже подбав про свою безпеку.
3.Отключеніе в браузері ActiveX і Active Scripting.
Цей захід унеможливить запуск в Бразер ActiveX і виконання Java або VBS скриптів. Це дійсно зробить неефективними більшість CDS атак, правда може істотно відбитися на функціональності відвідуваних сайтів. Однак не завжди CDS для успішної атаки вимагає підтримки від браузера ActiveX або Active Scripting - і це не панацея від усіх бід!
4.Работа в Інтернеті тільки з обмеженими правами.
Виконання цієї рекомендації дозволить, навіть в разі успішної атаки, знизити можливі збитки від неї. Як відомо браузер (а значить і всі скрипти в ньому) запускається з правами поточного користувача. Не дайте хакеру Васі отримати cmd.exe з правами Адміністратора :) !
Дотримання всіх цих рекомендацій допоможе стати трудноуязвімим для Cross-Domain Scripting!