Cache-forgiftning og beskyttelse av cache-laget

Web cache poisoning lurer en cache til å lagre et skadelig svar som deretter leveres til andre brukere. Angriperen manipulerer en inndata som påvirker svaret, men som ikke inngår i cache-nøkkelen.

• Angriperen sender en spesialtilpasset forespørsel
• Opprinnelsesserveren gjenspeiler angriperens inndata i svaret
• Cachen lagrer svaret og leverer det til alle

Den grunnleggende årsaken er en inndata utenfor nøkkelen: en header eller parameter som endrer svaret, men som er utelatt fra cache-nøkkelen. Hvis angriperen kontrollerer den, forgifter de den delte oppføringen.

Se for deg at opprinnelsesserveren gjenspeiler X-Forwarded-Host i en generert URL, mens cachen ignorerer denne headeren. Angriperen setter den til sitt eget domene, og den cachede siden peker nå alle til ressurser som kontrolleres av angriperen.

Det viktigste forsvaret er å ta med alle inndata som påvirker svaret, i cache-nøkkelen, eller å fjerne farlige headere før caching. Gjenspeil aldri upålitelige headere i cachet innhold.

Cache deception lurer cachen til å lagre private data under en offentlig utseende URL. En angriper legger til en falsk statisk filendelse, slik at cachen behandler en sensitiv side som en cachebar ressurs.

Beskytt deg ved å cache basert på den faktiske Content-Type-verdien og eksplisitte regler, ikke bare på URL-ens filendelse. Cache aldri svar som er merket private, eller som setter autentiseringsinformasjonskapsler.

Konfigurer edge-laget slik at det fjerner headere som en angriper ikke bør kunne kontrollere, før de når opprinnelsesserveren eller cachen, for eksempel headere av typen forwarded-host med mindre de uttrykkelig er klarert.

Hvis opprinnelsesserveren må gjengi en verdi, må du validere og kode den. Bygg aldri cachebare URL-er eller skript direkte fra forespørselsheadere uten strenge tillatte lister.

Autentiserte svar bør som regel omgå delte cacher. Send innloggede forespørsler utenom den offentlige cachen, eller merk dem med private, no-store slik at de aldri deles.

Se etter avvik: plutselige cache-oppføringer med uventede verter, økning i 4xx etter en utrulling eller meldinger om at brukere ser innhold som tilhører andre. Oppdagelse gjør at du kan tømme cachen raskt.

Beskytt cachelaget ved å:

• bruke alle inndata som påvirker svaret som del av nøkkelen
• fjerne upålitelige videresendingsheadere
• cache etter innholdstype, ikke URL-filendelse
• aldri cache private eller autentiserte svar
• kode alle gjenspeilede verdier fra forespørselen

Du har lært hvordan angrepene cache poisoning og cache deception utnytter inndata utenfor nøkkelen og URL-basert caching. Du har sett flere forsvarstiltak: grundig håndtering av cache-nøkler, fjerning av upålitelige headere, caching etter innholdstype, å aldri dele autentiserte svar og overvåking etter avvik.