Staram się zrozumieć cały problem z CSRF i odpowiednie sposoby, aby temu zapobiec. (Zasoby, które przeczytałem, rozumiem i zgadzam się z:OWASP CSRF Prevention CHeat Sheet, Pytania dotyczące CSRF.)

Jak rozumiem, luka w CSRF jest wprowadzana przez założenie, że (z punktu widzenia serwera WWW) prawidłowy plik cookie sesji w przychodzącym żądaniu HTTP odzwierciedla życzenia uwierzytelnionego użytkownika. Jednak wszystkie pliki cookie dla domeny źródłowej są magicznie dołączone do żądania przez przeglądarkę, więc naprawdę wszystko, co serwer może wywnioskować z obecności poprawnego pliku cookie sesji w żądaniu, to że żądanie pochodzi z przeglądarki, która ma uwierzytelnioną sesję; nie może dalej zakładać niczego okod działa w tej przeglądarce lub czy naprawdę odzwierciedla życzenia użytkownika. Sposobem na zapobieżenie temu jest włączenie do żądania dodatkowych informacji uwierzytelniających („token CSRF”), przenoszonych innymi środkami niż automatyczna obsługa plików cookie w przeglądarce. Luźno mówiąc, plik cookie sesji uwierzytelnia użytkownika / przeglądarkę, a token CSRF uwierzytelnia kod działający w przeglądarce.

W skrócie, jeśli używasz cookie sesji do uwierzytelniania użytkowników swojej aplikacji internetowej, powinieneś także dodać token CSRF do każdej odpowiedzi i wymagać odpowiedniego tokena CSRF w każdym (mutującym) żądaniu. Następnie token CSRF dokonuje obiegu z serwera do przeglądarki z powrotem na serwer, udowadniając serwerowi, że strona składająca żądanie jest zatwierdzona przez (wygenerowany przez, nawet) ten serwer.

Na moje pytanie, które dotyczy konkretnej metody transportu używanej dla tego tokena CSRF w tej podróży w obie strony.

Wydaje się to powszechne (np. WAngularJS, Django, Szyny) aby wysłać token CSRF z serwera do klienta jako plik cookie (tj. w nagłówku Set-Cookie), a następnie wyskakuj JavaScript z klienta i usuń go z pliku cookie i dołącz jako osobny nagłówek XSRF-TOKEN, aby wysłać go z powrotem do serwer.

(Alternatywna metoda jest zalecana przez np.Wyrazić, gdzie token CSRF generowany przez serwer jest zawarty w treści odpowiedzi poprzez rozszerzenie szablonu po stronie serwera, dołączony bezpośrednio do kodu / znaczników, które dostarczą go z powrotem do serwera, np. jako ukryty wpis formularza. Ten przykład jest bardziej webowym sposobem na robienie rzeczy, ale uogólniałby dobrze na bardziej obciążonego klienta JS.)

Dlaczego tak często używa się Set-Cookie jako transportu niższego rzędu dla tokena CSRF / dlaczego to jest dobry pomysł? Wyobrażam sobie, że autorzy wszystkich tych ram uważnie rozważyli swoje opcje i nie zrozumieli tego źle. Ale na pierwszy rzut oka używanie plików cookie w celu obejścia tego, co jest zasadniczo ograniczeniem projektowym dotyczącym plików cookie, wydaje się głupie. W rzeczywistości, jeśli użyjesz plików cookie jako transportu w obie strony (Set-Cookie: nagłówek w dół dla serwera, aby poinformować przeglądarkę o tokenie CSRF, a Cookie: nagłówek w górę, aby przeglądarka zwróciła go na serwer), ponownie wprowadzisz usterkę próbuję naprawić.

Zdaję sobie sprawę, że powyższe ramy nie wykorzystują plików cookie do całego obiegu dla tokena CSRF; używają downstreamu Set-Cookie, a potem czegoś innego (np. nagłówka X-CSRF-Token), a to zamyka lukę. Ale nawet używanie Set-Cookie jako transportu niższego szczebla jest potencjalnie mylące i niebezpieczne; przeglądarka będzie teraz dołączać token CSRF do każdego żądania, w tym prawdziwych szkodliwych żądań XSRF; w najlepszym razie sprawia, że ​​żądanie jest większe niż powinno być, aw najgorszym przypadku niektóre dobrze przemyślane, ale błędne fragmenty kodu serwera mogą faktycznie próbować go użyć, co byłoby naprawdę złe. Co więcej, ponieważ rzeczywistym odbiorcą tokena CSRF jest JavaScript po stronie klienta, oznacza to, że ten plik cookie nie może być chroniony tylko przez http. Więc wysyłanie tokena CSRF w dół w nagłówku Set-Cookie wydaje mi się dość nieoptymalne.