Prevenzione CSRF in PHP

Naviga le tue risposte
6

Due domande.

  1. Da dove viene scaricato la versione PHP di CSRF Guard di OWASP? Il seguente URL dice di controllare Git:

    link

    Tutto ciò che vedo su Git è comunque file * .java e * .js. Se ci sono file PHP in cui sono nella struttura delle directory?

  2. phpBB impedisce CSRF aggiungendo due parametri nascosti a tutti i moduli. L'ora e un hash SHA1 del tempo, un "form salt" per utente, l'identificatore di sessione e il nome del modulo. Fonte:

    link

    La mia domanda è ... perché è necessario qualcosa di diverso dal sale di forma? Per prevenire CSRF tutto ciò di cui hai bisogno è una stringa casuale che un utente malintenzionato non può prevedere in modo tale che non possa inviare una richiesta HTTP cieca e il modulo salt farebbe il trucco che mi sembra. Frustare questo insieme a tutto il resto sembra inutile.

    Forse la loro motivazione è che il modulo sale potrebbe essere compromesso se qualcuno copia / incolla il contenuto HTML della pagina? Forse è destinato a dimostrarlo in futuro? Una vulnerabilità XSS comprometterebbe in modo permanente le protezioni CSRF se il sale modulo è stato utilizzato direttamente mentre con un hash di tempo e il sale sale protegge da tale scenario.

    Inoltre, se il sale fosse solo di due caratteri o così potrei capire di fare l'hash sha1 () ma un lungo di due caratteri è solo insicuro perché tutto quello che devi fare a quel punto è inviare 256 ** 2 richieste HTTP cieche , ognuno con un diverso token. Ma non sono nemmeno due caratteri.

posta compcert 02.02.2012 - 08:19
fonte

2 risposte

2

  1. Particolare, ma non sei prima persona per chiederglielo , e c'è anche un'implementazione suggerita per la protezione CSRF lì + il codice ospitato su github . Non posso davvero garantire questo meccanismo, però, non l'ho davvero controllato da vicino.

  2. Domanda interessante. Mi sembra che phpbb sia andato un po 'sopra le righe con l'implementazione, ma c'è una logica dietro. Il solo sale non sarebbe sufficiente, perché nel caso phpbb, il valore user_form_salt è un valore statico per utente, che non cambia per quel particolare utente. Ciò significa che una volta che questo valore è noto / divulgato (e probabilmente esistono molti modi in cui questo valore può essere trapelato o ottenuto), tutti i moduli utente possono essere compromessi. Per sempre (o più precisamente per la durata di questo sale, ma non cambia in genere). Il metodo implementato lì ha il vantaggio che il valore cambia costantemente, tuttavia è "riproducibile" dal server per il controllo senza doverlo memorizzare da nessuna parte. Usa i dati memorizzati esistenti + alcuni elementi casuali per generare il token CSRF. Non sono troppo sicuro, ma suppongo che l'utilizzo, ad es. hash / HMAC del tempo con la variabile di sessione casuale interna (non esposta) come chiave, otterrebbe lo stesso risultato.

Infine, solo una breve nota sul tuo commento riguardante XSS e CSRF. Hai detto che

An XSS vulnerability would permanently compromise the CSRF protections if the form salt was used directly whereas with a hash of time and the form salt protects against that scenario.

In sostanza, una vulnerabilità XSS ha il potenziale per compromettere QUALSIASI protezione CSRF. Se l'utente malintenzionato è in grado di eseguire codice con la sessione utente, ha accesso a tutti i dati del modulo, per quanto ben protetto possa essere.

    
risposta data 02.02.2012 - 20:55
fonte
0

Rispondi per la prima parte:

La versione php di OWASP CSRF Guard è stata implementata come OWASP CSRF Protector (il nome del progetto è stato modificato a causa della diffrazione in logica di progettazione). È disponibile su github per il download!

    
risposta data 13.12.2014 - 18:52
fonte

Leggi altre domande sui tag

Sicurezza Haskell e Happstack Quale organo di governo è responsabile per l'uso di SMS SenderID alfanumerici GSM?