Техника за отравяне на уеб кеш, наречена инжектиране на ключове за кеша (cache key injection), може да позволи на атакуващите да достъпват защитени данни, да нарушават работата на уебсайтове или да отравят кеширани страници със зловредно съдържание.
Изследването на Алекс Брумен показва, че на атакуващите не винаги е необходимо да експлоатират стойности от HTTP заявки, които не са част от ключа за кеширане (unkeyed values) – традиционният фокус при атаките за отравяне на кеша.
Вместо това те могат да злоупотребяват със стойности, които вече са включени в ключа на кеша, когато уеб сървърът ги комбинира без ясни разделители. Уеб кешовете подобряват производителността, като съхраняват отговорите и ги генерират отново, когато последващи заявки създадат същия ключ за кеша.
В Nginx ключът за кеша може да бъде изграден от части от HTTP заявка, включително схемата на протокола, името на хоста, URI, заявката (query string), бисквитките или заглавните части (headers).
Стандартната конфигурация на Nginx може да изглежда така: proxy_cache_key "$scheme$host$request_uri$http_accept";.
Проблемът се появява, когато променливите компоненти на заявката са съединени директно. Ако няма разделители между тях, две различни заявки могат да създадат един и същ краен ключ за кеша.
Уеб кеш ключове за достъп до данни и отравяне на сайтове
Например, легитимна заявка за /home със заглавна част Accept: / може да генерира същия ключ като заявка от атакуващ за /h с Accept: ome*/*.
Въпреки че заявените пътища са различни, Nginx може да третира и двете заявки като един и същ обект в кеша след конкатенацията на стойностите. Тoва колизия позволява на атакуващия да съхрани един отговор под ключ, който по-късно съвпада с различна, легитимна заявка.
Едно от демонстрираните въздействия засяга крайни точки с ограничен достъп като /admin. В концептуалното доказателство (proof of concept) Nginx позволява достъп до административния панел само от localhost. В същото време неговият кеш използва персонализиран ключ, съдържащ URI на заявката и заглавната част Accept.
Администратор би могъл да кешира страницата /admin от localhost. Външен атакуващ, който не може да заяви /admin директно, би могъл да заяви различен път като /ad, поставяйки оставащия фрагмент min в контролирана от него стойност в заглавната част.
Ако манипулираната заявка създаде същия ключ за кеша като /admin, сървърът може да върне предварително кеширания административен отговор, без да оценява първоначалното правило за достъп до защитения път. Това създава форма на измама с уеб кеш (web cache deception), която не изисква от жертвите да щракват върху специално изработена връзка.
Техниката може също така да причини отравяне на кеша за отказ на услуга (CPDoS). Атакуващ може да заяви несуществуващ ресурс като /h, докато манипулира заглавна част така, че нейният ключ за кеша да влезе в колизия с /home.
Тъй като заявката на атакуващия връща кеширан отговор 404 Not Found, последващите посетители, заявяващи реалната страница /home, могат да получат отровения отговор за грешка, докато кешът изтече или бъде изчистен.
Брумен също така демонстрира по-сериозен сценарий, включващ объркване на протоколните схеми HTTP и HTTPS. Ако ключът на Nginx започва с $scheme$host$request_uri, атакуващ може да измести последното s в https в злонамерена стойност на заглавната част Host, изпратена през HTTP.
Например, HTTP заявка, използваща хоста sdummywebsite.localhost, може да генерира същия ключ като нормална HTTPS заявка към dummywebsite.localhost.
Ако браншовият сървър (backend) отразява стойността на Host в изходния код на скрипт, отровената кеширана страница може да зареди JavaScript от домейн, контролиран от атакуващия. Това може да доведе до съхранени междинни скриптове на уебсайта (stored cross-site scripting / XSS).
Изследването разглежда и среди, използващи Cloudflare пред оригинален Nginx кеш. Атакуващите могат да използват заглавната част Authorization, за да накарат Cloudflare да заобиколи периферния си кеш (edge cache), препращайки заявката към Nginx.
Ако Nginx все пак кешира този отговор, атакуващият може да се насочи директно към вътрешния оригинален кеш. Последваща заявка може след това да извлече отровения запис от Nginx, особено след като периферният запис в Cloudflare изтече или не съществува.
Основната мярка за защита е да се избягва конкатенацията на необработени фрагменти от ключове за кеша без граници. Хеширането на двусмислен ключ не решава проблема, тъй като две различни комбинации от заявки все пак могат да генерират един и същ основен низ.
Вместо следната конфигурация: proxy_cache_key "$scheme$host$request_uri$http_accept";, администраторите трябва да използват ясни разделители или структурирано кодиране: proxy_cache_key "$scheme|$host|$request_uri|$http_accept";.
Организациите трябва също така да избягват кеширането на автентифицирани отговори или такива с ограничен достъп в споделени кешове, да валидират стриктно заглавните части Host, да пренасочват HTTP трафика към HTTPS и да гарантират, че поведението на кеша е последователно в CDN и оригиналните слоеве.
Констатациите показват, че ключовете за кеша не трябва да се считат за безопасни само защото стойностите от заявките са включени в тях. Без ясни граници, стойности, контролирани от атакуващ, могат да влязат в колизия с легитимни заявки и да превърнат функцията за производителност в риск от изтичане на данни, дефейсмент на уебсайт или отказ на услуга.