Атака срещу предни и бек-енд системи, която ни позволява да проникнем в заявки на трети страни

Разкрити подробности за нова атака срещу сайтове, които използват модел от предния и задния край, като тези, работещи през мрежи за доставка на съдържание, балансьори на натоварването или проксита. Атаката позволява чрез изпращане на определени заявки да се вклини в съдържанието на други заявки, обработвани в същата нишка между интерфейса и бекенда. Предложеният метод беше успешно използван за организиране на атака, която направи възможно прихващането на параметрите за удостоверяване на потребителите на услугата PayPal, която плати на изследователите около 40 хиляди долара като част от програма за информиране за наличието на неотстранени уязвимости. Атаката е приложима и за сайтове, използващи мрежата за доставка на съдържание Akamai.

Същината на проблема е, че предните и задните части често предоставят различни нива на поддръжка за HTTP протокола, но в същото време капсулират заявки от различни потребители в общ канал. За свързване на заявките за получаване на предния край и заявките за обработка на задния край се установява дълготрайна TCP връзка, чрез която се предават потребителски заявки, предавани по веригата една след друга, разделени с помощта на HTTP протокола. За да разделите заявките, заглавките „Content-Length“ (определя общия размер на данните в заявката) и „Трансфер-кодиране: на парчета"(позволява ви да прехвърляте данни на части, като посочвате блокове с различни размери във формат "{размер}\r\n{блок}\r\n{размер}\r\n{блок}\r\n0").

Проблемът възниква, ако интерфейсът поддържа само „Content-Length“, но игнорира „Transfer-Encoding: chunked“ (например Akamai CDN направи това) или обратното. Ако 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“ не съответства на размера на веригата на парчета, което е по-малка от действителната стойност. Ако фронтендът обработва и препраща заявката според „Content-Length“ и бекендът изчаква блокът да завърши въз основа на „Transfer-Encoding: chunked“, тогава краят на данните въз основа на „Transfer-Encoding: chunked“ ще бъде определена по-рано и оставащата опашка на заявката, която нападателят ще бъде в началото на следващата заявка, т.е. нападателят ще може да прикачи произволни данни към началото на нечия друга заявка, предадена следващата.

За да определите проблема в използваната комбинация frontend-backend, можете да изпратите заявка като тази чрез frontend:

POST /за HTTP/1.1
Хост: example.com
Трансфер-кодиране: на парчета
Content-Length: 4

1
Z
Q

Проблемът е налице, ако бекендът не обработи незабавно заявката и изчака пристигането на последния нулев ограничаващ блок от разкъсани данни. За по-пълна проверка подготвени специална помощна програма, която също тества възможни методи за скриване на заглавката „Transfer-Encoding: chunked“ от интерфейса.

Извършването на истинска атака зависи от възможностите на атакувания сайт, например, когато атакувате уеб приложението Trello, можете да замените началото на заявката (заместете данни като „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) и изпращане на съобщение, включващо оригиналната заявка на потребител трета страна и посочената в нея бисквитка за удостоверяване. За атака на saas-app.com се оказа възможно да се замени JavaScript код в отговора, като се замени в един от параметрите на заявката. За атаката срещу redhat.com е използван вътрешен манипулатор за пренасочване към уебсайта на атакуващия (заявка от формата „POST /search?dest=../assets/idx?redir=//[имейл защитен]/ HTTP/1.1").

Използването на метода за мрежи за доставка на съдържание направи възможно просто да се замени исканият сайт чрез заместване на заглавката „Host:“. Атаката може да се използва и за отравяне на съдържанието на системите за кеширане на съдържание и извличане на кеширани поверителни данни. Върхът на метода беше организирането на атака срещу PayPal, което направи възможно прихващането на пароли, изпратени от потребителите по време на удостоверяване (заявката за iframe беше модифицирана, за да изпълнява JavaScript в контекста на страницата paypal.com/us/gifts, за която CSP (политика за сигурност на съдържанието) не е приложена).

Интересното е, че през 2005 г. имаше предложено по същество подобна техника за подправяне на заявки, която ви позволява да подправяте данни в кеширащи проксита (Tomcat, squid, mod_proxy) или да заобиколите блокирането на защитната стена, като посочите няколко заявки „GET“ или „POST“ в рамките на една HTTP сесия.

Източник: opennet.ru