Double Submit Cookies vulnerabilità

In base a carta pubblicato su Blackhat 2013, non è sufficiente implementare i cookie Double-Submit nel proprio sottodominio (ad esempio secure.host.com ). Devi davvero controllare tutti sottodomini:

2.1.1 Naïve Double Submit

Double submit cookie CSRF mitigations are common and implementations can vary a lot. The solution is tempting because it’s scalable and easy to implement. One of the most common variations is the naive:

if (cookievalue != postvalue) 
 throw CSRFCheckError 

With naïve double submit, if an attacker can write a cookie they can obviously defeat the protection. And again, writing cookies is significantly easier then reading them.

The fact that cookies can be written is difficult for many people to understand. After all, doesn’t the same origin policy specify that one domain cannot access cookies from another domain? However, there are two common scenarios where writing cookies across domains is possible:

1) While it’s true that hellokitty.marketing.example.com cannot read cookies or access the DOM from secure.example.com because of the same origin policy, hellokitty.marketing.example.com can write cookies to the parent domain (example.com), and these cookies are then be consumed by secure.example.com (secure.example.com has no good way to distinguish which site set the cookie).

Additionally, there are methods of forcing secure.example.com to always accept your cookie first. What this means is that XSS in hellokitty.marketing.example.com is able to overwrite cookies in secure.example.com.

In secondo luogo, questo approccio è vulnerabile agli attacchi man-in-the-middle:

2) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies).

Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plaintext HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as http://hellokitty.marketing.example.com doesn’t force https, then an attacker can overwrite cookies on any example.com subdomain.

In breve:

1. Devi controllare tutti i sottodomini.
2. Devi impostare il flag Secure per garantire che i cookie vengano inviati solo tramite HTTPS.
3. Se ti interessano gli attacchi MiTM , devi trasferire l'intero sito web a HTTPS, impostare l'intestazione HSTS e assicurati che include tutti i sottodomini . Al momento, solo il 58% dei browser supporta HSTS (Internet Explorer è un'eccezione degna di nota). Questo è previsto che cambi nel corso del prossimo anno.

Vedi link per una discussione sulla lunghezza del token e sul tipo di RNG necessari per generare valori.

Sebbene tutti gli attacchi XSS superino le protezioni CSRF, questi richiedono uno sforzo diverso da parte dell'attaccante. Una semplice protezione come un token è facile per un attaccante ottenere tramite un attacco XSS, in quanto può semplicemente leggere il valore del token dal DOM e utilizzarlo in qualsiasi invio di moduli successivo. Un modulo sensibile che richiede la password o la riautenticazione OTP è più difficile da attaccare, in quanto è necessario progettare il proprio attacco per acquisire le credenziali dell'utente o l'OTP in qualche modo. Tuttavia, con il pieno controllo del DOM, potevano imitare la pagina di accesso per indurre l'utente a pensare di essere stato disconnesso e aspettare che l'utente inserisse le proprie credenziali ... in questo caso, probabilmente potevano accedere direttamente come vittima invece di eseguire solo un attacco CSRF. Questo attacco causa anche un'interruzione visibile del sito, il che significa che un utente esperto può sospettare che qualcosa non va e rifiutarsi di accedere al modulo dell'attaccante.

Con i sottodomini ci sono due rischi con i cookie double-submit. Un utente malintenzionato su un sottodominio che legge il valore del cookie. per esempio. se un cookie solo host è impostato su example.com , un utente malintenzionato che controlla foo.example.com sarà in grado di leggere il valore del cookie. L'impostazione dei cookie di solo host può contrastare questo attacco.

L'altro rischio in un utente malintenzionato che scrive cookie. La Stessa politica di origine è più lenta per i cookie di quanto non lo sia per il resto del DOM. Ciò significa che un utente malintenzionato che controlla foo.example.com può impostare un cookie che verrà letto quando la vittima visita example.com o bar.example.com . Semplicemente impostano un non host solo al livello example.com . Anche se il sito è sotto attacco, diciamo che bar.example.com imposta i cookie solo host su HTTPS e imposta la bandiera protetta per evitare che trapelino su un semplice HTTP, un utente malintenzionato che imposta un semplice cookie HTTP sarà comunque in grado di impostare il cookie da leggere per bar.example.com . Il motivo è che il server non può stabilire il dominio effettivo che lo ha impostato, né può interrogare il flag di sicurezza stesso.

I cookie di doppia invio sono anche vulnerabili a un attaccante di Man-In-The-Middle che può intercettare e cambiare qualsiasi cosa a parte Traffico HTTPS . Anche se il sito di destinazione, example.com non ascolta su HTTP semplice (cioè la porta 443 è aperta solo per TLS), l'utente malintenzionato potrebbe reindirizzare qualsiasi richiesta HTTP semplice con HTTP 3xx (ad es. A http://example.com ) e quindi intercettare quella richiesta, inviare una risposta con il set di cookie CSRF avvelenato per example.com . Il server prenderà quel valore, come ancora non ha modo di determinare che non è un cookie con il flag di sicurezza. Questo è di nuovo dovuto alla stessa politica di origine dei cookie.

La soluzione a tutto questo consiste nell'implementare Sicurezza del trasporto rigoroso HTTP e per controllare tutti i sottodomini. Nei browser supportati, ciò impedirà qualsiasi semplice connessione HTTP effettuata dal browser durante la vita del record HSTS (forse anni) e proteggerà i cookie dall'attacco di un utente malintenzionato. Le voci HSTS possono anche essere inviate ai fornitori di browser per l'inclusione nella compilazione, il che significa che gli utenti non devono visitare il sito almeno una volta per impostare il record HSTS. Vedi Precarico HSTS .