Ho bisogno di protezione CSRF in questa configurazione con un'API REST supportata da oauth2 e un server di autenticazione SSO di autenticazione di base?

Naviga le tue risposte
5

Ho visto la risposta È possibile CSRF se non utilizzo nemmeno i cookie? , ma ci sono 2 risposte in conflitto e la domanda in sé non fornisce molte informazioni.

Sto creando un'API REST che verrà utilizzata da un client Web (di nostra creazione) in esecuzione su un altro dominio, pertanto eseguiremo richieste CORS. Questa API viene eseguita come server di risorse oauth2, pertanto l'accesso è limitato dai token di accesso che vengono passati nell'intestazione dell'autenticazione. Non abbiamo biscotti lì, tutto è senza stato. Sto seguendo il consiglio nell'articolo al link

  • Useremo SSL
  • Abbiamo pre-registrati reindirizzamenti uri
  • Il nostro unico tipo di concessione è il codice di autorizzazione, senza richiedere un segreto client (poiché l'origine del client Web è pubblico) invece del tipo di concessione implicita, come da raccomandazioni su link
  • Il client si autentica con un'intestazione quando effettua chiamate al server delle risorse effettive
  • L'ottenimento del token di accesso viene effettuato passando il codice di autorizzazione 1 volta nei parametri del modulo ( x-www-form-urlencoded ), che sembra essere il modo normale, non dovrebbe rimanere bloccato nella cronologia del browser poiché non è un parametro di query. / li>
  • Il client utilizzerà anche alcuni parametri dello stato segreto quando ottiene il codice di autorizzazione. In questo caso non sono sicuro che ci sia un punto in quanto il client non dipende da un segreto per ottenere un token di accesso scambiando comunque un codice.
  • Per l'endpoint oauth / token in cui si ottiene effettivamente un token di accesso, l'unica origine consentita è il dominio del nostro client Web
  • Per l'endpoint oauth / authorize, CORS non è consentito. Forse questo è eccessivo dal momento che il reindirizzamento uri ricollegherebbe comunque solo al nostro dominio?

Penso che copra praticamente tutto da quella parte.

Ora c'è un altro possibile vettore di attacco nella forma del server di autenticazione oauth stesso, che dovrebbe essere SSO e ha sessioni ed è accessibile con l'autenticazione di base. Tuttavia, non sembrano esserci azioni che potresti intraprendere con un attacco csrf che sarebbe effettivamente utile. Potresti fare una richiesta a questi endpoint oauth ma dovresti essere in grado di leggere il risultato, che è impedito dalla configurazione di CORS e dal fatto che gli uri di reindirizzamento sono pre-registrati. Non c'è POST che tu possa fare lì per cambiare la tua password, resettare il tuo indirizzo e-mail eccetera, tutte quelle cose sono in realtà anche esposte come un server delle risorse.

Mi manca qualcosa? Come andresti a sondare le vulnerabilità qui?

    
posta Sebastiaan van den Broek 11.07.2018 - 06:28
fonte

1 risposta

3

Per rispondere alla tua domanda iniziale: non hai bisogno di implementare contromisure CSRF sul tuo server delle risorse, se non stai utilizzando i cookie (sessioni) e non stai utilizzando l'autenticazione di base all'interno del browser.

I cookie e l'intestazione di autorizzazione di base vengono archiviati dal browser per ogni nome di dominio che visiti e ogni volta che invii una richiesta a un sito, i cookie salvati e l'intestazione di autorizzazione di base vengono automaticamente aggiunti alle intestazioni delle richieste.

Poiché utilizzi un token di accesso e presumibilmente lo invii utilizzando Authorization: Bearer <token> , dovresti essere sicuro. Il tuo browser non sa come gestire questo tipo di autorizzazione e questo è anche il motivo per cui devi aggiungere manualmente questa intestazione in ogni richiesta.

URI di reindirizzamento

Stai utilizzando URI di reindirizzamento pre-registrati, che è raccomandato dallo standard OAuth 2.0. Ciò garantisce che il tuo server di autorizzazione invii solo codici di autorizzazione ai siti di cui ti fidi.

È importante che gli URI di reindirizzamento utilizzino uno schema sicuro, come HTTPS, altrimenti sei vulnerabile a un attacco MITM.

Scambio del codice di autorizzazione per il token di accesso

Il tuo sito riceve un codice di autorizzazione tramite un parametro di query, quando sei reindirizzato dal server di autorizzazione. Molto probabilmente, stai scambiando immediatamente il codice di autorizzazione per un token di accesso, che in seguito dovrebbe revocare il codice di autorizzazione.

Il parametro state dovrebbe essere usato qui per prevenire gli attacchi CSRF, ad es. inviando un valore casuale all'endpoint authorize e verificando che si stia ricevendo lo stesso valore con il codice di autorizzazione. In una SPA, è possibile salvare il valore casuale nella memoria locale, cioè

In una SPA, devi preoccuparti meno di questo, che ad es. in un'applicazione web stateful sul lato server. Cosa succede se un utente malintenzionato ti reindirizza alla pagina di autorizzazione dalla sua pagina web? Finisci nella tua SPA, dove l'attaccante non dovrebbe poter continuare.

In un'applicazione server sideful, è possibile che, eseguendo questa autorizzazione, si colleghino effettivamente gli account e le cose possano iniziare a verificarsi. (A seconda dell'applicazione, ovviamente.)

CORS su token endpoint

Prima di tutto, CORS viene controllato solo dal tuo browser, quindi non devi fare affidamento su di esso per impedire a un utente malintenzionato di utilizzare il tuo token endpoint.

Per aggirare CORS qui, tutto ciò che un utente malintenzionato dovrebbe fare, è creare un endpoint proxy, che invia semplicemente la richiesta al tuo token endpoint.

Inoltre, l'endpoint token funziona solo se riceve un codice di autorizzazione valido.

CORS sul authorize endpoint

Normalmente, reindirizzeresti i tuoi utenti all'endpoint authorize , dove avrebbero (accedi e) fare clic su un pulsante di autorizzazione, garantendo l'accesso all'applicazione.

Senza CORS, un probabile attacco è che un utente malintenzionato possa creare il proprio sito, dove usa XHR / fetch per recuperare la tua pagina authorize . E supponendo che l'utente abbia effettuato l'accesso (con lo stato) sulla tua pagina authorize , sarà in grado di fare clic sul pulsante di autorizzazione, senza il consenso dell'utente.

Non esiste uno scenario in cui sia necessario utilizzare XHR / fetch per recuperare la pagina authorize . Quindi puoi tranquillamente bloccarlo con CORS.

Server di autorizzazione

Se il tuo server di autorizzazione ha lo stato, mentre scrivi, devi implementare la protezione CSRF ogni volta che esegui un'azione che può cambiare qualcosa. È consigliabile farlo in generale e se in futuro aggiungi una funzione di aggiornamento della password, hai già il codice necessario per la protezione da CSRF.

Raccomandazioni

Sembra che tu abbia compreso le specifiche OAuth. e sembra che tu stia facendo ciò che dovresti.

  • Le raccomandazioni ovvie sono di usare HSTS con precaricamento (e HPKP), per prevenire attacchi MITM.
  • Assicurati che i tuoi codici di autorizzazione siano di breve durata e possano essere utilizzati una sola volta. Non è necessario che siano validi per molto tempo, in scenari normali viene utilizzato immediatamente dopo essere stato concesso.
  • Non memorizzare token di accesso finale, token di aggiornamento, codici di autorizzazione nel database. Memorizza invece un identificatore (ad esempio 64 byte a caso) e emetti una versione firmata (ad es. JWT). Questo impedisce agli aggressori di estrarre i token di accesso dal tuo database, poiché l'utente malintenzionato non può comunque utilizzarlo.
  • Utilizza un'implementazione standard di OAuth, non eseguire il rollover.
risposta data 18.07.2018 - 09:26
fonte

Leggi altre domande sui tag

In che modo l'ambiente legale / di telecomunicazione del mio paese protegge dai cold-callers che connettono una sessione di accesso remoto al computer della vittima? È possibile utilizzare il disegno o scarabocchiare come metodo di autenticazione?