Jakie znaki są dozwolone w plikach cookie?

W ASP.Net możesz użyć System.Web.HttpUtility, Aby bezpiecznie zakodować wartość pliku cookie przed zapisaniem do pliku cookie i przekonwertować ją z powrotem do pierwotnej formy po odczytaniu.

// Encode
HttpUtility.UrlEncode(cookieData);

// Decode
HttpUtility.UrlDecode(encodedCookieData);

Spowoduje to zatrzymanie znaków Ampersand i equals dzielących wartość na kilka par nazwa / wartość, które są zapisywane w pliku cookie.

Myślę, że jest to ogólnie specyficzne dla przeglądarki. Aby zachować bezpieczeństwo, base64 koduje obiekt JSON i przechowuje w nim wszystko. W ten sposób musisz go tylko odszyfrować i przeanalizować JSON. Wszystkie znaki używane w base64 powinny grać dobrze z większości, jeśli nie wszystkich przeglądarek.

Oto, w jak najmniejszej liczbie słów . Skup się na postaciach, które nie potrzebują ucieczki:

Dla plików cookie:

abdefghijklmnqrstuvxyzABDEFGHIJKLMNQRSTUVXYZ0123456789!#$%&'()*+-./:<>?@[]^_`{|}~

Dla adresów URL

abdefghijklmnqrstuvxyzABDEFGHIJKLMNQRSTUVXYZ0123456789.-_~!$&'()*+,;=:@

Dla plików cookie i adresów URL (7)]}

abdefghijklmnqrstuvxyzABDEFGHIJKLMNQRSTUVXYZ0123456789!$&'()*+-.:@_~

Należy pamiętać, że w przypadku plików cookie,= został usunięty, ponieważ jest zwykle używane do ustawiania wartości pliku cookie.

Dla adresów URL ten = został zachowany. Skrzyżowanie jest oczywiście bez.

var chars = "abdefghijklmnqrstuvxyz"; chars += chars.toUpperCase() + "0123456789" + "!$&'()*+-.:@_~";

Okazuje się, że wciąż dochodzi do ucieczki i nieoczekiwanego zdarzenia, szczególnie w środowisku Java cookie, gdzie plik cookie jest owinięty podwójnymi cudzysłowami, jeśli napotka ostatnie znaki.

Nowszy rfc6265 opublikowany w kwietniu 2011:

cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" SP cookie-pair )
cookie-pair  = cookie-name "=" cookie-value
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )

cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                   ; US-ASCII characters excluding CTLs,
                   ; whitespace DQUOTE, comma, semicolon,
                   ; and backslash

Jeśli spojrzysz na @bobince odpowiedź widzisz, że nowsze ograniczenia są bardziej rygorystyczne.

Nie można umieścić ";" w polu Wartość pliku cookie, nazwa, która zostanie ustawiona jest ciągiem znaków aż do";"w większości przeglądarek...

Istnieją 2 wersje specyfikacji plików cookie
1. Wersja 0 cookies aka Netscape cookies,
2. Wersja 1 aka RFC 2965 cookies
W wersji 0 częścią nazwy i wartości plików cookie są sekwencje znaków, z wyłączeniem średnika, przecinka, znaku równości i spacji, jeśli nie są używane z podwójnymi cudzysłowami
Wersja 1 jest o wiele bardziej skomplikowana możesz ją sprawdzić tutaj
W tej wersji specyfikacja dla nazwy wartość części jest prawie taka sama, z tym, że nazwa nie może zaczynać się od $ sign

Jest jeszcze jeden interesujący problem z IE i Edge. Pliki cookie o nazwach dłuższych niż 1 Okres wydają się być po cichu usuwane. Więc To działa:

Cookie_name_a=valuea

While this will get dropped

Cookie. name. a=valuea

To proste:

A może być dowolnymi znakami US-ASCII z wyjątkiem control znaki (CTL), spacje lub tabulatory. Nie może również zawierać znak separatora jak poniżej: ( ) @ , ; : \ " / [ ] ? = { }.

Wartość może być opcjonalnie ustawiona w podwójnych cudzysłowach i dowolnych Znaki US-ASCII z wyłączeniem CTL, whitespace, double quotes, comma, średnik i Ukośnik są dozwolone. Kodowanie: wiele implementacji wykonaj kodowanie URL na wartościach plików cookie, jednak nie jest wymagane na Specyfikacja RFC. Pomaga spełnić wymagania dotyczące które znaki są jednak dozwolone.

Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives

Jeszcze jedna uwaga. Niedawno zaimplementowałem schemat, w którym niektóre poufne dane wysłane do skryptu PHP musiały zostać przekonwertowane i zwrócone jako zaszyfrowane pliki cookie, które wykorzystywały wszystkie wartości base64, które uważałem za gwarantowane "bezpieczne". Więc posłusznie zaszyfrowałem elementy danych za pomocą RC4, przepuściłem wyjście przez base64_encode i szczęśliwie zwróciłem plik cookie na stronę. Testowanie wydawało się przebiegać dobrze, dopóki zakodowany ciąg znaków base64 nie zawierał symbolu"+". Ciąg został zapisany na stronie bez kłopoty. Korzystając z diagnostyki przeglądarki mogłem również zweryfikować, czy pliki cookie zostały zapisane w niezmienionej formie. Następnie, gdy Następna strona wywołała moje PHP i uzyskała plik cookie za pośrednictwem tablicy $_COOKIE, jąkałem się, aby znaleźć ciąg znaków brakowało teraz znaku"+". Każde wystąpienie tego znaku zostało zastąpione spacją ASCII.

Biorąc pod uwagę, ile podobnych nierozwiązanych skarg przeczytałem opisując ten scenariusz od tego czasu, często umieszczając liczne odniesienia do używania base64 do "bezpiecznego" sklepu dowolne dane w plikach cookie, pomyślałem, że wskażę problem i zaproponuję moje rozwiązanie.

Po wykonaniu dowolnego szyfrowania na kawałku danych, a następnie użyciu base64_encode, aby uczynić go "bezpiecznym dla plików cookie", Uruchom ciąg wyjściowy przez to...

// from browser to PHP. substitute troublesome chars with 
// other cookie safe chars, or vis-versa.  

function fix64($inp) {
    $out =$inp;
    for($i = 0; $i < strlen($inp); $i++) {
        $c = $inp[$i];
        switch ($c) {
            case '+':  $c = '*'; break; // definitly won't transfer!
            case '*':  $c = '+'; break;

            case '=':  $c = ':'; break; // = symbol seems like a bad idea
            case ':':  $c = '='; break;

            default: continue;
            }
        $out[$i] = $c;
        }
    return $out;
    }

Tutaj po prostu zastępuję " + "(i zdecydowałem"=") innymi" cookie safe " znakami, przed zwróceniem zakodowanej wartości na stronę, do wykorzystania jako plik cookie. Należy pamiętać, że długość przetwarzany ciąg znaków nie zmienia się. Gdy ta sama (lub inna strona na stronie) uruchomi mój skrypt PHP ponownie, będę mógł odzyskać ten plik cookie bez brakujących znaków. Muszę tylko pamiętać, aby przekazać ciasteczko z powrotem przez to samo wywołanie fix64 (), które utworzyłem, i stamtąd mogę je odszyfrować za pomocą zwykłej metody base64_decode (), a następnie dowolnych innych deszyfrowań w twoim schemacie.

Może być jakieś ustawienie, które mógłbym zrobić w PHP, które pozwala na przesyłanie ciągów base64 używanych w plikach cookie powrót do PHP bez korupcji. W międzyczasie to działa. "+"Może być" legalną " wartością pliku cookie, ale jeśli chcesz być w stanie przesłać taki ciąg z powrotem do PHP( w moim przypadku przez tablicę $_cookie), sugeruję ponowne przetworzenie w celu usunięcia obrażających znaków i przywrócenia ich po odzyskaniu. Istnieje wiele innych" cookie safe " znaków do wyboru.

Jeśli używasz zmiennych później, przekonasz się, że rzeczy takie jak path faktycznie przepuszczają znaki z akcentami, ale nie pasują do ścieżki przeglądarki. W tym celu musisz je URIEncode. Czyli tak:

  const encodedPath = encodeURI(myPath);
  document.cookie = `use_pwa=true; domain=${location.host}; path=${encodedPath};`

Więc "dozwolone" znaki, może być więcej niż to, co jest w specyfikacji. Ale powinieneś trzymać się specyfikacji i używać ciągów zakodowanych URI, aby być bezpiecznym.

Lata temu MSIE 5 lub 5.5 (i prawdopodobnie oba) miał jakiś poważny problem z " - " w bloku HTML, jeśli można w to uwierzyć. Alhough nie jest to bezpośrednio powiązane, odkąd przechowujemy hash MD5 (zawierający tylko litery i cyfry) w pliku cookie, aby wyszukać Wszystko inne w bazie danych po stronie serwera.

Skończyło się na użyciu

cookie_value = encodeURIComponent(my_string);

I

my_string = decodeURIComponent(cookie_value);

To wydaje się działać dla wszystkich rodzajów znaków. W przeciwnym razie miałem dziwne problemy, nawet z znakami, które nie były średnikami ani przecinkami.