Wiem, że plik cookie z flagą secure nie zostanie wysłany przez nieszyfrowane połączenie. Zastanawiam się, jak to działa dogłębnie.Jak działa flaga "Bezpieczne" pliku cookie?
Kto jest odpowiedzialny za określenie, czy plik cookie zostanie wysłany, czy nie?
Zestawy klienckie to tylko dla połączeń szyfrowanych, a to jest zdefiniowane w RFC 6265:
Secure atrybut ogranicza zakres cookie do „zabezpieczenia” kanałów (gdzie „bezpieczne” jest zdefiniowany przez agenta użytkownika). Gdy plik cookie ma atrybut Secure, agent użytkownika umieści plik cookie w żądaniu HTTP tylko wtedy, gdy żądanie zostanie przesłane bezpiecznym kanałem (zazwyczaj HTTP ponad Transport Layer Security (TLS) [RFC2818]).
Chociaż wydaje się przydatny do ochrony plików cookie przed aktywnymi atakującymi sieciami, atrybut Bezpieczny chroni tylko poufność plików cookie. Aktywny atakujący sieci może nadpisać bezpieczne pliki cookie z niezabezpieczonego kanału, zakłócając ich integralność (szczegółowe informacje znajdują się w części 8.6).
Jeszcze słowo na temat:
Pominięcie secure ponieważ witryna example.com jest w pełni https nie wystarczy.
Jeśli Twój użytkownik wyraźnie dotrze do http://example.com, zostanie przekierowany na numer https://example.com, ale jest już za późno, pierwsza prośba zawierała plik cookie.
Wiem, że jest stary, ale preload HSTS pomaga w tej sytuacji, zapobiegając częstemu występowaniu tego problemu. Nadal nie jest to naprawa w 100%, ale jest to kolejna rzecz do rozważenia, jeśli naprawdę chcesz uniknąć bezpiecznego pliku cookie. –
@ Mr.MonoChrome Dlaczego chcesz uniknąć bezpiecznego pliku cookie? – MEMark
@ Mr.MonoChrome chociaż niektóre starsze lub niższe przeglądarki spec, jak sądzę, nawet nie obsługują HSTS – Anthony
w przypadku, gdy strona po stronie klienta nie ma jeszcze pliku cookie i powinny być wysyłane z serwera (np. Logowanie), czy serwer będzie stroną, która zdecyduje się włączyć plik cookie w odpowiedzi? – ted
Serwer początkowo ustawia pliki cookie za pomocą "nagłówków Set-Cookie". – Ivan