Що таке забруднення параметрів HTTP і чому це реальна небезпека?

Коли ми говоримо про безпеку вебзастосунків, багато людей думають лише про Помилки SQL-ін'єкції, XSS або автентифікаціїОднак, протягом багатьох років існує досить непомітний метод, який продовжує залишатися непоміченим у багатьох аудитах: забруднення або забруднення параметрів HTTP, відоме як Забруднення параметрів HTTP (HPP) Забруднення параметрів HTTP.

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

Концепція параметрів HTTP та їх пріоритет

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

У типовому GET-запиті ці дані передаються в рядок запиту (все, що йде після знака ? в URL-адресі)Пари ключ/значення розділяються символом амперсанда (&). У POST-запиті вони можуть бути в тілі запиту, але логіка застосунку на сервері зазвичай обробляє їх дуже схоже: ключі з одним або кількома пов'язаними значеннями.

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

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

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

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

Що таке забруднення параметрів HTTP (HPP)?

Забруднення параметрів HTTP – це метод, який полягає в вставляти додаткові параметри або роздільники рядків запиту (закодований) всередині інших існуючих параметрів. Коли цей введений параметр декодується та повторно використовується для створення нової URL-адреси або для створення іншого запиту, застосунок Зрештою, це включає додаткові параметри, яких розробник не очікував..

Іншими словами, HPP використовує спосіб, у який програма Він реконструює URL-адреси, обробляє форми та використовує повторювані параметри.Якщо вхідні дані не перевірені належним чином, зловмисник може змусити програму інтерпретувати значення, відмінні від очікуваних, або включати додаткові параметри в посилання, форми та перенаправлення.

Методи гідроелектростанцій були публічно представлені Стефано Ді Паола та Лука Кареттоні на конференції OWASP AppSec 2009. Відтоді вони були задокументовані багато сценаріїв атакиАле навіть сьогодні вони не мають такої ж видимості, як інші, більш відомі вразливості, і вони не повністю охоплені всіма автоматизованими інструментами.

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

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

Як сервери обробляють дублікати параметрів

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

У деяких середовищах, якщо ми надсилаємо URL-адресу типу змінна1=значення1&змінна1=значення2сервер зберігатиме лише перше значення (значення1). В інших випадках це займе останнє отримане значення (значення2). А в певних випадках, як це трапляється з певними конфігураціями IIS, ці два значення є об'єднати внутрішньо у список, наприклад, розділені комами, які потім має інтерпретувати програма.

Часто наводимий приклад полягає в тому, що Apache У своїй поведінці за замовчуванням він зазвичай зберігає перше значення параметра та відкидає наступні, тоді як інші технології генерують Список CSV (дані, розділені комами) з усіма значеннями цього забрудненого параметра. Якщо бекенд-застосунок адаптований лише до одного з цих випадків, неконтрольовані сценарії можуть призвести до неочікуваних наслідків.

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

Крім того, ГЕС можна використовувати для отримання переваг внутрішні трансформації характеру що робить сам сервер. Наприклад, було задокументовано, як деякі сервери змінюють певні символи (наприклад, заміна символу "]" на "_") під час обробки, що можна використовувати для обхід правил фільтрації або прошивок WAF на основі регулярних виразів.

Наслідки та сценарії експлуатації ГЕС

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

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

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

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

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

Що стосується наслідків, атаки спостерігалися з обох сторін. сторона сервера (обхід WAF, зміна перезапису URL-адрес, примусове використання різних внутрішніх маршрутів) станом на сторона клієнта (впровадження параметрів у посилання та форми для обману жертв через спеціально маніпульовані URL-адреси).

Класичний приклад HPP у програмі для голосування

Щоб краще зрозуміти, як працює атака HTTP Parameter Pollution, розглянемо приклад Веб-додаток для голосування, написаний на JSPде користувачам дозволено голосувати за свого улюбленого кандидата на різних виборах.

Додаток отримує через параметр під назвою ідентифікатор_виборів Ідентифікатор поточних виборів. З цим значенням сервер генерує сторінку зі списком доступних кандидатів, кожен з яких містить посилання для голосування. Метод Request.getParameter("пара") У JSP, коли для одного й того ж параметра присутні кілька значень, він завжди повертає перше значення.

Давайте уявимо собі URL-адресу такої форми: http://servidor/eleccion.jsp?eleccion_id=4568На сторінці, що відкриється, буде відображено посилання для голосування за кожного кандидата, наприклад:

Посилання 1Я голосую за пана Вайта
Посилання 2Я голосую за пані Грін

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

URL-адреса, яку він створює, може бути приблизно такою: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenЗверніть увагу, що зловмисник закодував символ & як %26, а знак = як %3D, тож після декодування вони стають новим параметром кандидата, вбудованим у значення election_id.

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

В результаті, внутрішньо згенеровані посилання стають приблизно такими:

Посилання 1Я голосую за пана Вайта
Посилання 2Я голосую за пані Грін

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

Завдяки такій поведінці, вразливість HPP дозволяє зловмиснику змусити всі голоси, подані на цій сторінці, піти за їхнього кандидатанезалежно від вибору жертви в інтерфейсі. Це дуже яскравий приклад того, як нібито «просте» керування параметрами може мати прямий вплив на цілісність даних та бізнес-логіка.

Обхід автентифікації: випадок Blogger

Один із найвідоміших прикладів використання HTTP-параметрів стався в системі блогів BloggerВразливість в обробці параметрів дозволила зловмисникам отримати доступ до стати адміністраторами блогів інших людейпросто маніпулюючи параметрами POST-запиту.

Проблемний запит був приблизно таким (спрощуючи синтаксис):

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Запросити

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

Через цю внутрішню суперечність, спосіб, яким сервер обробляв дублікати параметрівЗловмиснику вдалося пройти перевірку безпеки для власного блогу, але виконати дію на іншому блозі. Результатом стала повний обхід автентифікації з одним добре сформульованим запитом.

Цей випадок дуже добре демонструє, що HPP — це не просто «технічна цікавость», а техніка з реальний вплив на системи великих постачальниківКрім того, це підкреслює важливість перевірок безпеки та виконання операцій з використанням абсолютно однакових значень параметрів, без залежності від неконтрольованого пріоритету.

HPP та брандмауер веб-застосунків (WAF)

Багато організацій покладаються на WAF як додатковий рівень для захисту своїх веб-застосунків від відомих атак. Ці брандмауери зазвичай базуються на правила та підписи (регулярні вирази) які застосовуються до параметрів, заголовків і навіть тіла HTTP-запитів.

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

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

Крім того, деякі WAF, які не функціонують як зворотний проксі-сервер А ті, хто не має повного уявлення про потік між клієнтом і сервером, а радше діє як точкові фільтри, можуть бути особливо вразливими до цих обхідних шляхів HPP. Ті, що базуються на таких технологіях, як Apache з механізмом оцінювання параметрів та статистичного аналізу Вони, як правило, поводяться краще перед обличчям таких методів.

Коротше кажучи, HPP демонструє, що навіть за умови правильно налаштованої WAF, Безпека не гарантована Якщо сама логіка застосунку та сервера неправильно обробляє дублікати параметрів, захист має бути комплексним та враховувати, як запити обробляються на всіх рівнях.

Реальні випадки, інструменти та поширеність HPP

Академічні дослідження та робота експертів з безпеки показали, що забруднення параметрів HTTP — це далеко не рідкість. Такі проекти, як PAPAS (Система аналізу параметрів забруднення), керовані такими дослідниками, як Кармен Торрано, були розроблені саме для того, щоб автоматично виявляти вразливості HPP у великомасштабних веб-додатках.

В експериментах, проведених на більш ніж 5000 дуже популярних веб-сайтів (згідно з рейтингами, такими як Alexa), було помічено, що майже 30% проаналізованих сайтів Вони містили щонайменше одну сторінку, вразливу до HPP. Тобто, можна було вставити закодований параметр в інший існуючий і перевірити, чи він відображається декодованим у певній результуючій URL-адресі або формі.

Ще більш вражаючим є те, що поблизу 47% знайдених вразливостей (що еквівалентно приблизно 14% від загальної кількості сайтів) були справді експлуатованийдозволяючи атаки, що виходили за рамки простих недоліків презентації. Серед постраждалих сайтів були Великі імена, такі як Microsoft або GoogleЦе чітко показує, що навіть технологічні гіганти не є винятком від цих проблем.

Такі інструменти, як PAPAS Вони допомогли проаналізувати та кількісно оцінити проблему, але також висвітлили складність автоматично виявляти ГЕСБагато традиційних веб-сканерів вразливостей не враховують ретельно сценарії з дублікатними параметрами або генерують дуже велику кількість хибнопозитивних результатів.

Окрім специфічних рішень, таких як POTATOES, існують розширення, такі як Пошукач HPP для Google ChromeЦі інструменти розроблені для виявлення потенційних векторів атак HPP в URL-адресах та HTML-формах. Хоча вони можуть допомогти виявити підозрілі моменти (наприклад, форми, які повторно використовують параметри без належної перевірки), вони не є не є повним рішенням і не замінює поглиблений аудит безпеки.

Ще один інструмент, що широко використовується в екосистемі тестування безпеки, це OWASP ZAPякий включає розширення та скрипти для тестування різних векторів, зокрема тих, що пов'язані з параметрами в рядку запиту. Однак, у конкретному випадку HPP, все ще необхідно поєднувати автоматизовані інструменти з ручний аналіз та розуміння потоку роботи програми.

HPP у внутрішніх пошукових системах та приклади, такі як Apple.com

ГПП спостерігалися не лише в системах управління блогами або адміністративних панелях, вони також з'являються в на перший погляд нешкідливі функції, такі як пошукові системи за тегами на онлайн-форумах та у спільнотах. Яскравим прикладом було Форуми Apple, де управління забрудненими мітками та параметрами демонструвало цікаву поведінку.

На цих форумах вибір тегу в інтерфейсі додавав параметр теги Рядку запиту в URL-адресі передавалося значення вибраного тегу. Бекенд-застосунок отримував це значення, шукав теми з цим тегом і відображав результати користувачеві. Якщо було вибрано кілька тегів, усі вони додавалися. в тому ж параметрі tags, розділених оператором додавання (+)тож серверна частина була готова до обробки цього списку.

Коли параметр tags був забруднений кількома дублікатними значеннями, було помічено, що технологія бекенду генерувала список, розділений комами (CSV) з усіма забрудненими значеннями параметрів. Програма змогла частково обробити цей список (виявити різні теги), але Він не надрукував усі етикетки правильно. у текстовому полі пошукової системи.

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

Аналіз базових технологій на таких форумах, як форум Apple (наприклад, Apache з J2EE в серверній частині) показує, що багато сучасних стеків поводяться подібно до серверів, таких як IIS, або їх комбінацій, таких як Apache з Python, під час обробки забруднених параметрів, генеруючи списки, розділені комами, та делегуючи остаточну обробку цих значень логіці програми.

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

Виявлення та зменшення забруднення параметрів HTTP

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

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

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

Щодо інфраструктури, доцільно переглянути конфігурації веб-сервера та фреймворку Щоб точно зрозуміти, що відбувається, коли отримується параметр, що повторюється: чи зберігається перший, останній чи всі вони об'єднані. Звідси логіку програми можна налаштувати, щоб уникнути розбіжностей між перевіркою та фактичним використанням значення.

Що стосується інструментів, то, окрім звичайних сканерів вразливостей, корисно використовувати цільові рішення, такі як PAPAS або тип розширень Пошук ГЕС у тестовому потоці. Якщо використовуються OWASP ZAP або інші інструменти для тестування на проникнення, варто розробити спеціальні скрипти, які генерують запити з дублікатними параметрами та значеннями, закодованими різними способами спостерігати за реакцією програми.

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

Забруднення параметрів HTTP по праву зайняло своє місце серед методів веб-атак, які повинна мати на увазі будь-яка команда розробників та безпеки: Він непомітний, його важко побачити простим поглядом на колоди, і він може мати дуже серйозні наслідки. якщо це впливає на ключові параметри бізнес-логіки або засобів контролю безпеки. Розуміння того, як обробляються дублікати параметрів у вашому стеку, та активне тестування цих сценаріїв – це одне з тих завдань, яке спочатку може здатися трохи нудним, але саме воно визначає різницю між просто функціональним застосунком та тим, який дійсно стійкий до складних атак.