Sto pensando a CSRF per proteggere tutte le richieste AJAX pubbliche che restituiscono JSON, ma ho alcune preoccupazioni

Question

Sto pensando a CSRF per proteggere tutte le richieste AJAX pubbliche che restituiscono JSON, ma ho alcune preoccupazioni

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

1

Sto pensando a CSRF a proteggere tutte le richieste AJAX pubbliche che restituiscono JSON, perché cosa impedire a un altro sito di falsificare l'intestazione AJAX e utilizzare il JSON come se fosse un'API pubblica? Penso che la protezione CSRF sia la soluzione migliore per questo, tuttavia sono interessato al modo in cui Laravel gestisce questo :

Usando il filtro CSRF di laravel, noto in app / filters.php che controlla usando Session:token , ciò richiede che ogni visitatore pubblico abbia una sessione e imponga requisiti aggiuntivi sulla RAM del server (come contrario alla navigazione senza sessioni).
Nel filtro CSRF, Laravel controlla Input::get('token') , ma potrei voler fare anche le chiamate ajax POST. Le richieste POST non funzioneranno?
Che cosa succede se un visitatore ha una finestra aperta. Si allontanano per un po '... poi tornano per eseguire una richiesta di ajax. Questo sarebbe un problema e avremmo bisogno di aggiornare la pagina, che sembrerebbe scomoda per un visitatore pubblico (al contrario degli utenti che hanno effettuato l'accesso, dove potremmo semplicemente reindirizzare a una pagina di accesso).
Cosa succede se un visitatore (o anche un utente che ha effettuato l'accesso) ha 2 finestre aperte? Si allontanano e lasciano scadere la sessione. Quindi, ritorna e aggiorna una finestra (o accedi di nuovo in una finestra), quindi vai alla seconda finestra per eseguire un'operazione (solo per trovarla non funziona o sono costretti ad accedere di nuovo).

Qualcuno può affrontare questi problemi nell'implementazione della protezione CSRF di Laravel?

php ajax laravel

posta David Graham 17.03.2014 - 23:52

fonte

2 risposte

0

Ecco una risposta alla tua domanda n. 3 su ajax e probabilmente anche # 4

Per Laravel 5.4 a maggio 2017, ho risolto il problema in questo modo:

In web.php :

Route::post('keep-token-alive', function() {
    //https://stackoverflow.com/q/31449434/470749
    return 'Token must have been valid, and the session expiration has been extended.'; 
});

In javascript nella visualizzazione:

$(document).ready(function () {

    setInterval(keepTokenAlive, 1000 * 60 * 15); // every 15 mins

    function keepTokenAlive() {
        $.ajax({
            //https://stackoverflow.com/q/31449434/470749
            url: '/keep-token-alive', 
            type: 'post',
            headers: {
                'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
            }
        }).then(function (result) {
            console.log(new Date() + ' ' + result + ' ' + $('meta[name="csrf-token"]').attr('content'));
        });
    }

});

Ricorda che devi non elencare 'keep-token-alive' nelle esclusioni entro VerifyCsrfToken.php . Come @ ITDesigns.eu implica in un commento, è importante per questa route verificare che vi sia un token valido al momento e che è sufficiente che la sua scadenza sia estesa.

Vedi la mia risposta più approfondita qui su StackOverflow .

risposta data 23.05.2017 - 01:00

fonte

Leggi altre domande sui tag php ajax laravel

Alternative all'annotazione JDT - Problemi di licenza Codice di analisi e analisi del set di regole concatenato: raccomandazioni?

score 2 · Accepted Answer

Sì, tutte le implementazioni che ho visto per CSRF utilizzano sessioni a salva il token. In questo modo gli utenti possono utilizzare il sito Web in più schede o finestre senza emettere più token (che sovrascrive in modo efficace il token precedentemente valido poiché viene tracciato solo un token per utente). Penso che troverai i requisiti aggiuntivi del server per l'utilizzo di sessioni è abbastanza trascurabile.
Le richieste di posta funzioneranno. La funzione Input :: get () ottiene effettivamente le variabili da $ _GET e $ _POST. Per citare il documentazione ( link )

You do not need to worry about the HTTP verb used for the request, as input is accessed in the same way for all verbs.
Una possibile soluzione sarebbe quella di passare un nuovo token in una delle richieste json ogni volta che scade. Se si utilizza questo metodo e si dispone di moduli normali (non Ajax) sul stessa pagina dovrai usare javascript per sostituire i valori dei token in ognuno di questi forme.
Poiché CSRF utilizza le sessioni per tenere traccia del token e presupponendo di aver risolto il problema 3, la seconda finestra non dovrebbe presentare problemi durante l'operazione poiché i token verrebbero automaticamente aggiornati alla scadenza.