XSRF Token w Laravel'u

Question

Proszę o rozwianie pewnych wątpliwości związanych z tokenem XSRF w Laravelu - chociaż to zagadnienie zapewne dotyczy nie tylko tego framework'a. Rozumiem o co chodzi gdy do formularza dołączamy ukryty token csrf. Jednak zauważyłem, że cookie dołączane do każdego rządania do aplikacji laravelowej zawiera coś takiego:

"cookie": "XDEBUG_SESSION=XDEBUG_ECLIPSE; XSRF-TOKEN=eyJpdiI6Ijg0WHNCRG53K2VxamdsU04vUDR6NFE9PSIsInZhbHVlIjoiZG

No i poczytałem trochę na ten temat, goście na Stack Overflow opisują to tak : 

          

x-xsrf-token:

• It is added to the request header for ajax requests.
• Popular libraries like angular and axios, automatically get value of this header from xsrf-token cookie and put it in every request header.
• To use it, we should create a cookie named xsrf-token in backend, then our front end framework that uses angular or axios will use it automatically.

 https://stackoverflow.com/questions/42408177/what-is-the-difference-between-x-xsrf-token-and-x-csrf-token

An alternative approach (called the "Cookie-to-header token" pattern) is to set a Cookie once per session and the have JavaScript read that cookie and set a custom HTTP header (often called X-CSRF-TOKEN or X-XSRF-TOKEN or just XSRF-TOKEN) with that value. Any requests will send both the header (set by Javascript) and the cookie (set by the browser as a standard HTTP header) and then the server can check that value in the X-CSRF-TOKEN header matches the value in the cookie header. The idea being that only JavaScript run on the same domain would have access to the cookie, so JavaScript from another domain couldn't set this header to the right value (assuming the page is not vulnerable to XSS that would give access to this cookie). Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.

 https://stackoverflow.com/questions/34782493/difference-between-csrf-and-x-csrf-token/34783845

Zwróćcie uwagę na przyciemniony tekst. Dochodzimy do sedna. Po co dodawać token xsrf do każdego rządania AJAX skoro istnieje coś takiego jak Same Origin Policy i przegądarka i tak blokuje rządania AJAX pochądzące z osobnych domen(przynajmniej domyślnie) ? Do czego to jest potrzebne?

Poza tym jak to w końcu jest? Skoro to ma służyć do AJAX'a to dlaczego gość pisze :

Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.

?? 

Answer 1

Pomęczyłem trochę temat i teraz w sumie zastanawia mnie jedna kluczowa kwestia. Dlaczego SOP generalnie zezwala na zapisywanie a nie pozwala na odczytywanie?

• Cross-origin writes are typically allowed. Examples are links, redirects, and form submissions. Some HTTP requests require preflight.
• Cross-origin embedding is typically allowed. (Examples are listed below.)
• Cross-origin reads are typically disallowed, but read access is often leaked by embedding. For example, you can read the dimensions of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access

Odnoszę wrażenie, że powinno być na odwrót.

Answer 2

Same Origin Policy (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) ma zagwarantować bezpieczeństwo podczas korzystania z różnych zasobów/skryptów na stronie/domenie,

aby to obejść wykorzystuje się Cross-Origin Resource Sharing (CORS) (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)

np w różnych CDN/API aby poinformować przeglądarkę, że konkretna domena pozwala na komunikacje AJAX (np ta strona korzysta z https://connect.facebook.net/pl_PL/sdk.js jeśli zobaczysz w inspektorze są tam nagłówki access-control aby biblioteki mogły się swobodnie komunikować Ajaxem z serwerem )

natomiast ukryte pola w formularzu ,nagłówki w head i cookie -- tokeny csrf (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html),

mają konkretnie pomóc w zabezpieczeniu (przed atakami) , aby nie doszło do sytuacji kiedy jakiś skrypt wykona za użytkownika operacje ze jego plecami , dlatego generuje się tokeny aby uwierzytelnić operacje POST (jednorazowe służące autoryzacji jednego formularza)

ale oczywiście mogę się mylić

Comments

Z tokenami w formularzu sprawa jest dla mnie zrozumiała. Mnie zastanawia dlaczego konieczne jest dołączanie nagłówka do każdego rządania AJAX'owego. Działa to w ten sposób, że dołączane jest cookie jak rozumiem z automatu i tam jest zawartość tokena XSRF i ta wartość z cookie jest porównywana z tą dołączaną w nagłówku AJAX'a.

---

podczas zapytania ajax istnieje możliwość manipulacji nagłówkami , ustawiania własnych, framework frontendowy pobierając to cooki może automatycznie ustawić te nagłówki , jedyny sens tych nagłówków jeśli serwer je czyta bo z automatu nic samo się nie dzieje, w standardowym POSTcie ze zwykłego formularza nie lecą dodatkowe nagłówki wtedy korzysta się z ukrytego pola

https://laravel.com/docs/7.x/csrf -  tutaj wytłumaczyli idee