Protezione CSRF con ID sessione

Sembra che la soluzione semplice (ovvero la protezione CSRF ma con tutte le risorse Web memorizzabili nella cache) sia quella di aggiungere un cookie separato contenente il token anti-CSRF ma accessibile alla pagina javascript.

In altre parole, quando il client esegue l'accesso, in realtà imposterò i due cookie (un solo HttpOsid e un non-HttpOnly token anti-CSRF, accessibile dagli script di pagina). Pertanto, il server memorizzerà (insieme a un client sessionid) il loro valore di token anti-CSRF e convaliderà che è lo stesso valore originariamente impostato con il secondo cookie. Se la convalida fallisce, hai un potenziale CSRF.

Questo approccio è citato anche in altri posti sul web ...

Citato da pagina di prevenzione CSRF di OWASP :

Double Submit Cookies

Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. This is typically referred to as the session ID. The site should require every form submission to include this pseudorandom value as a hidden form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the session ID value.

While this approach is effective in mitigating the risk of cross-site request forgery, including authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking. Architects and developers must ensure that no network appliances or custom application code or modules explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare occurrence across network systems and web applications as doing so will expose significant sensitive data aside from session identifiers including passwords, credit card numbers, and or social security numbers. Inclusion of the session identifier within HTML can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern as described in this article.

Non esiste una vera ragione per non utilizzare il meccanismo di prevenzione CSRF incorporato, ma ora quasi tutti i framework seri hanno questo.

No perché non devi mai consentire agli script di poter accedere ai tuoi cookie. Fai riferimento a HTTPOnly sul sito web OWASP.

Per evitare che le persone possano rubare id di sessione, se XSS è presente, devi sempre impostare questo flag di cookie. Il tuo meccanismo non funzionerebbe più in quanto non sarebbe in grado di accedere al cookie.

potresti , ma a me sembra un po 'ingombrante. Qualsiasi meccanismo di prevenzione CSRF funziona in questo modo:

• Fai in modo che il server accetti solo richieste che soddisfano alcune condizioni
• Assicurati che le condizioni siano qualcosa che non può essere falsificato
• Scrivi il tuo codice HTML in modo che le richieste che genera seguano le condizioni impostate dal server.

Il metodo collaudato consiste nell'utilizzare <input type=hidden> nei campi HTML che contiene un token anti-CSRF. Anche il tuo metodo funziona ¹ , ma l'uso di JS per intercettare e iniettare le richieste POST sembra icky e non necessario quando l'intera logica lato client può essere contenuta nell'HTML.

^{1 Come notato da TildalWave, mettere i dati sensibili in non- httponly cookie e rendere accessibile al lato client JS potrebbe essere un problema se si hanno vulnerabilità XSS. Segui il metodo collaudato allora}

Come menzionato da un numero di persone - il doppio invio è una protezione CSRF ok, a condizione che tu usi un nonce separato. L'utilizzo dell'ID di sessione è molto sbagliato in questo contesto, a cominciare dal fatto che sessionid deve essere HTTPOnly per la protezione XSS.

Un argomento su "cosa succede se c'è XSS su questa pagina / sito web" non è valido - quando hai XSS, CSRF è l'ultima delle tue preoccupazioni. Il browser diventa completamente controllabile da remoto tramite uno script inserito e CSRF non è necessario per forzare il browser a compiere azioni per conto dell'utente.