Dlaczego w odpowiedzi HTTP należy używać zarówno opcji no-cache, jak i no-store?

Powiedziano mi, żebym zapobiegał wyciekowi informacji o użytkowniku, tylko odpowiedź „no-cache” nie wystarczy. „brak sklepu” jest również konieczne.

Cache-Control: no-cache, no-store

Po przeczytaniu tej specyfikacji http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , nadal nie jestem pewien, dlaczego.

Obecnie rozumiem, że jest to tylko dla pośredniego serwera pamięci podręcznej. Nawet jeśli w odpowiedzi pojawi się komunikat „no-cache”, pośredni serwer pamięci podręcznej może nadal zapisywać zawartość w pamięci nieulotnej. Pośredni serwer pamięci podręcznej zdecyduje, czy użyć zapisanej treści dla następnego żądania. Jeśli jednak odpowiedź zawiera informację „no-store”, pośredni serwer pamięci podręcznej nie powinien przechowywać treści. Więc to jest bezpieczniejsze.

Czy jest jakiś inny powód, dla którego potrzebujemy zarówno opcji „no-cache”, jak i „no-store”?

Muszę wyjaśnić, że no-cachenie oznacza to, że nie buforuj . W rzeczywistości oznacza to „ponowne sprawdzenie poprawności z serwerem” przed użyciem jakiejkolwiek odpowiedzi z pamięci podręcznej, którą możesz mieć, na każde żądanie.

must-revalidatez drugiej strony wymaga ponownej walidacji tylko wtedy, gdy zasób zostanie uznany za nieaktualny.

Jeśli serwer twierdzi, że zasób jest nadal ważny, pamięć podręczna może odpowiedzieć swoją reprezentacją, zmniejszając w ten sposób potrzebę ponownego wysłania przez serwer całego zasobu.

no-storejest w rzeczywistości pełną dyrektywą „ nie zapisuj w pamięci podręcznej” i ma na celu zapobieganie przechowywaniu reprezentacji w jakiejkolwiek formie pamięci podręcznej.

Powiem cokolwiek, ale zwróć uwagę na to w specyfikacji HTTP RFC 2616:

Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy

Jest to jednak pomijane w nowszej specyfikacji protokołu HTTP RFC 7234 w celu potencjalnej próby no-storewzmocnienia, zobacz:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

W pewnych okolicznościach IE6 będzie nadal buforować pliki, nawet jeśli Cache-Control: no-cacheznajduje się w nagłówkach odpowiedzi.

Stany W3Cno-cache :

Jeśli dyrektywa no-cache nie określa nazwy pola, pamięć podręczna NIE MOŻE używać odpowiedzi w celu spełnienia kolejnego żądania bez pomyślnej ponownej walidacji z serwerem pochodzenia.

W mojej aplikacji, jeśli odwiedziłeś stronę z no-cachenagłówkiem, wylogowałeś się, a następnie wcisnąłeś z powrotem w przeglądarce, IE6 nadal pobierałby stronę z pamięci podręcznej (bez nowego / sprawdzającego żądania do serwera). Dodanie w no-storenagłówku zatrzymało to. Ale jeśli uwierzysz W3C na słowo, tak naprawdę nie ma sposobu, aby kontrolować to zachowanie:

Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy.

Ogólne różnice między historią przeglądarki a zwykłym buforowaniem HTTP są opisane w odpowiedniej podsekcji specyfikacji .

Ze specyfikacji HTTP 1.1 :

brak sklepu :

Cel braku sklepuDyrektywa ma na celu zapobieżenie niezamierzonemu ujawnieniu lub zatrzymaniu wrażliwych informacji (na przykład na taśmach zapasowych). Dyrektywa no-store dotyczy całej wiadomości i MOŻE zostać wysłana w odpowiedzi lub w żądaniu. W przypadku wysłania żądania pamięć podręczna NIE MOŻE przechowywać żadnej części ani tego żądania, ani odpowiedzi na nie. W przypadku wysłania w odpowiedzi pamięć podręczna NIE MOŻE przechowywać żadnej części ani tej odpowiedzi, ani żądania, które ją wywołało. Ta dyrektywa dotyczy zarówno niewspółdzielonych, jak i współużytkowanych pamięci podręcznych. „NIE WOLNO przechowywać” w tym kontekście oznacza, że ​​pamięć podręczna NIE MOŻE celowo przechowywać informacji w pamięci nieulotnej i MUSI dołożyć wszelkich starań, aby usunąć informacje z pamięci ulotnej tak szybko, jak to możliwe po ich przesłaniu. Nawet jeśli ta dyrektywa jest powiązana z odpowiedzią, użytkownicy mogą jawnie przechowywać taką odpowiedź poza systemem pamięci podręcznej (np. za pomocą okna dialogowego „Zapisz jako”). Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Bufory historii MOGĄ przechowywać takie odpowiedzi jako część ich normalnej pracy. Celem tej dyrektywy jest spełnienie określonych wymagań określonych użytkowników i autorów usług, którzy są zaniepokojeni przypadkowym ujawnieniem informacji poprzez nieoczekiwany dostęp do struktur danych pamięci podręcznej. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie. Chociaż stosowanie tej dyrektywy może w niektórych przypadkach poprawić prywatność, ostrzegamy, że NIE jest to w żaden sposób niezawodny ani wystarczający mechanizm zapewniający prywatność. W szczególności złośliwe lub zainfekowane pamięci podręczne mogą nie rozpoznawać tej dyrektywy lub jej przestrzegać, a sieci komunikacyjne mogą być narażone na podsłuchiwanie.

Jeśli chcesz zapobiec wszelkiemu buforowaniu (np. Wymusić przeładowanie podczas korzystania z przycisku Wstecz), potrzebujesz:

• no-cache dla IE

• no-store dla przeglądarki Firefox

Moje informacje na ten temat są tutaj:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

no-storenie powinno być konieczne w normalnych sytuacjach i może zaszkodzić zarówno szybkości, jak i użyteczności. Jest przeznaczony do użytku w przypadku, gdy odpowiedź HTTP zawiera informacje tak wrażliwe, że w ogóle nie powinna być zapisywana w pamięci podręcznej dysku, niezależnie od negatywnych skutków, jakie stwarza to dla użytkownika.

Jak to działa:

• Zwykle, nawet jeśli agent użytkownika, taki jak przeglądarka, ustali, że odpowiedź nie powinna być buforowana, może nadal przechowywać ją w pamięci podręcznej dysku z powodów wewnętrznych dla agenta użytkownika. Ta wersja może być wykorzystywana do takich funkcji, jak „wyświetl źródło”, „wstecz”, „informacje o stronie” itd., Gdzie użytkownik nie musi koniecznie ponownie zażądać strony, ale przeglądarka nie uważa tego za nowy widok strony i miałoby sens serwowanie tej samej wersji, którą aktualnie przegląda użytkownik.

• Użycie no-storeuniemożliwi przechowywanie tej odpowiedzi, ale może to wpłynąć na możliwość podania przez przeglądarkę „źródła wyświetlania”, „wstecz”, „informacji o stronie” itd. Bez wysyłania nowego, oddzielnego żądania do serwera, co jest niepożądane. Innymi słowy, użytkownik może spróbować wyświetlić źródło, a jeśli przeglądarka nie zachowała go w pamięci, albo zostanie poinformowany, że nie jest to możliwe, albo spowoduje to nowe żądanie do serwera. Dlatego no-storepowinno być używane tylko wtedy, gdy utrudniane przez użytkownika korzystanie z tych funkcji nie działa prawidłowo lub szybko jest równoważone przez znaczenie zapewnienia, że ​​zawartość nie jest przechowywana w pamięci podręcznej.

Obecnie rozumiem, że jest to tylko dla pośredniego serwera pamięci podręcznej. Nawet jeśli w odpowiedzi pojawi się komunikat „no-cache”, pośredni serwer pamięci podręcznej może nadal zapisywać zawartość w pamięci nieulotnej.

To jest niepoprawne. Serwery pośredniczące z pamięcią podręczną zgodne z protokołem HTTP 1.1 będą przestrzegać instrukcji no-cachei must-revalidate, zapewniając, że zawartość nie jest buforowana. Skorzystanie z tych instrukcji zapewni, że odpowiedź nie będzie buforowana przez żadną pośrednią pamięć podręczną, a wszystkie kolejne żądania będą wysyłane z powrotem do serwera pochodzenia.

Jeśli pośredni serwer pamięci podręcznej nie obsługuje protokołu HTTP 1.1, będziesz musiał użyć Pragma: no-cachei mieć nadzieję na najlepsze. Zauważ, że jeśli nie obsługuje HTTP 1.1, no-storeto i tak nie ma znaczenia.

Jeśli system buforowania poprawnie implementuje brak przechowywania, nie potrzebujesz żadnej pamięci podręcznej. Ale nie wszyscy. Ponadto niektóre przeglądarki implementują brak pamięci podręcznej, tak jakby to był brak przechowywania. Tak więc, chociaż nie jest to ściśle wymagane, prawdopodobnie najbezpieczniej jest uwzględnić oba.

Zwróć uwagę, że Internet Explorer od wersji 5 do 8 zgłosi błąd podczas próby pobrania pliku obsługiwanego przez https i serwer wysyłający Cache-Control: no-cachelub Pragma: no-cachenagłówki.

Zobacz http://support.microsoft.com/kb/812935/en-us

Użycie Cache-Control: no-storei Pragma: privatewydaje się być najbliższą rzeczą, która nadal działa.

W przypadku Chrome, no-cache jest używany do ponownego załadowania strony przy ponownej wizycie, ale nadal buforuje ją, jeśli wrócisz do historii (przycisk Wstecz). Aby ponownie załadować stronę w celu przywrócenia historii, użyj opcji no-store. IE wymaga ponownej walidacji, aby działać w każdej sytuacji.

Więc tylko po to, aby uniknąć wszystkich błędów i błędnych interpretacji, których zawsze używam

Cache-Control: no-store, no-cache, must-revalidate

jeśli chcę się upewnić, że się ponownie załaduje.

Pierwotnie korzystaliśmy z no-cache wiele lat temu i napotkaliśmy pewne problemy z nieaktualnymi treściami w niektórych przeglądarkach ... Nie pamiętam niestety szczegółów.

Od tego czasu zdecydowaliśmy się TYLKO na korzystanie z braku sklepu. Od tamtej pory nigdy nie oglądałem się za siebie ani nie miałem ani jednego problemu z nieaktualnymi treściami w jakiejkolwiek przeglądarce lub u pośredników.

Ta przestrzeń jest z pewnością zdominowana przez rzeczywistość implementacji w porównaniu z tym, co zostało napisane w różnych dokumentach RFC. W szczególności wiele serwerów proxy ma tendencję do myślenia, że ​​lepiej „poprawiają wydajność”, zastępując politykę, której powinni przestrzegać, własną.

Żeby było jeszcze gorzej, w niektórych sytuacjach nie można użyć no-cache, ale no-store może:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

OWASP omawia to:

Jaka jest różnica między dyrektywami Cache-Control: no-cache i no-store?

Dyrektywa no-cache w odpowiedzi wskazuje, że odpowiedź nie może służyć do obsługi kolejnego żądania, tj. Pamięć podręczna nie może wyświetlać odpowiedzi, która ma tę dyrektywę ustawioną w nagłówku, ale musi pozwolić serwerowi obsłużyć żądanie. Dyrektywa no-cache może zawierać niektóre nazwy pól; w takim przypadku odpowiedź może zostać wyświetlona z pamięci podręcznej, z wyjątkiem określonych nazw pól, które mają być obsługiwane z serwera. Dyrektywa no-store dotyczy całej wiadomości i wskazuje, że pamięć podręczna nie może przechowywać żadnej części odpowiedzi ani żadnego żądania, które o to poprosiło.

Czy jestem całkowicie bezpieczny dzięki tym dyrektywom?

Nie. Ale generalnie używaj zarówno Cache-Control: no-cache, no-store i Pragma: no-cache, oprócz Expires: 0 (lub wystarczająco datowanej daty GMT, takiej jak epoka UNIX). Typy zawartości inne niż HTML, takie jak PDF, dokumenty Word, arkusze kalkulacyjne programu Excel itp., Często są buforowane, nawet jeśli ustawione są powyższe dyrektywy kontroli pamięci podręcznej (chociaż zależy to od wersji i dodatkowego użycia funkcji must-revalidate, pre-check = 0, post-check = 0, max-age = 0 i s-maxage = 0 w praktyce czasami mogą skutkować przynajmniej usunięciem pliku po zamknięciu przeglądarki w niektórych przypadkach z powodu dziwactw przeglądarki i implementacji HTTP). Ponadto funkcja „Autouzupełnianie” umożliwia przeglądarce buforowanie wszystkiego, co użytkownik wpisze w polu wejściowym formularza. Aby to sprawdzić, tag formularza lub poszczególne tagi wejściowe powinny zawierać atrybut „Autocomplete =„ Off ””. Jednak,

Źródło tutaj .