Какво е замърсяване на HTTP параметри и защо е реален риск?

Когато говорим за сигурност на уеб приложенията, много хора се сещат само за Неуспехи при SQL инжектиране, XSS или удостоверяванеВъпреки това, от години съществува една сравнително тиха техника, която продължава да остава незабелязана в много одити: замърсяване или замърсяване на HTTP параметрите, известно като Замърсяване на HTTP параметрите (HPP) o Замърсяване на HTTP параметри.

Този тип уязвимост използва начина, по който различните сървърни технологии и рамки управляват дублиращи се параметри в една и съща HTTP заявкаАко приложението не е подготвено за това, атакуващият може да промени вътрешната логика, да заобиколи валидациите, да заблуди защитните стени на уеб приложенията (WAF) и дори да поеме контрол над критични функционалности като удостоверяване или управление на разрешения.

Концепция за HTTP параметри и приоритет

На почти всеки съвременен уебсайт потребителите изпращат данни чрез HTTP параметри в URL адреса или в тялото на заявкатаТези параметри позволяват на браузъра да предава информация на приложението: търсения, данни от формуляри, избор на анкети, коментари, данни за вход и др.

В типична GET заявка, тези данни се пренасят в низ на заявката (всичко, което идва след знака ? в URL адреса)Двойките ключ/стойност са разделени от символа амперсанд (&). В POST заявка те могат да бъдат в тялото, но логиката на приложението на сървъра обикновено ги третира много подобно: ключове с една или повече свързани стойности.

Много езици за програмиране и рамки предоставят методи за получаване и на двете единична стойност на параметър като например пълния списък със стойности, ако този параметър се появява многократно. Това е често срещано например при квадратчета за отметка, които позволяват множествен избор, където едно и също име на параметър се появява няколко пъти.

Проблемът възниква, когато разработчикът приеме, че Ще има само една стойност за всеки параметър. и използва функции, които връщат една стойност, докато браузърът (или атакуващият) изпраща множество стойности с едно и също име. В този момент влиза в действие ключова концепция: предимство на ценностите.

В зависимост от езика, рамката и уеб сървъра, многократното появяване на един и същ параметър може да доведе до няколко поведения: че първата получена стойностче той взема последна стойност или това е генерирано комбинация от всички (например, свързани със запетаи)Няма единен стандарт, така че всеки технологичен стек може да се държи различно, което отваря вратата към много опасни ситуации.

Това, че една функция връща само една стойност, само по себе си не е уязвимост, но когато има такава Дублиращи се параметри и разработчикът не е наясно В зависимост от това как работи този приоритет, приложението може да получи неочаквана стойност. Именно това аномално поведение се използва от техниките. Замърсяване на HTTP параметрите.

Какво е HTTP параметрично замърсяване (HPP)?

Замърсяването на HTTP параметрите е техника, която се състои от инжектиране на допълнителни параметри или разделители на низове за заявки (кодиран) в рамките на други съществуващи параметри. Когато този инжектиран параметър се декодира и използва повторно за генериране на нов URL адрес или за изграждане на друга заявка, приложението В крайна сметка се включват допълнителни параметри, които разработчикът не е очаквал..

С други думи, HPP използва начина, по който приложението Той реконструира URL адреси, обработва формуляри и обработва повтарящи се параметри.Ако входните данни не са правилно валидирани, атакуващият може да принуди приложението да интерпретира стойности, различни от очакваните, или да включи допълнителни параметри във връзки, формуляри и пренасочвания.

Техниките за ВЕЦ бяха публично представени от Стефано Ди Паола и Лука Каретони на конференцията OWASP AppSec 2009. Оттогава те са документирани много сценарии за атакаНо дори и днес те нямат същата видимост като други, по-известни уязвимости, нито пък са напълно покрити от всички автоматизирани инструменти.

Въздействието на атака със замърсяване на HTTP параметри зависи до голяма степен от специфична логика на приложениетона рамката и уеб сървъра. В някои случаи последствията са незначителни (грешки при представяне, проблеми с печата на етикети и др.), но в други това може да означава заобикаляне на удостоверяването, промяна на разрешения или манипулиране на критични операции.

За да бъде уязвимостта на HPP наистина експлоатираема, механизмът за четене на параметри на сървъра или рамката трябва да бъде връща стойност, различна от очакваната когато срещне дублиращи се параметри. Оттам нататък атакуващият може да манипулира този приоритет, за да насочи потока на приложението в своя полза.

Как сървърите обработват дублиращи се параметри

Ключовият технически елемент, който прави възможно HPP, се крие в неравномерното поведение на различните уеб сървъри и езици за бекенд при обработка на повтарящи се параметри. Не всеки прави едно и също нещо и именно това разнообразие позволява на атакуващите да намират уязвимости.

В някои среди, ако изпратим URL адрес от типа променлива1=стойност1&променлива1=стойност2сървърът ще запази само първа стойност (val1). В други случаи ще е необходимо последна получена стойност (val2). И в определени случаи, както се случва с определени конфигурации на IIS, двете стойности са конкатенират вътрешно в списък, например разделени със запетаи, които приложението след това ще трябва да интерпретира.

Често цитиран пример е, че Apache В поведението си по подразбиране, обикновено запазва първата стойност на параметър и отхвърля следващите, докато други технологии генерират CSV (стойности, разделени със запетая) списък с всички стойности на този замърсен параметър. Ако бекенд приложението е адаптирано само към един от тези случаи, неконтролираните сценарии могат да причинят неочаквани ефекти.

Тази обработка на дублиращи се параметри не само засяга логиката, видима за потребителя, но и вътрешни контроли за сигурност, валидатори на входни данни, процедури за удостоверяване и оторизацияЕдин и същ параметър може да бъде проверен в един момент от приложението, използвайки една стойност, и използван в друг момент с различна стойност, всичко това в рамките на една и съща заявка.

Освен това, ВЕЦ могат да се използват, за да се възползват от вътрешни трансформации на характера което прави и самият сървър. Документирано е например как някои сървъри променят определени специфични символи (като например символът "]", който се заменя с "_") по време на обработка, което може да се използва за избягване на правила за филтриране или WAF фърмуери, базирани на регулярни изрази.

Последици и сценарии на експлоатация на ВЕЦ

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

Сред най-забележителните последици, наблюдавани при уязвимите приложения, са презаписване на защитени параметриАтакуващ може да добави повече от една стойност за критичен параметър и да принуди приложението да използва точно злонамерената стойност, благодарение на начина, по който работи приоритетът в тази специфична среда.

Също така е обичайно ВЕЦ да позволяват промяна на очакваното поведение на приложениетоНапример, чрез промяна на филтри във вътрешни търсачки, промяна на идентификатори на ресурси, манипулиране на операции за гласуване или промяна на параметри, които контролират бизнес логиката (като например администраторски флагове, режими за отстраняване на грешки или състояния на транзакции).

Друго важно следствие е избягване на валидиране на входни данниАко кодът за валидиране на сигурността проверява първото появяване на параметър, но действителната операция се извършва с по-късно появяване, нападателят може да заобиколи привидно добре внедрени контроли за сигурност. Това е наблюдавано в случаи на заобикаляне на удостоверяване и контрол на достъпа.

В по-сложни контексти, HPP може да задейства вътрешни грешки в приложението, излагане на чувствителна информация, достъп до променливи извън предвидения обхват и дори използването на конкатенирани параметри, които след повторно сглобяване образуват полезни товари, които WAF не е открил при анализа на всеки параметър поотделно.

По отношение на въздействието, атаки са наблюдавани и от двете страни. сървърна страна (заобикаляне на WAF, промяна на пренаписване на URL адреси, налагане на различни вътрешни маршрути) към страна на клиента (инжектиране на параметри във връзки и формуляри за заблуда на жертвите чрез специално манипулирани URL адреси).

Класически пример за HPP в приложение за гласуване

За да разберем по-добре как работи атаката тип „замърсяване на HTTP параметри“, ще разгледаме примера на Уеб приложение за гласуване, написано на JSPкъдето потребителите могат да гласуват за любимия си кандидат в различни избори.

Приложението получава чрез параметър, наречен elections_id Идентификаторът на текущите избори. С тази стойност сървърът генерира страница, в която са изброени наличните кандидати, всеки с линк за гласуване. Методът Request.getParameter("чифт") В JSP, когато за един и същ параметър има множество стойности, винаги се връща първа стойност.

Нека си представим URL адрес като този: http://servidor/eleccion.jsp?eleccion_id=4568Получената страница показва линк за гласуване за всеки кандидат, например:

1 LinkГласувам за г-н Уайт
2 LinkГласувам за г-жа Грийн

Да предположим, че злонамерен потребител, който подкрепя определен кандидат, осъзнава, че приложението не... успешно валидира параметъра choice_idВъзползвайки се от уязвимостта на HPP, той решава да инжектира параметъра кандидат в рамките на този choice_id, кодирайки разделителите на низа на заявката.

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

Когато жертвата кликне върху този манипулиран URL адрес, тя очевидно има достъп до правилните избори. Тъй като обаче приложението използва стойността election_id, за да конструира връзките за гласуване, декодирайки инжектираната стойност... В крайна сметка се включва допълнителен кандидат в получения низ на заявката..

Резултатът е, че вътрешно генерираните връзки стават нещо подобно:

1 LinkГласувам за г-н Уайт
2 LinkГласувам за г-жа Грийн

Няма значение върху кой от двата линка кликва жертвата: скриптът 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Това ясно показва, че дори технологичните гиганти не са изключени от тези проблеми.

Инструменти като ПАПАС Те послужиха за анализ и количествено определяне на проблема, но също така подчертаха трудността на автоматично откриване на ВЕЦМного традиционни скенери за уеб уязвимости не вземат предвид подробно сценариите с дублиращи се параметри или генерират много голям брой фалшиви положителни резултати.

В допълнение към специфични решения като POTATOES, има разширения като Търсачка на HPP за Google ChromeТези инструменти са предназначени за откриване на потенциални вектори на HPP атака в URL адреси и HTML формуляри. Въпреки че могат да помогнат за идентифициране на подозрителни точки (например формуляри, които използват повторно параметри без подходяща проверка), те не представляват не е цялостно решение, нито заместител на задълбочен одит на сигурността.

Друг инструмент, широко използван в екосистемата за тестване на сигурността, е OWASP ZAPкоето включва разширения и скриптове за тестване на различни вектори, включително тези, свързани с параметри в низа на заявката. В конкретния случай на HPP обаче все още е необходимо да се комбинират автоматизирани инструменти с ръчен анализ и разбиране на потока на приложението.

HPP във вътрешни търсачки и примери като Apple.com

HPP не са наблюдавани само в системи за управление на блогове или административни панели, те се появяват и в привидно безобидни функции, като например търсачки по тагове в онлайн форуми и общности. Поразителен пример беше открит в Форуми на Apple, където управлението на замърсените етикети и параметри показа любопитни поведения.

В тези форуми, избирането на етикет в интерфейса добавяше параметър тагове На низа на заявката в URL адреса беше предадена стойността на избрания етикет. Бекенд приложението извлече тази стойност, потърси теми с този етикет и показа резултатите на потребителя. Ако бяха избрани няколко етикета, всички те бяха добавени. в същия параметър tags, разделени от оператора за събиране (+)така че бекендът беше готов да обработи този списък.

Когато параметърът tags беше замърсен с няколко дублиращи се стойности, беше наблюдавано, че backend технологията генерира списък, разделен със запетаи (CSV) с всички замърсени стойности на параметрите. Приложението успя частично да обработи този списък (да открие различните етикети), но Не отпечата всички етикети правилно. в текстовото поле на търсачката.

В този конкретен контекст не изглеждаше да има експлоатиран бъг в сигурността, но беше ясно, че Имаше сценарии, които разработчиците не бяха взети предвидВ други, по-малко безобидни приложения, подобно поведение може да доведе до несъответствия между това, което е валидирано, това, което се използва, и това, което се показва на потребителя, с по-сериозни последици.

Анализът на основните технологии във форуми като този на Apple (например, Apache с J2EE в бекенда) показва, че много съвременни стекове се държат подобно на сървъри като IIS или комбинации като Apache с Python при обработка на замърсени параметри, генериране на списъци, разделени със запетаи, и делегиране на окончателната обработка на тези стойности на логиката на приложението.

Тези видове примери служат като напомняне, че Не е достатъчно „да изглежда, че работи“ в нормални случаи.Трябва систематично да тествате как приложението реагира, когато му се изпращат дублиращи се параметри, странно кодирани стойности, необичайни комбинации и т.н., защото именно там HPP намира своята ниша.

Откриване и смекчаване на замърсяването на HTTP параметрите

Откриването и смекчаването на високоефективни предприятия (HPP) изисква хибриден подход, който съчетава добри практики за сигурно разработване, правилна конфигурация на сървъра и използване на специфични инструментиНе е достатъчно да се разчита на WAF, за да поправи всичко, защото, както видяхме, много пъти именно този слой може да бъде измамен.

От гледна точка на разработката, е от съществено значение програмистите Имайте предвид, че един параметър може да има множество стойности и те трябва изрично да решат как да се справят с този случай. Те не трябва да разчитат на език по подразбиране или поведение на рамката, без да разбират задълбочено как работи приоритетът на стойностите.

Препоръчително е също така в критични точки, като например удостоверяване, оторизация, чувствителни операции или важни промени в състояниетоСтрого е валидирано, че параметрите се появяват само веднъж, като заявките с дублиращи се параметри се отхвърлят или поне се регистрират за анализ.

Що се отнася до инфраструктурата, препоръчително е да се преразгледа конфигурации на уеб сървър и рамка За да се разбере точно какво се случва, когато се получи повтарящ се параметър: дали се запазва първият, последният или всички конкатенирани. Оттам нататък логиката на приложението може да се коригира, за да се избегнат несъответствия между валидирането и действителното използване на стойността.

По отношение на инструментите, в допълнение към обичайните скенери за уязвимости, е полезно да се включат целенасочени решения, като например ПАПАС или тип разширения Търсачка на ВЕЦ в тестовия поток. Ако се използва OWASP ZAP или други инструменти за тестване за проникване, е целесъобразно да се проектират специфични скриптове, които генерират заявки с дублиращи се параметри и стойности, кодирани по различни начини да наблюдавате реакцията на приложението.

Накрая е важно да се признае, че ВЕЦ е проблем много по-разпространено, отколкото се смятаТова е особено вярно за големи приложения с много години на еволюция. Комбинирането на обучение, преглед на код, автоматизирано тестване и добре проектирано ръчно тестване е най-добрият начин да се контролират тези грешки.

Замърсяването на HTTP параметрите с право си е спечелило място сред техниките за уеб атака, които всеки екип за разработка и сигурност трябва да има предвид: Дискретно е, трудно се вижда с един поглед към дневниците и може да има много сериозни последици. ако това засяга ключови параметри на бизнес логиката или контролите за сигурност. Разбирането как се обработват дублиращи се параметри във вашия стек и активното тестване на тези сценарии е една от онези задачи, които в началото може да изглеждат малко досадни, но това прави цялата разлика между просто функционално приложение и такова, което е наистина устойчиво на напреднали атаки.