Атака на сістэмы фронтэнд-бэкенд, якая дазваляе ўклінавацца ў іншыя запыты

Раскрыты дэталі новай атакі на сайты, якія выкарыстоўваюць мадэль фронтэнд-бэкенд, напрыклад, якія працуюць праз сеткі дастаўкі кантэнту, балансавальнікі або проксі. Атака дазваляе праз адпраўку вызначаных запытаў укліньвацца ў змесціва іншых запытаў, якія апрацоўваюцца ў тым жа струмені паміж фронтэндам і бэкэндам. Прапанаваны метад паспяхова ўжыты для арганізацыі нападу, якая дазваляе перахапляць параметры аўтэнтыфікацыі карыстачоў сэрвісу PayPal, які выплаціў даследнікам каля 40 тысяч даляраў у рамках праграмы інфармавання аб наяўнасці невыпраўленых уразлівасцяў. Атака таксама дастасавальная для сайтаў, якія выкарыстоўваюць сетку дастаўкі кантэнту Akamai.

Сутнасць праблемы ў тым, што фронтэнды і бэкэнды часта забяспечваюць розны ўзровень падтрымкі пратакола HTTP, але пры гэтым інкапсулююць запыты розных карыстальнікаў у агульны канал. Для сувязі які прымае запыты фронтэнда і апрацоўваючага запыты бэкенда ўсталёўваецца доўгажывучае TCP-злучэнне, праз якое транслююцца запыты карыстачоў, якія перадаюцца па ланцужку адзін следам за іншым з падзелам сродкамі пратаколу HTTP. Для падзелу запытаў могуць выкарыстоўвацца загалоўкі "Content-Length" (вызначае агульны памер дадзеных у запыце) і "Transfer-Encoding: chunked» (дазваляе перадаваць дадзеныя па частках, паказваючы блокі рознага памеру ў фармаце «{памер}\r\n{блок}\r\n{памер}\r\n{блок}\r\n0»).

Праблема ўзнікае, калі фронтэнд падтрымлівае толькі "Content-Length", але ігнаруе "Transfer-Encoding: chunked" (напрыклад, так рабіў CDN Akamai) або наадварот. У выпадку падтрымкі Transfer-Encoding: chunked» на абодвух баках для нападу могуць выкарыстоўвацца асаблівасці рэалізацыі парсераў HTTP-загалоўкаў (напрыклад, калі фронтэнд ігнаруе радкі выгляду «Transfer-Encoding: xchunked», » Transfer-Encoding: chunked», «Transfer-Encoding :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" або "Transfer-Encoding : chunked", а бэкенд паспяхова апрацоўвае іх).

У гэтым выпадку атакавалы можа адправіць запыт, у якім адначасова паказаны загалоўкі "Content-Length" і "Transfer-Encoding: chunked", але памер у "Content-Length" не адпавядае памеру chunked-ланцужкі, якая менш фактычнага значэння. Калі фронтэнд апрацуе і перанакіруе запыт у адпаведнасці з "Content-Length", а бэкенд будзе чакаць завяршэння блока на аснове "Transfer-Encoding: chunked", то канец дадзеных на падставе "Transfer-Encoding: chunked" будзе вызначаны раней і пакінуты хвост запыту атакавалага апынецца спачатку наступнага запыту, г.зн. атакавалы атрымае магчымасць прымацавання адвольных дадзеных да пачатку чужога запыту, перададзенага следам.

Для вызначэння праблемы ў выкарыстоўваным звязку фронтэнд-бэкенд праз фронтэнд можна адправіць запыт выгляду:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Праблема прысутнічае, калі бэкэнд адразу не апрацуе запыт і будзе чакаць прыходу фінальнага нулявога абмяжоўвалага блока chunked-дадзеных. Для больш поўнай праверкі падрыхтавана спецыяльная ўтыліта, якая таксама тэстуе магчымыя метады ўтойвання загалоўка "Transfer-Encoding: chunked" ад фронтэнда.

Правядзенне рэальнай атакі залежыць ад магчымасцяў атакаванага сайта, напрыклад, пры нападзе на web-дадатак Trello можна падмяніць пачатак запыту (падставіць дадзеныя выгляду «PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake») і адправіць паведамленне, улучальнае арыгінальны запыт іншага карыстача і паказаныя ў ім Cookie аўтэнтыфікацыі. Для нападу на saas-app.com аказалася магчымым ажыццявіць падстаноўку JavaScript-кода ў адказ, праз яго падстаноўку ў адзін з параметраў запыту. Для нападу на redhat.com быў выкарыстаны ўнутраны апрацоўшчык для перанакіравання на сайт атакавалага (быў падстаўлены запыт выгляду "POST /search?dest=../assets/idx?redir=//[электронная пошта абаронена]/ HTTP/1.1»).

Ужыванне метаду для сетак дастаўкі кантэнту дазваляла проста падмяніць запытаны сайт праз падстаноўку загалоўка «Host:». Атака таксама дастасавальная для арганізацыі атручвання змесціва сістэм кэшавання кантэнту і вымання прокешированных канфідэнцыйных дадзеных. Вяршыняй ужывання метаду стала арганізацыя нападу на PayPal, якая дазваляе перахапляць паролі, якія адпраўляюцца карыстачамі пры аўтэнтыфікацыі (было ажыццёўлена змена запыту iframe для выканання JavaScript у кантэксце старонкі paypal.com/us/gifts, для якой не ўжываўся CSP (Content Security Policy)).

Цікава, што ў 2005 годзе была прапанаваная падобная ў сутнасці тэхніка падмены запытаў, якая дазваляе падмяніць дадзеныя ў кэшуюць проксі (Tomcat, squid, mod_proxy) або абыйсці блакаванні міжсеткавых экранаў праз указанне некалькіх запытаў "GET" ці "POST" у рамках аднаго HTTP-сеансу.

Крыніца: opennet.ru