IBM Rational AppScan: атаки на Web-додатки через підробку маркерів (cookie poisoning), Різне, Програмування, статті

Природа ризиків, пов’язаних з підробкою маркерів


Підробка маркерів (cookie poisoning) – це методика, яка зазвичай застосовується для фальсифікації персональної інформації шляхом маніпуляцій з маркерами (cookies) сеансу, що містять ідентифікаційні дані клієнта (або кінцевого користувача). Фальсифікуючи ці cookies, атакуючий може видати себе за добропорядного клієнта і тим самим отримувати інформацію та виконувати певні дії від імені своєї жертви. Можливість зміни таких сеансових cookies (зазвичай їх називають маркерами сеансу) обумовлена ​​тією обставиною, що маркери генеруються небезпечним чином.


Сізіфова праця обслуговування сеансів власними силами


Завдання управління сеансами при програмуванні Web-додатків є складною і трудомісткою. Програмісту потрібно враховувати багато аспектів управління сеансами, які можуть відвернути його від основної мети – Реалізації бізнес-логіки, яка робить сайт унікальним і прибутковим.


У числі цих завдань:






Піклуючись про забезпечення безпеки, важливо враховувати наступні моменти:





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


Є безліч прикладів недостатній захист маркерів. Вони були продемонстровані лабораторією Laboratory for Computer Science Массачусетського технологічного інституту (див. статтюDos and Don”ts of Client Authentication on the Web (Аутентифікація клієнта в Web: що можна і що не можна), Кевін Фу (Kevin Fu), Еміл Сіт (Emil Sit), Кендра Сміт (Kendra Smith) і Нік Фімстер (Nick Feamster)). Таким чином, ми бачимо, що важко створити хороше рішення для управління сеансами, не кажучи вже про безпечне рішення для управління сеансами. Це одна з причин, чому сервери додатків настільки популярні.


Сервери додатків і їх механізми: рішення і проблема


Сервер додатків (або механізм сервера додатків) – це програмне забезпечення, покликане полегшити життя розробнику додатків. Воно зазвичай пропонує програмісту прості способи для написання HTML-сторінок, містять вбудовані директиви, які наказують серверу виконувати різні завдання. Більшість серверів додатків надають програмісту середовище, яке автоматично обслуговує сеанс, звільняючи програміста від додаткових турбот, згаданих вище.


Приклади серверів додатків:



На сторінці Internet Cookie Report Web-сайту Security Space представлений аналіз повторюваності при співвіднесенні імен cookie з породив їх сервером. Зрозуміло, цей підхід неточний, оскільки деякі сервери і сайти використовують маркери в параметрах, а не в cookies.


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


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


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


Приклад 1. Атака на маркер, побудований на базі системного часу


Мішенню для цієї атаки є механізм дуже популярного комерційного сервера додатків. Цей продукт використовує два cookies для ідентифікації сеансу. Пара, що утворюється двома cookies, визначає сеанс. Перший cookie є просто лічильником, вміст якого збільшується при кожному новому сеансі. Він повинен гарантувати відсутність двох однакових пар. Другий cookie – це маркер, який повинен убезпечити пару, зробивши її “непередбачуваною”. Враховуючи, що значення першого cookie легко передбачити, ми зосередимося на другому cookie, який буде називати TOKEN.


На перший погляд TOKEN являє собою послідовність з довільних восьмизначних чисел. Ентропія (ступінь випадковості) тут становить 108 = 226.57, що можна вважати достатнім, оскільки важко направити таку велику кількість запитів (100 млн.) на сайт, щоб це залишилося без уваги. Однак при більш детальному розгляді можна побачити, що TOKEN описується наступним рівнянням:






Позначимо як t час за Гринвічем, виражене в секундах,  таке як 01/01/1970 00:00, встановлене на сервері додатків.

Позначимо як m складову в мілісекундах лічильника синхроімпульсів на сервері додатків.

Тоді: TOKEN = (31415821 * (t + m) + 1) mod 100 000 000

Цікаво відзначити, що значення t можна отримати із значення HTTP-заголовка Date, яке сервер посилає назад клієнтові разом з часом першої установки cookies. Це означає, що значення cookie TOKEN є цілком передбачуваним. Фактично, якщо комусь відомий інтервал часу T





Отримуємо першу пару (id1, TOKEN1). Записуємо t1 –  час сервера (Чорноморське HTTP заголовка)
Чекаємо ΔT секунд.
Отримуємо другу пару (id22, TOKEN2).
Записуємо t2 – Час сервера (витягаємо з HTTP-заголовка Date)
if (id2 > id1 +1)
begin / / тут ми використовуємо передбачуваний час сеансу жертви.
for (x= t1 ; x < t2+1000 ; x++) // which is ΔT +1000 Ітерації починаємо з
Пробуємо пару (id1 +1, (31415821 * x + 1) mod 100 000 000) end end

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


Описаний вище алгоритм дозволяє атакуючому визначити маркер жертви за умови, що cookie був призначений жертві в інтервалі між двома спробами атакуючого підібрати cookie сайту. Оскільки атакуючий може як завгодно багато разів повторювати алгоритм, він здатний отримати ці cookies для всіх клієнтів, періодично посилаючи запити на сайт (скажімо, один раз на хвилину) і додатково видаючи по 1060 запитів для кожного з нововиявлених клієнтів. Знову ж таки, як згадувалося вище, можна скоротити інтервали між запитами (по одному в секунду) і скористатися меншою дискретністю годин, що в ряді випадків дозволяє домагатися мети за допомогою 100 запитів на кожного нового клієнта.


Цілком імовірно, що якщо спроба дізнатися маркер клієнта виконується в той момент, коли сайт досить завантажений трафіком, то додаткова сотня чи тисяча запитів залишиться непоміченою (або, по крайней мірі, буде помічена не відразу).


Приклад 2. Коли Random () не забезпечує випадковість


У цьому прикладі ми маємо справу з усе ще популярним (хоч і дещо застарілим) механізмом сервера додатків. Цей механізм генерує один cookie для кожного нового сеансу. Цей cookie (тут ми називаємо його ID) містить три обов’язкові поля (F1, F2 і F3) і одне додаткове (в залежності від конфігурації сервера) поле (F4, з попереднім крапкою), об’єднані в єдине ціле. Ось ці поля:






F1 = 6 символів (A-Z0-9) – число PRNG (генератор псевдовипадкових чисел),  представлене в системі числення за основою 36 з початковими нулями  F2 = 3 символи (A-Z0-9) –  серверне час (в мілісекундах), поділений на 2000,  по модулю 363 (= 46656), представлене в системі числення по підставі 36 цифр з початковими нулями F3 = 3 символи (A-Z0-9) – число сеансів за ці 2 секунди,  представлене в системі числення за основою 36 цифр  F4 = строкою константа (унікальна для сервера)

Як можна бачити, число F4 (якщо воно є) є константою, а тому його цілком можна передбачити. F2 – це просто серверне час (в секундах), поділене на 2, по модулю 46656, теж цілком передбачуване, а число F3 теж цілком можна визначити, так як воно послідовно збільшується на одиницю через кожні дві секунди (завжди відраховується з одиниці).


Таким чином, єдиним цікавим полем є F1. Здавалося б, воно володіє достатньою ентропією, щоб забезпечити безпеку системи, оскільки може приймати 366 значень (= 231.0). Але знову-таки, якщо провести повний аналіз, то, що на перший погляд видається безпечним, насправді таким не є. Пояснення, як і чому можна передбачити значення F1, наведено у Додатку А. Проблема з F1 полягає в тому, що при його формуванні використовується генератор псевдовипадкових чисел (PRNG), робота якого сама по собі передбачувана. Знаючи кілька значень F1, можна передбачити число, сгенерированное PRNG, і, таким чином, майбутні (і минулі) значення F1.


Ось схема такої атаки:






Підготовка:
Отримуємо три значення ID через мінімально можливі інтервали часу.
Витягуємо внутрішній статус PRNG (як пояснюється в Додатку А).
Через цикл перехоплення отримуємо ID і записуємо серверний час
, t .
Для простоти вважаємо, що t парне число.
Знаходимо внутрішній статус PRNG, який був використаний для генерації цього ID (Як – пояснюється у Додатку) чекаємо ΔT секунд (тут ΔT парне число) Міняємо PRNG і фіксуємо всі внутрішні статуси між станом PRNG стосовно до старого ID і станом PRNG стосовно генерації цього ID (як – пояснюється у Додатку). Назвемо список внутрішніх станів L
/ / ΔT / 2 ітерацій:
for (T=t; T<t+ΔT; T+=2)
begin кожного внутрішнього статусу PRNG L, i.
begin Пробуємо ID cookie складається з:
F1 = генерується з вибірки станів PRNG i і i +1;
F2=T; F3 = 1; / / Перший сеанс в цьому двухсекундной інтервалі часу F4 = F4 будь-який з обчислених вище ID; / / серверна константа
end
end

Як можна бачити, можливо, хоча й не без зусиль, передбачити деякі ідентифікують cookies. Необхідно, щоб інтервал часу (ΔT) був коротким (по відношенню до очікуваного коефіцієнту використання сервера), щоб мінімізувати довжину списку L (містить можливі внутрішні статуси PRNG). Якщо ці інтервали дійсно дуже малі (менше двох секунд), є шанс, при правильному виборі проміжків часу, визначити, чи був протягом поточного 2-секундного інтервалу запущений новий сеанс, що робить атаку більш ефективною (оскільки додаткові запити на сервер надсилаються тільки тоді, коли стає відомо про створення жертвою нового сеансу). Слід також зазначити, що для уникнення втрати синхронізації (внутрішнього статусу PRNG) з сайтом необхідно час від часу запитувати новий ID, щоб привести внутрішній статус PRNG атакуючого у відповідність з новим значенням. Це означає, що сайт може інтенсивно використовувати PRNG, а це викликає швидку втрату синхронізації (щоб перешкодити цього, потрібно здійснювати ресинхронізацію через мінімально можливі проміжки часу, наприклад, кожні кілька хвилин). З іншого боку, можна отримати більш чітке уявлення про внутрішній статус PRNG, переглядаючи інші випадкові значення, які можуть бути використані на цьому сайті. Це дозволить знайти обхідний шлях і заощадити масу обчислювальних ресурсів.


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


Що кажуть постачальники


Постачальник 1 був повідомлений про слабкому місці і повідомив нам, що користувачам рекомендується використовувати для управління сеансами сертифікати SSL. Хоча деяких користувачів це і влаштує (але, безумовно, не всіх, оскільки перехід на SSL і сертифікати SSL – не завжди проста, а іноді й неможливе завдання). У документації на продукт засвідчується, що вбудовані засоби управління сеансами забезпечують безпеку (В документації для розробників вони називаються “клієнтським маркером безпеки”). Крім того, постачальник не зробив цю інформацію публічно доступною.


Постачальник 2 підтвердив наявність слабкості, але відповів нам: “Сеансовий cookies не замінюють маркери аутентифікації. Розумними механізмами є сеансові cookies в поєднанні з випадково формованим маркером аутентифікації, або перевірка логіна при аутентифікації. Це справедливо для розробки сценаріїв, заснованих на сеансах – навіть у ситуаціях, коли сеансові маркери сьогодні вважаються “заслуговують довіри”. “Таким чином, цей постачальник перекладає відповідальність на розробника.


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


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


Висновки


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


Рішення просте: світ Web-додатків повинен включати три компоненти:





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

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


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

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

Ваш отзыв

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

*

*