4.3 Testing for HTTP Parameter Pollution
Суть вразливості:
Надання кількох параметрів HTTP з тим самим ім'ям може призвести до того, що програма інтерпретуватиме значення непередбаченими способами. Використовуючи ці ефекти, зловмисник може обійти перевірку введення, викликати помилки програми або змінити значення внутрішніх змінних. Оскільки забруднення параметрів HTTP (коротше кажучи, HPP) впливає на будівельний блок всіх веб-технологій, існують атаки на стороні сервера та клієнта.
Поточні стандарти HTTP не включають керівництво про те, як інтерпретувати кілька вхідних параметрів з одним і тим самим ім'ям. Наприклад, RFC 3986 просто визначає термін Query String як послідовність пар значення-поле, а RFC 2396 визначає класи звернених та незарезервованих символів рядка запиту. Без встановленого стандарту компоненти веб-програми обробляють цей крайній випадок у різний спосіб (подробиці див. у таблиці нижче).
Саме собою це не обов'язково вказує на вразливість. Однак, якщо розробник не знає про проблему, наявність дубльованих параметрів може призвести до аномальної поведінки в програмі, яка може бути використана зловмисником. Як і часто в області безпеки, несподівана поведінка є звичайним джерелом слабких місць, які можуть призвести до атак забруднення параметрів HTTP. Щоб краще уявити цей клас уразливостей та результати атак HPP, цікаво проаналізувати деякі реальні приклади, які були виявлені в минулому.
Перевірка вхідних даних та обхід фільтрів У 2009 році, відразу після публікації першого дослідження із забруднення параметрів HTTP, метод привернув увагу спільноти безпеки як можливий спосіб обійти брандмауери веб-додатків.
Один з цих недоліків, що впливають на основні правила SQL-ін'єкцій ModSecurity, є чудовим прикладом невідповідності імпедансу між додатками і фільтрами. ModSecurity фільтруватиме наступний рядок:
select 1,2,3 from Table
Таким чином блокуючи цей приклад URL з обробки веб-сервером:
/index.aspx?page=select 1,2,3 from table
Однак, використовуючи об'єднання кількох параметрів HTTP, зловмисник може змусити сервер додатків об'єднати рядок після того, як фільтр ModSecurity вже прийняв вхідні дані. Наприклад, URL /index.aspx?page=select 1&page=2,3 з таблиці не запускатиме фільтр ModSecurity, однак прикладний рівень об'єднає вхідні дані назад у повний шкідливий рядок. Виявилося, що ще одна вразливість HPP торкнулася Apple Cups, відомої системи друку, яка використовується в багатьох системах UNIX. Експлуатуючи HPP, зловмисник може легко викликати вразливість XSS , використовуючи наступну URL:
http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos.
Контрольну точку перевірки програми можна обійти, додавши додатковий kerberos аргумент, що має допустимий рядок (наприклад, пустий рядок). Оскільки контрольна точка перевірки враховуватиме лише друге входження, перший kerberos параметр не був належним чином очищений перед використанням для створення динамічного вмісту HTML. Успішна експлуатація призведе до виконання коду Javascript у контексті веб-сайту хостингу.
Обхід автентифікації
Ще більш критична вразливість HPP була виявлена в Blogger, популярній блог-платформі. Ця помилка дозволила зловмисникам заволодіти блогом жертви за допомогою наступного запиту HTTP:
POST /add-authors.do
HTTP/1.1 security_token=attackertoken&blogID=attackerblogidvalue&blogID=vic timblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite
Недолік полягав у механізмі автентифікації, який використовується веб-додатком, оскільки перевірка безпеки була виконана для першого blogID параметра, тоді як фактична операція використовувала друге входження.
Як тестувати
На щастя, оскільки призначення параметрів HTTP зазвичай виконується через сервер веб-застосунків, а не через код програми, тестування відповіді на забруднення параметрів повинно бути стандартним для всіх сторінок і дій. Однак, оскільки потрібні глибокі знання бізнес-логіки, тестування HPP вимагає ручного тестування. Автоматичні інструменти можуть лише частково допомогти аудиторам, оскільки мають тенденцію генерувати занадто багато помилкових спрацьовувань. Крім того, HPP може виявлятися у клієнтських та серверних компонентах.
Серверна HPP
Щоб перевірити наявність уразливостей HPP, визначте будь-яку форму або дію, яка дозволяє вводити дані користувачем. Параметри рядка запиту в HTTP-запитах GET легко налаштовуються на панелі навігації браузера. Якщо дія форми надсилає дані через POST, тестувальник повинен буде використовувати перехоплюючий проксі-сервер для зміни даних POST під час їх надсилання на сервер. Визначивши певний вхідний параметр для тестування, можна відредагувати дані GET або POST, перехопивши запит або змінити рядок запиту після завантаження сторінки відповіді. Щоб перевірити вразливість HPP, просто додайте той самий параметр до даних GET або POST, але з іншим призначеним значенням.
Наприклад: під час тестування search_string параметра в рядку запиту URL-адреса буде включати ім'я та значення цього параметра
http://example.com/?search_string=kittens
Конкретний параметр може бути прихований серед кількох інших параметрів, але підхід той самий; залиште інші параметри на місці та додайте дублікат.
http://example.com/?mode=guest&search_string=kittens&num_results=100
Додайте той самий параметр з іншим значенням
http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=pup
і надішліть новий запит.
Проаналізуйте сторінку відповіді, щоб визначити, які значення було проаналізовано. У наведеному вище прикладі результати пошуку можуть показати kittens або разом зі значенням puppies та ще різні варіанти (kittens, puppies або kittens~puppies або ['kittens','puppies']), також може дати порожній результат або сторінку помилки.
Чи виявляє цю поведінку на потенційну вразливість? Залежить від конкретної перевірки вхідних даних та фільтрації, що стосується конкретної програми.
Для більш глибокого аналізу потрібно кілька HTTP-запитів для кожного HTTP-параметра:
1. Надішліть запит HTTP, що містить ім'я та значення стандартного параметра, та запишіть відповідь HTTP. Наприклад, page?par1=val1
2. Замініть значення параметра зміненим значенням, надішліть та запишіть відповідь HTTP. Наприклад, page?par1=HPP_TEST1
3. Надішліть новий запит, об'єднуючи кроки (1) та (2). Знову збережіть відповідь HTTP. Наприклад, page?par1=val1&par1=HPP_TEST1
4. Порівняйте відповіді, отримані всіх попередніх етапах. Якщо відповідь (3) відрізняється від (1), а відповідь (3) також відрізняється від (2), існує невідповідність імпедансу, яка може зрештою використовуватися для запуску вразливостей HPP.
Клієнтська HPP
Як і у випадку серверної HPP, ручне тестування є єдиним надійним методом аудиту веб-застосунків з метою виявлення вразливостей забруднення параметрів, що стосуються компонентів на стороні клієнта. У той час як у варіанті на стороні сервера зловмисник використовує вразливу веб-програму для доступу до захищених даних або для виконання дій, які або не дозволені, або не повинні виконуватися, а атаки на стороні клієнта спрямовані на підрив компонентів та технологій.
Щоб перевірити наявність вразливостей на стороні клієнта HPP, визначте будь-яку форму або дію, яка дозволяє вводити дані користувачем і відображає результат цього введення користувача. Сторінка пошуку ідеальна, але на полі входу в систему може не спрацювати (оскільки на ньому може не відображатися відповідь про неправильне ім'я користувача).
Аналогічно HPP на стороні сервера, забруднюйте кожен параметр HTTP %26HPP_TEST і шукайте входження, декодовані по URL, з корисного навантаження, наданого користувачем:
• &HPP_TEST
• &HPP_TEST
• … і інші
Зокрема, зверніть увагу на відповіді , що мають вектори HPP data, src, href атрибути або форми дії. Знову ж таки, чи буде ця поведінка за умовчанням виявляти потенційну вразливість, залежить від конкретної перевірки вхідних даних, фільтрації та бізнес-логіки програми. Крім того, важливо зазначити, що ця вразливість також може впливати на параметри рядка запиту, що використовуються в XMLHttpRequest (XHR), створенні атрибутів середовища виконання та інших технологіях плагінів (наприклад, змінні flashvars Adobe Flash).