Macht man das clientseitige Invalidieren in der Praxis wirklich? Ist es kein Sicherheitsproblem wenn der Client entscheidet wann der Applikation Server angesprochen wird? Stichwort: DoS
no-cache wird wahrscheinlich an erster Stelle verwendet um garantiert eine frische Antwort, die nicht aus dem Cache kommt zu erhalten. Bei der Invalidierung für andere z.B. nach einem PUT ist man darauf angewiesen, dass der Client wirklich die Invalidierung durchführt. Was nicht einfach ist, wenn man selbst nicht den Client implementiert. Caches bieten natürlich auch eine Angriffsoberfläche. Man kann z.B. versuchen mit Cache Poisening eine Attacke zu fahren. Dabei wird z.B. nach einem HTTP-Header gesucht, der nicht in den Cache-Key eingeht, der aber einen Fehler verursacht, der dann gecached wird. Um den Cache für eine DOS zu umgehen, genügt es, den Cache-Key z.B. mit einem zusätzlichen Query-Parameter zu verändern. Es kann je nach Anforderung auch Sinn machen, den no-cache nicht zuzulassen.
@@thomas-bayer danke für die ausführliche Antwort. 😁. Bzgl. der GET Parameter sollte der Cache imho nur geprüfte Werte in den Cache ablegen. Ansonsten könnte man den Cache fluten bis er in die Knie geht. Bei Web Applikation kann man das lösen in dem man die Parameter signiert und GET Anfragen ohne Signatur verwirft. Aber bei einer API ist das natürlich deutlich aufwendiger. Vermutlich wäre da eine Whitelist mit erlaubten Parametern in Kombination mit einer Authentifizierung und Rate Limiter eine gute Option.
Ich finde den neuen Stil der Video top. Weiter so.
Danke für das Feedback. Ich werde weiter am Stil arbeiten.
Genial !!! Deine Frau freut sich bestimmt wenn sie das Video sieht. Stichwort Ehering :)))
Macht man das clientseitige Invalidieren in der Praxis wirklich? Ist es kein Sicherheitsproblem wenn der Client entscheidet wann der Applikation Server angesprochen wird? Stichwort: DoS
no-cache wird wahrscheinlich an erster Stelle verwendet um garantiert eine frische Antwort, die nicht aus dem Cache kommt zu erhalten. Bei der Invalidierung für andere z.B. nach einem PUT ist man darauf angewiesen, dass der Client wirklich die Invalidierung durchführt. Was nicht einfach ist, wenn man selbst nicht den Client implementiert. Caches bieten natürlich auch eine Angriffsoberfläche. Man kann z.B. versuchen mit Cache Poisening eine Attacke zu fahren. Dabei wird z.B. nach einem HTTP-Header gesucht, der nicht in den Cache-Key eingeht, der aber einen Fehler verursacht, der dann gecached wird. Um den Cache für eine DOS zu umgehen, genügt es, den Cache-Key z.B. mit einem zusätzlichen Query-Parameter zu verändern. Es kann je nach Anforderung auch Sinn machen, den no-cache nicht zuzulassen.
@@thomas-bayer danke für die ausführliche Antwort. 😁. Bzgl. der GET Parameter sollte der Cache imho nur geprüfte Werte in den Cache ablegen. Ansonsten könnte man den Cache fluten bis er in die Knie geht. Bei Web Applikation kann man das lösen in dem man die Parameter signiert und GET Anfragen ohne Signatur verwirft. Aber bei einer API ist das natürlich deutlich aufwendiger. Vermutlich wäre da eine Whitelist mit erlaubten Parametern in Kombination mit einer Authentifizierung und Rate Limiter eine gute Option.