Perché questa vulnerabilità di Laravel CSRF funziona?

3

Recentemente Laravel 4 è stato aggiornato per risolvere un problema di sicurezza: c'era una vulnerabilità CSRF nel loro codice .

Ecco il vecchio codice:

if (Session::token() != Input::get('_token'))
{
    throw new Illuminate\Session\TokenMismatchException;
}

Ed ecco la loro correzione (nota il !== ):

if (Session::token() !== Input::get('_token'))
{
    throw new Illuminate\Session\TokenMismatchException;
}

Comprendo la differenza tra == e === in PHP (in pratica il secondo è più rigido perché controlla il tipo), e capisco cos'è CSRF e come affrontarlo, ma non capisco del tutto perché questo caso specifico crea una vulnerabilità o il modo in cui un utente malintenzionato potrebbe sfruttarlo.

    
posta Jason 24.11.2014 - 13:57
fonte

2 risposte

3

chrismsnz here ...

Per farla breve, DarkLighting ha praticamente ragione.

Input::get() di solito legge dai parametri della richiesta, ma se la richiesta è JSON, legge dal corpo JSON. JSON ti permette di specificare il tipo di dati così invece di una stringa token CSRF, ho inviato un int (0) che passerà il confronto libero il più delle volte.

L'altro trucco è che di solito non è possibile inviare richieste JSON cross-site, a causa del controllo CORS nei browser. Tuttavia, Laravel ha un controllo JSON molto scarso, fondamentalmente controlla se la stringa '/json' è ovunque nel tipo di contenuto e se è lì, esegue l'intera richiesta attraverso un parser JSON e lo alimenta in Input .

Quindi puoi sfruttarlo usando qualcosa come questo (esempio jquery)

$.ajax("http://<laravel app>/sensitiveaction", {
    type: 'post',
    contentType: 'application/x-www-form-urlencoded; charset=UTF-8; /json',
    data: '{"sensitiveparam": "sensitive", "_token": 0}',
});
    
risposta data 17.02.2015 - 03:47
fonte
3

Sembra che fosse una divulgazione privata, quindi sembra che non lo sapremo di sicuro a meno che qualcuno non si prenda il tempo di analizzare il codice quadro (o @chrismsnz decida di spiegarcelo).

Ma da quello che potrei dire, sembra come Session :: token () restituisce una stringa e Input :: get () restituisce un oggetto misto .

Dalla spiegazione piuttosto breve che hanno dato, il ricercatore ha trovato un modo per rendere la variabile contenente dati arbitrari usando JSON , ma il valore non ha il tipo corretto ( stringa ). Poiché il framework stava solo controllando il valore corretto, è stato in grado di ignorare il filtro.

    
risposta data 24.11.2014 - 18:41
fonte

Leggi altre domande sui tag