A quali attacchi CSRF vengono protetti i cookie "First-Party-Only"?

Question

A quali attacchi CSRF vengono protetti i cookie "First-Party-Only"?

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

4

Il nuovo attributo del cookie "Solo per la prima parte" :

... allows servers to assert that a cookie ought to be sent only in a "first-party" context. This assertion allows user agents to mitigate the risk of cross-site request forgery attacks, and other related paths to cross-origin information leakage.

Chrome ha in programma di implementare la funzione in chrome # 50 .

La specifica definisce First-Party :

... as an HTTP request for a resource whose URL's origin matches the origin of the URL the user sees in the address bar.

Specificamente affermando:

New windows create new first-party contexts.

Full-page navigations create new first-party contexts. Notably, this includes both HTTP and <meta>-driven redirects.

<iframe>'s do not create new first-party contexts; their requests MUST be considered in the context of the origin of the URL the user actually sees in the user agent's address bar.

Quindi la funzione sembra proteggere dal caso in cui CSRF viene utilizzato per inviare una richiesta di POST a un <iframe> sulla pagina dell'attaccante. Ma per quanto riguarda i seguenti vettori CSRF:

Il CSRF è un link o una navigazione javascript a una richiesta GET ? L'utente vedrà una navigazione completa, presumo che non ci sia t aiutato qui.
Il CSRF è un javascript inviato POST , ma il target del modulo causa una navigazione completa verso il sito della vittima? Più probabile essere dodgy dato che POST proviene da qualche altra parte ma è ancora pieno navigazione.

Sono eccitato per questa nuova funzione Cookie ma fino a che punto protegge contro gli attacchi CSRF?

cookies csrf

posta George Powell 03.02.2016 - 15:08

fonte

3 risposte

Leggi altre domande sui tag cookies csrf

Come vengono allegati i virus ai file? Il server OpenSSH utilizza un parametro DH fallback codificato per 2048 bit?

score 2 · Answer 1

Oltre a la tua risposta , Le difese di CRS sono ancora raccomandate e sono utili :

"SameSite" cookies offer a robust defense against CSRF attack when
deployed in strict mode, and when supported by the client. It is,
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and
submissions can certainly be executed in conjunction with other
attack vectors such as cross-site scripting.

Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are
idempotent, etc) to mitigate the risk more fully.

Additionally, client-side techniques such as those described in
[app-isolation] may also prove effective against CSRF, and are
certainly worth exploring in combination with "SameSite" cookies.

Anche se non sono d'accordo con il vettore di attacco XSS, dato che XSS supera sempre una vulnerabilità CSRF - se un hacker può iniettare HTML e script può aggirare la maggior parte delle difese (o tutte le difese con un po 'di "ingegneria sociale" per ingannare l'utente per inserire password o CAPTCHA quando richiesto).

score 2 · Answer 2

Questi scenari sono trattati in Versione 6 delle specifiche .

Definisce le modalità Strict (default) e Lax , dove strict non invierà cookie anche per le navigazioni di primo livello e Lax vorrebbe inviare cookie per le navigazioni di primo livello, ma < em> non per "metodi HTTP non sicuri" compreso POST .

Le risposte per i due scenari sono quindi:

Navigazioni JS e clic link sarebbero protetti con First-Party-Only cookie, a meno che non si usi la modalità Lax .
Il modulo POST s sarebbe sempre protetto poiché POST è considerato non sicuro.

Quindi, quando questo viene implementato attraverso i browser, i token CSRF sono obsoleti?

I token CSRF sono ancora utili perché possono garantire che gli endpoint possano solo essere richiamati da pagine specifiche sul tuo dominio. Dove i cookie di First-Party-Only possono solo garantire che provengano dallo stesso dominio. ~~Ciò significa che le vulnerabilità XSS su una pagina diversa verso il tuo endpoint non possono colpire quell'endpoint.~~

score 0 · Answer 3

Dalla lettura della sezione 7.1 "Limitazioni" I dare per scontato che l'autore della RFC sia consapevole della limitazione che descrivi. I cookie di prima parte non sono considerati come la protezione onnicomprensiva contro CSRF.

I cookie di prima parte sono solo rientrati per proteggere contro CSRF che sono invisibili all'utente finale. Ciò significa che non intende proteggere contro CSRF, il che comporterà la modifica dell'URL visibile, come accade quando si segue un link, si invia un modulo o si riceve un reindirizzamento usando il meta tag o una risposta HTTP. Ma dovrebbero proteggere dalla CSRF invisibile che non modifica l'URL visibile e che può essere fatto con il tag immagine, all'interno di un iframe o di un simile.