È CORS open-to-all sicuro per schemi di autenticazione non basati su cookie (ad es. OAuth)

1

Sto costruendo una API con endpoint protetti e pubblici e la sto proteggendo con i vari flussi di OAuth 2. Voglio che questa API sia aperta al mondo: il principale sito Web del consumatore non sarà nemmeno sulla stessa origine del server API. Quindi ho intenzione di implementare CORS.

Molti testi mettono in guardia contro terze parti "che inviano richieste come l'utente ", ma non sono sicuro di cosa significhi. I presumo questo è simile a come funziona CSRF - come in, le richieste vengono inviate con i cookie dell'utente.

Se questo è il caso, dal momento che il mio schema di autenticazione OAuth 2 utilizza token passati attraverso l'intestazione HTTP o un parametro GET, non sarebbe questo un problema? Il mio servizio non tocca nemmeno i cookie.

Qualsiasi terza parte che tenta di eseguire un'operazione protetta per conto dell'utente non ha accesso a un token valido (che è archiviato su memoria locale o in memoria). O a meno che l'utente invochi esplicitamente un flusso di OAuth 2, assegna alla terza parte un token valido e utilizza quello (funzionando come previsto) - o non è un'operazione che richiede l'utente da autenticare, che funzionerebbe (funzionando anche come previsto).

Naturalmente, come tutti sappiamo, quando presumo di fare un asino da oh dio siamo compromessi ci sono gattini ovunque , quindi potrei sbagliare e c'è un maggiore divario di sicurezza che solo biscotti Grazie!

    
posta bananapeel 28.06.2014 - 11:29
fonte

1 risposta

1

"sending requests as the user", but I'm not sure what they mean by that. I assume this is similar to how CSRF works

Esattamente.

as in, the requests get sent across with the user's cookies.

CSRF non richiede necessariamente i cookie. È semplicemente più semplice con i cookie perché vengono allegati automaticamente a qualsiasi richiesta relativa a una particolare origine.

Se le credenziali di autorizzazione sono ipotizzabili o cancellabili, una iframe di terze parti può falsificare una richiesta con loro. CORS semplifica la creazione di una richiesta con intestazioni che di solito non fanno parte di un GET o POST avviato dal browser.

Se esegui l'autorizzazione tramite segreti nell'URL, assicurati che il tuo servizio CORS includa le intestazioni appropriate in modo da non essere vulnerabili a annusare la cronologia e attacchi di canali laterali simili. I parametri incorporati di OAuth dovrebbero avere abbastanza entropia da essere sicuri contro lo sniffing, ma c'è sempre una perdita di referrer dalla tua parte a cui badare, quindi quelle intestazioni sono una buona idea.

Any third parties attempting to do a protected operation on behalf of the user wouldn't have access to a valid token (which is stored on local storage or in-memory).

Sembra che tu abbia una maniglia sui principali vettori di attacco.

Se è archiviato in locale-storage, quindi un XSS su qualsiasi pagina con accesso a tale archivio locale potrebbe perdere il token.

Se non puoi mantenere il token in un'origine che non include HTML con contenuti di terze parti, allora potrebbero esserci trucchi che puoi fare con document.domain per limitare la finestra di esposizione agli script iniettati su qualsiasi pagina è nella stessa origine del token.

  1. carica JS che recupera e sequestra il token utilizzando l'integrità della chiusura per fornire un'API ad altri JS nella pagina senza esporre il valore del token stesso.
  2. cambia l'origine della pagina in modo da non avere più accesso all'archivio locale
  3. procedere per eseguire il resto dello script di pagina che potrebbe avere contenuto iniettato

Inoltre, CSP potrebbe fornire la difesa in profondità lungo la strada.

    
risposta data 28.06.2014 - 14:24
fonte

Leggi altre domande sui tag