Cache poisoning og beskyttelse af cachelaget

Forgiftning af webcache narrer en cache til at gemme et skadeligt svar, som derefter leveres til andre brugere. Angriberen manipulerer et input, der påvirker svaret, men ikke indgår i cache-nøglen.

• Angriberen sender en specialkonstrueret forespørgsel
• Oprindelsesserveren indsætter angriberens input i svaret
• Cachen gemmer det og leverer det til alle

Den grundlæggende årsag er et input uden nøgle: en header eller parameter, der ændrer svaret, men er udeladt fra cache-nøglen. Hvis en angriber kontrollerer det, forgifter vedkommende den delte post.

Forestil dig, at oprindelsesserveren indsætter X-Forwarded-Host i en genereret URL, men at cachen ignorerer denne header. En angriber sætter den til sit eget domæne, og den cached side peger nu alle brugere på angriberens ressourcer.

Det vigtigste forsvar er at medtage hvert input, der påvirker svaret, i cache-nøglen eller fjerne farlige headere før caching. Indsæt aldrig ikke-betroede headere direkte i output, der caches.

Cachebedrag narrer en cache til at gemme private data under en offentligt udseende URL. En angriber tilføjer en falsk statisk filendelse, så cachen behandler en følsom side som et aktiv, der kan caches.

Beskyt dig ved at cache baseret på den faktiske Content-Type og udtrykkelige regler, ikke kun på URL'ens filendelse. Cache aldrig svar, der er markeret med private, eller som angiver godkendelsescookies.

Konfigurér edge-laget til at fjerne headere, som en angriber ikke bør kunne kontrollere, før de når oprindelsesserveren eller cachen, f.eks. headere af typen forwarded-host, medmindre de udtrykkeligt er betroede.

Hvis oprindelsesserveren skal gengive en værdi, skal du validere og kode den. Opbyg aldrig URL'er eller scripts, der kan caches, direkte ud fra forespørgselsheadere uden strenge tilladelseslister.

Godkendte svar bør som regel omgå delte caches. Send forespørgsler fra brugere, der er logget ind, uden om den offentlige cache, eller markér dem med private, no-store, så de aldrig deles.

Hold øje med uregelmæssigheder: pludselige cacheposter med uventede værter, stigninger i 4xx efter en udrulning eller meldinger om, at brugere ser fremmed indhold. Opdagelse gør det muligt at rydde hurtigt.

Beskyt cachelaget ved at:

• bruge alle input, der påvirker svaret, som en del af nøglen
• fjerne ikke-betroede forwarding-headere
• cache efter indholdstype, ikke URL-filendelse
• aldrig cache private eller godkendte svar
• kode alle værdier fra forespørgslen, der indsættes igen

Du har lært, hvordan angreb med cacheforgiftning og cachebedrag udnytter input uden nøgler og URL-baseret caching. Du har set forsvarsmekanismer som grundig håndtering af cache-nøgler, fjernelse af ikke-betroede headere, caching efter indholdstype, aldrig at dele godkendte svar samt overvågning efter uregelmæssigheder.