Strategia token CSRF

0

Sto cercando di saperne di più sulla sicurezza del sito Web, ma è fonte di confusione. Spesso mi sento come se avessi bisogno di essere un attaccante per capire come difendermi da uno, dal momento che non so cosa sono in grado di fare. Attualmente mi sto interrogando sulla migliore strategia per implementare i token CSRF. Raccolgo che è meglio generare il token al login e includerlo nei moduli di invio.

Ma cosa succede se ho una pagina di aggiornamento del profilo di un membro che funziona in questo modo:

  1. Ricevi l'ID del membro tramite $ _GET
  2. Recupera le informazioni dei membri dal DB
  3. Invia modifiche modulo a self
  4. Aggiorna DB

So che dovrei inviare il token nel passaggio 3, ma dovrei anche inviarlo tramite $ _GET nel passaggio 1, prima di interrogare il DB? In tal caso, dovrei usarlo anche su qualsiasi pagina riservata ai membri che interroga il DB, anche se non esiste una forma? O sto rendendo le cose inutilmente complicate? Leggere su questa roba tende a rendermi un po 'paranoico.

    
posta gr8dane 28.10.2014 - 18:22
fonte

3 risposte

3

Nel contesto di CSRF e XSS, l'autore dell'attacco è vincolato dalla Politica Same-Origin . È possibile utilizzare XSS per ignorare la politica Same-Origin ed eseguire qualsiasi azione come utente. Dove l'obiettivo per CSRF è di eseguire un'azione specifica, e ciò è permesso perché a quell'azione manca una prova di lavoro. Se una richiesta non ha un token CSRF o una prova di lavoro, è quindi vulnerabile a CSRF.

Inoltre, l'accesso ai dati tramite l'ID del membro, che viene passato come parametro GET, è di gran lunga peggiore di CSRF e XSS. Si chiama Riferimento ad oggetti diretti non sicuri (IDOR). In poche parole, l'applicazione consente agli utenti di modificare i dati che non possiedono. In questo contesto, l'autore dell'attacco non è vincolato dalla politica Same-Origin, l'utente malintenzionato può inviare richieste HTTP arbitrarie al server per ottenere ciò che desidera. Per proteggere l'ID del membro, deve essere una variabile $_SESSION .

Questa forma proposta è probabilmente vulnerabile sia a IDOR che a CSRF.

Raccomando di leggere tutti i OWASP primi 10 .

    
risposta data 28.10.2014 - 18:34
fonte
1

Il falsificatore di richieste intersito (noto anche come attacchi CSRF o XSRF) è un attacco che consente agli aggressori di eseguire azioni indesiderate su un'applicazione Web in cui un utente è attualmente autenticato. L'attacco è possibile quando l'applicazione mirata non convalida correttamente l'origine della richiesta e fa affidamento esclusivamente sull'esistenza di una sessione valida tra il browser della vittima e il server dell'applicazione.

Nello scenario più comune di un attacco CSRF, un utente connesso accederà a una pagina Web aggiuntiva fornita dall'hacker in un'altra scheda del browser. Questa pagina verrà immediatamente indirizzata a una funzione sensibile all'interno dell'applicazione, che è ancora aperta nell'altra scheda, inviando una richiesta appositamente predisposta. Poiché la richiesta viene inviata dallo stesso browser, l'applicazione vulnerabile accetterà la richiesta ed eseguirà l'azione.

LacorrettaprotezioneCSRFsibasasullaprevenzionechegliaggressoripossanocreareunarichiestagranularediazioniinunsistema.Unasoluzioneaquestotipodiattaccoconsistenell'implementaretokencasualiunivociperleformesensibili.Perogniinviodimoduli,iltokendeveessereconvalidatosullatoserver.

Comenotaamargine,questitokendovrebberosempreessereinviatiutilizzandoilmetodoPOST.Disolitovengonoforniticomecampomodulonascosto.

EccounesempiodiimplementazioneCSRFperPHP:

  1. GenerazionediuntokenCSRFsicuroinPHP
functiongenerateCSRFKey($key){$token=base64_encode(openssl_random_pseudo_bytes(16));$_SESSION['csrf_'.$key]=$token;return$token;}

Potrestiesseretentatodiusarerand()ouniqid()maentrambispecificanoesplicitamentechequestefunzioninondevonoessereutilizzatepergeneraretokensicuri!Anchebase64_encode()èusatosoloperassicurarsicheilvalorenoninfrangealcuncodiceHTML.

  • Il controllo di un token inviato è valido:
  • function checkCSRFKey($key, $value) {
        if (!isset($_SESSION['csrf_' . $key]))
            return false;
        if (!$value)
            return false;
    
        if ($_SESSION['csrf_' . $key] !== $value)
            return false;
    
        unset($_SESSION['csrf_' . $key]); 
        return true;
    }
    

    Il codice sopra può essere usato per aggiungere un token univoco a qualsiasi modulo usando:

    " name="token">
    
    1. Il codice da verificare sul lato server se il token fornito è valido:
    $token = $_POST['token'];
    if (checkCSRFKey('settings', $token)) {
        // Handle error
    }
    
        
    risposta data 28.10.2014 - 20:27
    fonte
    0

    Nel contesto della tua descrizione ci sono un paio di dubbi. Saranno legati alla CSRF in seguito. Innanzitutto, l'area del tuo membro deve essere crittografata. Ad esempio, il link ha informazioni pubbliche e va bene non essere criptato. link * sarebbe dove solo gli utenti autenticati possono accedere ai loro profili e fare qualsiasi altra cosa che richiede un utente autenticato. Chiunque navighi su link * senza una sessione valida, verrebbe reindirizzato alla pagina di accesso. Lì avrebbero inserito il nome utente e la password. Dopo aver autenticato il nome utente e la password, sarebbe stata stabilita una sessione SSL / TLS (idealmente TLS). Il sessionID verrebbe archiviato in un cookie con i flag HTTP e Secure impostati. Ciò garantisce la protezione della sessione di ciascun utente e, soprattutto, inserisce il modulo di aggiornamento del profilo dietro un livello di crittografia.

    Questa crittografia aggiunge un livello di protezione per il modulo. Anche se il modulo è vulnerabile a CSRF, il server può essere configurato in modo da consentire solo i moduli degli utenti con una sessione valida, che richiede un utente autenticato. Oppure un altro attacco per ottenere una sessione valida, in entrambi i casi è più utile sfruttare la vulnerabilità di CSRF. Esistono un paio di modi diversi per implementare protezioni CSRF . Tuttavia, la versione rapida è che funziona come un one-time-pad, per richiesta. Quando un utente invia il modulo, il client calcola il one-time-pad e lo aggiunge alla richiesta. Il server verifica la sessione, quindi il one-time-pad prima di accettare la richiesta.

        
    risposta data 28.10.2014 - 20:03
    fonte

    Leggi altre domande sui tag