Ограничена уязвимост за CRLF инжектиране може да бъде ескалирана до сериозна атака за HTTP десинхронизация, отравяйки CDN кешове и доставяйки зловреден XSS код на потребители на легитимни уебсайтове. Атаката, наречена „CRLF-Powered Desync“, започва, когато дадено приложение обработва неправилно кодирани символи за връщане на каретката и преминаване на нов ред, обикновено представени като %0d%0a.
Тези символи маркират нови редове в HTTP съобщенията. Ако сървър от предния край (front-end) ги декодира, преди да препрати заявка към бекенд сървър, атакуващият може да инжектира нови HTTP заглавни части или да промени структурата на заявката нагоре по веригата.
Една рискова конфигурация включва внедрявания на Nginx, които поставят променливи като $uri в директиви proxy_pass. Nginx може да нормализира и URL-декодира пътя, преди да го препрати нагоре. Това може да преобразува кодираните CRLF последователности в действителни прекъсвания на редове, позволявайки инжектиране на заглавни части на заявката. Полученото несъответствие между начина, по който различните инфраструктурни слоеве интерпретират една и съща заявка, може да създаде условия за контрабанда на HTTP заявки (HTTP request smuggling) или десинхронизация.
При атака с десинхронизация, прокси сървърът от предния край и бекенд приложението се разминават в мнението си за това къде свършва една HTTP заявка и къде започва следващата. Киберпрестъпниците могат да използват това объркване, за да вмъкнат допълнителна заявка в споделена връзка. Отговорите, предназначени за един потребител, могат да бъдат доставени на друг, причинявайки смесване на акаунти, излагане на чувствителни данни, отказ от услуга (DoS) или отравяне на кеша. Изследователите показаха, че проблемът може да стане особено опасен в рамките на CDN инфраструктурата.
В един от случаите отравянето на опашката от отговори е възникнало на ниво CDN, а не само в целевото приложение. Това създава риск заявки и отговори от несвързани сайтове, хоствани на същата CDN инфраструктура, да се смесят. Подобни инциденти могат да разкрият сесийни бисквитки, токени за оторизация и други чувствителни данни, ако изолацията на връзката се провали. По-сериозен сценарий включва отравяне на кеширана от CDN страница, превръщайки кешираното съдържание в механизъм за доставка на XSS.
Чрез комбиниране на CL.TE десинхронизация, задвижвана от CRLF, с внимателно подбрано поведение при HEAD заявка, изследователите са успели да накарат CDN да кешира злонамерен отговор. Отрованият ресурс след това може да бъде сервиран на реални потребители, позволявайки на контролиран от атакуващия JavaScript код да се изпълни в контекста на техния браузър. Изследването също така предупреждава, че тези атаки могат да бъдат съвместими с браузъра.
В някои случаи нормалната навигация в браузъра или JavaScript fetch() заявки могат да пренасят създадените кодирани данни, необходими за задействане на десинхронизацията. Ако атакуващият постигне XSS на страница, достъпна от жертвата, браузърът на жертвата може многократно да стартира същите злонамерени заявки, създавайки саморазпространяващ се „десинхронизационен червей“.
Организациите трябва да третират CRLF и инжектирането на заглавни части в заявки като констатации с висока степен на сериозност, а не като незначителни проблеми с валидирането на входните данни. Защитниците трябва да прегледат правилата за обратни проксита, да избягват използването на декодирани URI променливи в Nginx proxy_pass и return директиви и да гарантират, че всеки слой от стека прилага последователни правила за HTTP анализ.
Екипите трябва също така да тестват съвместно поведението на CDN, балансьора на натоварването, проксито и оригиналния сървър, тъй като най-сериозните сривове възникват от разлики в анализаторите в тези слоеве. Преминаването на трафика нагоре по веригата към HTTP/2, където е практично, изолирането на бекенд връзките, ранното отхвърляне на кодирани контролни символи и редовното тестване за контрабанда на заявки могат значително да намалят излагането на риск.