Qual è un modo corretto per proteggere l'interfaccia REST dal furto di sessione?

Question

Qual è un modo corretto per proteggere l'interfaccia REST dal furto di sessione?

#1 da (1 voti)

1

Supponiamo che l'autore dell'attacco sia stato in grado di iniettare JavaScript nel sito web. Ovviamente può fare qualsiasi richiesta HTTP per fare il backend di imitare le azioni dell'utente, a meno che non ci sia una conferma come il codice SMS che richiede l'interazione diretta da parte dell'utente (anche in questo caso il JavaScript dannoso potrebbe ingannare l'utente). Quindi, immagino, questo vettore di attacco non possa essere ragionevolmente difeso. Ma se l'attaccante ruba una sessione, può impersonare l'utente e fare quasi tutto. Quindi sto pensando alla difesa di questo vettore. Certo, il server potrebbe controllare l'indirizzo IP, ecc., Ma non è sempre possibile.

Prima cosa: memorizzare la sessione in un cookie solo HTTP. JavaScript non può rubarlo. Fin qui tutto bene. Ma c'è un altro punto debole: il sito Web di terze parti può creare tag con azioni dal mio server e inviare questo modulo con il cookie dell'utente. Si potrebbero usare token CSRF, ma ancora dovrebbero essere disponibili per JavaScript, potrebbero essere rubati se JavaScript viene compromesso, devono essere mantenuti sul server web, il che danneggia la scalabilità, ecc. Sto pensando di usare il metodo PUT per ogni azione REST (beh, non sarà un REST corretto ovviamente, chiamiamolo API HTTP). Non c'è modo di indurre l'utente a emettere la richiesta PUT dal sito web di terze parti e il cookie solo HTTP impedirà il furto del valore del cookie.

Non vedo questo utilizzo, quindi credo che mi manchi qualcosa e ci dovrebbe essere un modo più semplice per proteggere gli endpoint?

rest http

posta vbezhenar 27.09.2017 - 16:25

fonte

1 risposta

Leggi altre domande sui tag rest http

Accesso diretto alle pagine di amministrazione, il server Web o il server delle applicazioni sono configurati in modo non sicuro Come impedire l'iniezione di JSONP

score 1 · Answer 1

Penso che potresti aver frainteso CSRF come vettore di minacce. Un attacco CSRF è uno in cui l'attaccante non ha accesso al DOM ed è in grado di forzare il browser dell'utente a inviare una richiesta che include il token di autenticazione dell'utente. XSS è dove l'hacker è in grado di manipolare il DOM. Se l'utente malintenzionato può manipolare il DOM, può costringere l'utente a inviare eventuali richieste e includerà sia i valori del cookie HTTPOnly sia i token anti-CSRF. Qualsiasi limitazione CSRF messa in atto può essere aggirata se un utente malintenzionato può controllare il DOM (XSS).

Dato questo, la migliore implementazione includerebbe sia un token di autenticazione HTTPOnly sia un token anti-CSRF accessibile a JavaScript.

Inoltre, è possibile implementare token anti-CSRF che non devono essere gestiti lato server utilizzando i cookie HttpOnly. Includete un token generato in modo casuale in un cookie HTTPOnly e includete lo stesso token in un modo accessibile da DOM. Quando il client restituisce la richiesta, includere il token anti-CSRF come intestazione (o tramite un metodo simile). Quindi, sul server, si convalida che sia il token HTTPOnly sia i token di intestazione coincidano. Un attacco CSRF invierà il token HTTPOnly, ma non può inviare il token di intestazione corrispondente. Un attacco XSS sarà comunque in grado di aggirare questo problema, ma come detto sopra, le mitigazioni anti-CSRF non funzioneranno se l'attaccante controlla il DOM.