Шта је контаминација HTTP параметара и зашто представља стварни ризик?

Када говоримо о безбедности веб апликација, многи људи само помисле на Грешке SQL инјекције, XSS-а или аутентификацијеМеђутим, годинама постоји прилично тиха техника која и даље остаје непримећена у многим ревизијама: контаминација или загађење HTTP параметара, позната као Загађење HTTP параметара (HPP) o Контаминација HTTP параметара.

Ова врста рањивости искоришћава начин на који различите серверске технологије и оквири управљају дуплирани параметри у истом HTTP захтевуАко апликација није спремна за то, нападач може да промени интерну логику, заобиђе валидације, превари заштитне зидове веб апликација (WAF), па чак и преузме контролу над критичним функционалностима као што су аутентификација или управљање дозволама.

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

На готово свакој модерној веб страници, корисници шаљу податке путем HTTP параметри у URL-у или у телу захтеваОви параметри омогућавају прегледачу да проследи информације апликацији: претраге, податке из образаца, изборе анкета, коментаре, податке за пријаву итд.

У типичном GET захтеву, ти подаци путују у стринг упита (све што долази после знака ? у URL-у)Парови кључ/вредност су раздвојени симболом амперсанд (&). У POST захтеву, могу бити у телу захтева, али их логика апликације на серверу обично третира веома слично: кључеви са једном или више повезаних вредности.

Многи програмски језици и оквири пружају методе за добијање оба једна вредност параметра као што је комплетна листа вредности ако се тај параметар понавља више пута. Ово је уобичајено, на пример, код поља за потврду која омогућавају вишеструки избор, где се исти назив параметра појављује неколико пута.

Проблем настаје када програмер претпостави да Постојаће само једна вредност по параметру. и користи функције које враћају једну вредност, док прегледач (или нападач) шаље више вредности са истим именом. У овом тренутку, кључни концепт долази до изражаја: приоритет вредности.

У зависности од језика, фрејмворка и веб сервера, вишеструко појављивање истог параметра може резултирати неколико понашања: да прва примљена вредностда он узима последња вредност или који је генерисан комбинација свих (на пример, спојених зарезима)Не постоји јединствени стандард, тако да се сваки технолошки стек може понашати другачије, што отвара врата веома опасним ситуацијама.

То што функција враћа само једну вредност није рањивост сама по себи, али када постоји Дуплирани параметри, а програмер није свестан тога У зависности од тога како тај приоритет функционише, апликација може добити неочекивану вредност. Управо ово аномално понашање је оно што технике искоришћавају. Загађење HTTP параметара.

Шта је загађење HTTP параметара (HPP)?

Загађивање HTTP параметара је техника која се састоји од убаците додатне параметре или разграничиваче низова упита (кодиран) унутар других постојећих параметара. Када се тај убризгани параметар декодира и поново употреби за генерисање новог URL-а или за конструисање другог захтева, апликација На крају укључује додатне параметре које програмер није очекивао..

Другим речима, ХПП искоришћава начин на који апликација Реконструише УРЛ-ове, обрађује обрасце и обрађује поновљене параметре.Ако унос није правилно валидиран, нападач може присилити апликацију да интерпретира вредности које нису очекиване или да укључи додатне параметре у линкове, обрасце и преусмеравања.

Технике ХПП-а су јавно представљене од стране Стефано Ди Паола и Лука Каретони на конференцији OWASP AppSec 2009. Од тада су документовани многи сценарији нападаАли чак ни данас немају исту видљивост као друге, боље познате рањивости, нити су у потпуности покривене свим аутоматизованим алатима.

Утицај напада загађења HTTP параметара у великој мери зависи од посебна логика апликацијеоквира и веб сервера. У неким случајевима последице су мање (грешке у презентацији, грешке у штампању етикета итд.), али у другима могу значити заобилажење аутентификације, измена дозвола или манипулација критичним операцијама.

Да би рањивост HPP-а била заиста искоришћена, механизам за читање параметара сервера или фрејмворка мора бити вратити вредност која није очекивана када наиђе на дуплиране параметре. Одатле, нападач може манипулисати тим приоритетом како би усмерио ток апликације у своју корист.

Како сервери обрађују дуплиране параметре

Кључни технички елемент који омогућава ХПП лежи у неједнаком понашању различитих веб сервери и бекенд језици приликом обраде поновљених параметара. Не раде сви исту ствар, и та разноликост је управо оно што омогућава нападачима да пронађу рањивости.

У неким окружењима, ако пошаљемо URL адресу типа променљива1=вредност1&променљива1=вредност2Сервер ће чувати само прва вредност (val1). У другим случајевима, биће потребно последња примљена вредност (val2). И у одређеним случајевима, као што се дешава са одређеним конфигурацијама Апацхе, две вредности су спојити интерно у листу, на пример одвојене зарезима, које ће апликација потом морати да интерпретира.

Често наведен пример је да апацхе У свом подразумеваном понашању, обично задржава прву вредност параметра и одбацује следеће, док друге технологије генеришу CSV (вредности раздвојене зарезима) листа са свим вредностима тог загађеног параметра. Ако је бекенд апликација прилагођена само једном од тих случајева, неконтролисани сценарији могу изазвати неочекиване ефекте.

Овакво руковање дуплираним параметрима не утиче само на логику видљиву кориснику, већ и интерне безбедносне контроле, валидатори уноса, рутине за аутентификацију и ауторизацијуИсти параметар може бити проверен у једном тренутку у апликацији користећи једну вредност, а у другом тренутку коришћен са другом вредношћу, све у оквиру истог захтева.

Штавише, хидроелектране се могу користити да би се искористиле предности унутрашње трансформације карактера што сам сервер ради. Документовано је, на пример, како неки сервери мењају одређене специфичне знакове (као што је знак „]“ који се замењује са „_“) током обраде, што се може користити за избегавање правила филтрирања или WAF фирмвера заснованих на регуларним изразима.

Последице и сценарији експлоатације ХЕ

Технике загађења HTTP параметара омогућавају генерисање прилично широког спектра ризичних ситуација, како на страни сервера тако и на страни клијента. Њихова озбиљност зависи од функција погођеног параметра и тачка у току апликације у коме је измењен.

Међу најзначајнијим последицама које су примећене код рањивих апликација су преписивање заштићених параметараНападач може додати више од једне вредности за критични параметар и приморати апликацију да користи управо злонамерну вредност захваљујући начину на који приоритет функционише у том специфичном окружењу.

Такође је уобичајено да ХПП дозвољавају модификација очекиваног понашања апликацијеНа пример, променом филтера у интерним претраживачима, изменом идентификатора ресурса, манипулисањем операцијама гласања или варирањем параметара који контролишу пословну логику (као што су администраторске заставице, режими отклањања грешака или стања трансакција).

Још једна важна последица је избегавање валидација уносаАко код за безбедносну валидацију испита прво појављивање параметра, али се стварна операција изврши са каснијим појављивањем, нападач може заобићи наизглед добро имплементиране безбедносне контроле. Ово је виђено у случајевима заобилажење аутентификације и контроле приступа.

У сложенијим контекстима, ХПП може да покрене интерне грешке апликације, излагање осетљивих информација, приступ променљивим ван предвиђеног опсега па чак и коришћење спојених параметара који, када се поново саставе, формирају корисне терете које WAF није детектовао приликом анализе сваког параметра засебно.

Што се тиче утицаја, напади су примећени са обе стране. страна сервера (заобилажење WAF-а, измена преписивања URL-ова, форсирање различитих интерних рута) од страна клијента (убризгавање параметара у линкове и обрасце ради обмане жртава путем посебно манипулисаних УРЛ адреса).

Класичан пример ХПП-а у апликацији за гласање

Да бисмо боље разумели како функционише напад загађења HTTP параметара, пример Веб апликација за гласање написана у JSP-угде је корисницима дозвољено да гласају за свог омиљеног кандидата на различитим изборима.

Апликација прима преко параметра који се зове elections_id Идентификатор тренутних избора. Са овом вредношћу, сервер генерише страницу са списком доступних кандидата, сваки са линком за гласање. Метода Захтев.гетПараметар("пар") У JSP-у, када постоји више вредности за исти параметар, увек враћа прва вредност.

Замислимо URL овако: http://servidor/eleccion.jsp?eleccion_id=4568Добијена страница приказује линк за гласање за сваког кандидата, на пример:

КСНУМКС линкГласам за господина Вајта
КСНУМКС линкГласам за госпођу Грин

Претпоставимо да злонамерни корисник, који подржава одређеног кандидата, схвати да апликација не успешно валидира параметар choice_idКористећи рањивост HPP-а, одлучује да убризга параметар кандидат унутар тог choice_id-а, кодирајући разграничнике низа упита.

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

Када жртва кликне на тај манипулисани URL, наизглед приступа исправним изборима. Међутим, пошто апликација користи вредност election_id за конструисање линкова за гласање, декодирајући убризгану вредност... На крају се у резултујући низ упита укључује додатни кандидат..

Резултат је да интерно генерисане везе постају нешто попут овога:

КСНУМКС линкГласам за господина Вајта
КСНУМКС линкГласам за госпођу Грин

Није битно на који од два линка жртва кликне: скрипту voting.jsp увек прима две инстанце параметра кандидатагде је прва вредност зелене боје. Пошто програмер користи стандардну Јава функционалност за добијање једне вредности, добија само прву вредност параметра кандидата и одбацује другу, која би забележила стварни глас корисника.

Захваљујући овом понашању, HPP рањивост омогућава нападачу приморати све гласове дате на тој страници да иду њиховом кандидатубез обзира на изборе жртве у интерфејсу. Ово је веома јасан пример како наводно „једноставно“ управљање параметрима може имати директан утицај на интегритет података и пословна логика.

Заобилажење аутентификације: случај Блогера

Један од најозлоглашенијих примера искоришћавања HTTP параметара догодио се у блог систему блоггерРањивост у обради параметара омогућила је нападачима да добију приступ постаните администратори туђих блоговаједноставним манипулисањем параметара POST захтева.

Проблематични захтев је био отприлике овакав (поједностављујући синтаксу):

ПОСТ /add-authors.do HTTP/1.1
сецурити_токен=аттацкертокен&блогИД=аттацкерблогидвалуе&блогИД=вицтимблогидвалуе&аутхорсЛист=аттацкермаил%40гмаил.цом&ок=Позови

Проблем је лежао у чињеници да је механизам за аутентификацију и безбедносну верификацију Само сам гледао/ла први параметар blogID који је стигао у захтеву, потврђујући да корисник има дозволе за тај блог. Међутим, стварна операција коју је гостујући аутор додао извршена је коришћењем друго појављивање blogID-а, што је одговарало блогу жртве.

Захваљујући овој унутрашњој контрадикцији, начин на који је сервер обрадио дуплирани параметриНападач је успео да прође безбедносне провере за свој блог, али је извршио акцију на другом блогу. Резултат је био... потпуно заобилажење аутентификације са једним добро конструисаним захтевом.

Овај случај веома добро показује како ХПП није само „техничка занимљивост“, већ техника са стварни утицаји на системе великих добављачаШтавише, истиче важност безбедносних провера и извршавања операција користећи потпуно исте вредности параметара, без зависности од неконтролисаног приоритета.

HPP и заштитни зид веб апликација (WAF)

Многе организације се ослањају на WAF као додатни слој за заштиту својих веб апликација од познатих напада. Ови заштитни зидови су обично засновани на правила и потписи (регуларни изрази) који се примењују на параметре, заглавља, па чак и на тело HTTP захтева.

Проблем је у томе што, у присуству дуплираних параметара, нападач може фрагментирати злонамерни корисни терет на неколико вредности истог параметраИако WAF анализира сваки параметар засебно, могуће је да се ниједна од изолованих вредности не подудара са потписима напада, тако да захтев пролази филтере без блокирања.

Када тај захтев стигне до веб сервера, апликативног мотора или самог сервера поново саставља вредности према својој унутрашњој логици (на пример, спајањем зарезима или узимањем последњег), што резултира низом који, као целина, представља напад. На овај начин, иста техника загађења параметара омогућава заобићи WAF-ове који нису опремљени за анализу спојеног скупа вредности.

Поред тога, неки WAF-ови који не функционишу као обрнути прокси А они који немају потпуни увид у ток између клијента и сервера, већ делују више као тачкасти филтери, могу бити посебно рањиви на ове HPP заобилазнице. Они који су засновани на технологијама као што су Apache са системом за бодовање параметара и статистичку анализу Они имају тенденцију да се боље понашају суочени са оваквим техникама.

Укратко, HPP показује да чак и са правилно конфигурисаним WAF-ом, Безбедност није загарантована Ако сама логика апликације и сервера погрешно обрађује дуплиране параметре, заштита мора бити свеобухватна и узети у обзир како се захтеви обрађују на свим нивоима.

Стварни случајеви, алати и распрострањеност ХПП-а

Академска истраживања и рад стручњака за безбедност показали су да загађење HTTP параметара није ни близу ретке ситуације. Пројекти као што су PAPAS (Систем за анализу загађења параметара), које су водили истраживачи попут Кармен Торано, дизајниране су управо да аутоматски детектује рањивости ХПП-а у великим веб апликацијама.

У експериментима спроведеним на више од 5000 веома популарних веб-сајтова (према ранг листама попут Алексе), примећено је да скоро 30% анализираних сајтова Садржали су барем једну страницу рањиву на HPP. То јест, било је могуће убацити кодирани параметар у други постојећи и проверити да ли се декодиран појављује у неком резултујућем URL-у или облику.

Још је упечатљивије то што је близу 47% пронађених рањивости (што је еквивалентно око 14% укупног броја локација) су заиста били експлоатисаномогућавајући нападе који су ишли даље од једноставних недостатака у презентацији. Међу погођеним сајтовима били су Велика имена попут Мајкрософта или ГуглаОво јасно показује да чак ни технолошки гиганти нису изузети од ових проблема.

Алати попут ПАПАС Они су послужили за анализу и квантификацију проблема, али су такође истакли тешкоћу аутоматски детектује ХППМноги традиционални скенери веб рањивости не разматрају темељно сценарије дуплираних параметара или генеришу веома велики број лажно позитивних резултата.

Поред специфичних решења као што је POTATOES, постоје и екстензије као што су HPP Finder за Google ChromeОви алати су дизајнирани да открију потенцијалне векторе HPP напада у URL-овима и HTML обрасцима. Иако могу помоћи у идентификацији сумњивих тачака (на пример, обрасци који поново користе параметре без одговарајуће валидације), они не представљају није комплетно решење нити замена за детаљну безбедносну ревизију.

Још један алат који се широко користи у екосистему безбедносног тестирања је ОВАСП ЗАПшто укључује екстензије и скрипте за тестирање различитих вектора, укључујући и оне који се односе на параметре у низу упита. Међутим, у конкретном случају HPP-а, и даље је потребно комбиновати аутоматизоване алате са ручна анализа и разумевање тока апликације.

HPP у интерним претраживачима и примери попут Apple.com

ХПП-ови нису примећени само у системима за управљање блоговима или административним панелима, већ се појављују и у наизглед безопасне функције као што су претраживачи ознака на онлајн форумима и заједницама. Упечатљив пример је пронађен у Аппле форуми, где је управљање загађеним ознакама и параметрима показало необично понашање.

На овим форумима, одабир ознаке у интерфејсу је додао параметар ознаке Низ упита у URL-у је прослеђен као вредност изабране ознаке. Бекенд апликација је преузела ову вредност, претражила теме са том ознаком и приказала резултате кориснику. Ако је изабрано више ознака, све су додате. у истом параметру ознака, одвојено оператором сабирања (+)тако да је бекенд био спреман да обради ту листу.

Када је параметар tags био загађен са неколико дуплих вредности, примећено је да је бекенд технологија генерисала листа одвојена зарезима (CSV) са свим вредностима параметара који су загађени. Апликација је била у стању да делимично обради ту листу (открије различите ознаке), али Није исправно одштампао све етикете. у текстуалном пољу претраживача.

У овом конкретном контексту, није изгледало да постоји безбедносна грешка која се може искористити, али је било јасно да Било је сценарија које програмери нису узели у обзирУ другим, мање невиним применама, слично понашање може довести до неслагања између онога што је валидирано, онога што се користи и онога што се приказује кориснику, са озбиљнијим последицама.

Анализа основних технологија на форумима као што је Еплов (на пример, Apache са J2EE у позадини) показује да се многи модерни стекови понашају слично серверима попут IIS-а или комбинацијама попут Apache-а са Python-ом приликом руковања загађеним параметрима, генерисања листа одвојених зарезима и делегирања коначне обраде тих вредности логици апликације.

Овакви примери служе као подсетник да Није довољно да „изгледа да функционише“ у нормалним случајевима.Морате систематски тестирати како апликација реагује када јој се шаљу дуплирани параметри, чудно кодиране вредности, необичне комбинације итд., јер је ту HPP место где проналази своју нишу.

Детекција и ублажавање загађења HTTP параметара

Откривање и ублажавање ХПП захтева хибридни приступ који комбинује добре праксе безбедног развоја, правилна конфигурација сервера и коришћење специфичних алатаНије довољно ослањати се на WAF да све поправи, јер као што смо видели, много пута је управо тај слој тај који може бити преварен.

Са становишта развоја, неопходно је да програмери Имајте на уму да параметар може имати више вредности и морају експлицитно одлучити како да поступају у том случају. Не би требало да се ослањају на подразумевани језик или понашање оквира без темељног разумевања како функционише приоритет вредности.

Такође се препоручује да се на критичним тачкама, као што су аутентификација, ауторизација, осетљиве операције или важне промене стањаСтрого је валидирано да се параметри појављују само једном, одбацујући захтеве са дуплираним параметрима или, барем, евидентирајући их за анализу.

Што се тиче инфраструктуре, препоручљиво је преиспитати конфигурације веб сервера и фрејмворка Да би се тачно разумело шта се дешава када се прими поновљени параметар: да ли се задржава први, последњи или сви спојени. Одатле се логика апликације може прилагодити како би се избегла неслагања између валидације и стварне употребе вредности.

Што се тиче алата, поред уобичајених скенера рањивости, корисно је укључити циљана решења као што су ПАПАС или тип екстензија Проналазач ХЕ у току тестирања. Ако се користи OWASP ZAP или други алати за тестирање продора, вредно је дизајнирати посебне скрипте које генеришу захтеви са дуплираним параметрима и вредностима кодираним на различите начине да посматрате реакцију апликације.

Коначно, важно је признати да је ХПП проблем много распрострањенији него што се обично мислиОво је посебно тачно код великих апликација са много годинама еволуције. Комбиновање обуке, прегледа кода, аутоматизованог тестирања и добро осмишљеног ручног тестирања је најбољи начин да се ове грешке држе под контролом.

Контаминација HTTP параметара је с правом заслужила своје место међу техникама веб напада које би сваки развојни и безбедносни тим требало да има на уму: Дискретно је, тешко га је видети једноставним погледом на трупце и може имати веома озбиљне последице. ако утиче на кључне параметре пословне логике или безбедносних контрола. Разумевање како се дуплирани параметри обрађују у вашем стеку и активно тестирање ових сценарија један је од оних задатака који у почетку могу деловати помало заморно, али прави сву разлику између само функционалне апликације и оне која је заиста робусна на напредне нападе.