Difetti di sicurezza per l'uso di token di accesso di breve durata in client javascript

Question

Difetti di sicurezza per l'uso di token di accesso di breve durata in client javascript

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

6

Ho intenzione di costruire un sito di front end interamente in javascript (NodeJS) e mi piacerebbe fare chiamate ajax a un REST WS che si trova su un altro dominio sul lato client.

Intendo usare oauth2 e SSL per proteggere il mio back-end REST, eseguire il token di accesso che chiede sul lato front-end del server, ma poiché voglio essere in grado di effettuare chiamate Ajax, devo usare il token di accesso ottenuto sul client lato.

La mia domanda è: qual è il pericolo di utilizzare un token di accesso di breve durata sul lato client per eseguire chiamate ajax tra domini diversi? Non è sicuro come usare i cookie? So che passare da un proxy dovrebbe essere più sicuro ma vale davvero la pena?

Grazie mille.

rest oauth ajax

posta rico 09.04.2012 - 23:45

fonte

2 risposte

Leggi altre domande sui tag rest oauth ajax

Utilizzo di un certificato verificato per firmare altri Risorse sui rischi per la sicurezza di NFC

score 4 · Answer 1

Con qualsiasi API su HTTP devi preoccuparti degli attacchi di contraffazione di richieste tra siti. JSON + REST CSRF è possibile . Questo non sta prendendo in considerazione JSONP o CORS perché la richiesta non viene eseguita con un XHR.

L'attivazione di CORS causa enormi problemi nel tentativo di proteggere la tua API. In effetti, CORS revoca i tuoi diritti di proteggere il tuo sito web con la stessa politica di origine, è molto simile alla presenza di una vulnerabilità XSS sul tuo sito web.

Un ottimo metodo per prevenire CSRF è includere un token casuale con ogni richiesta. Sfortunatamente questo non è molto RESTful, ma è sicuro. In alcuni casi un utente malintenzionato può ottenere questo token CSRF abusando di JSON ( link ), e ci sono modi per prevenire questo . Se stai servendo questo token con un'API REST abilitata per CORS, non c'è modo di impedire a un utente malintenzionato di ottenere questo token, e in questo caso non puoi impedire CSRF.

score 3 · Answer 2

Se capisco la tua domanda, il tuo approccio proposto va bene, purché tutte le connessioni siano su HTTPS. Non c'è niente di sbagliato nell'includere un token di accesso di breve durata nella richiesta per dimostrare che la richiesta fa parte di una sessione autenticata. È fondamentalmente isomorfo utilizzare un cookie di sessione per dimostrare che una richiesta fa parte di una sessione stabilita.

Ci sono alcune precauzioni che dovresti fare attenzione. Dovresti solo collegare il token di accesso alle richieste che hai costruito interamente da solo; altrimenti, gli attacchi CSRF diventano possibili. Se si utilizza un client Web, quindi includere il token di accesso nei parametri URL non è l'ideale: i parametri URL vengono spesso registrati sul lato server e possono essere divulgati nell'intestazione Referer . È meglio inviare il token di accesso in un parametro di modulo nascosto incluso nei dati POST. (I cookie evitano questi problemi, perché non vengono inviati nel parametro URL, sebbene introducano i propri rischi, in particolare CSRF.)