CNet sta segnalando che tutti OpenID e OAuth i siti sono vulnerabili a un attacco chiamato "Covert Redirect". Che cos'è questo attacco, come funziona e come utente finale, come posso mitigare il rischio?
CNet sta segnalando che tutti OpenID e OAuth i siti sono vulnerabili a un attacco chiamato "Covert Redirect". Che cos'è questo attacco, come funziona e come utente finale, come posso mitigare il rischio?
Questa non è affatto una vulnerabilità di / in OAuth 2.0. Il problema è stato selvaggiamente esagerato e errato da CNET e dal cercatore originale.
Ecco in breve: se il tuo sito web (esempio.com) implementa un endpoint di reindirizzamento aperto, ovvero implementa un URL che reindirizzerà il browser a qualsiasi URL fornito nell'URL parametri - E il tuo reindirizzamento copia i parametri dell'URL dall'URL in entrata all'URL di reindirizzamento in uscita, quindi è possibile che terzi sfruttino questo artefatto del tuo sito web in un'ampia varietà di modi cattivi.
Caso peggiore: evil.com è in grado di ottenere il codice di autenticazione originariamente previsto per il tuo sito web (esempio.com) e potrebbe essere in grado di utilizzare quel codice di autenticazione per estrarre le informazioni utente dal provider di autenticazione (Google, Facebook, ecc. ) o forse addirittura assumere il controllo dell'account dell'utente sul tuo sito web.
Potrebbe evil.com essere in grado di assumere il controllo dell'account Google dell'utente utilizzando tale codice di accesso? No, perché il codice di accesso è stato coniato per il tuo sito, esempio.com, e funziona solo lì.
Chi è la colpa è? Distinti, per implementare un reindirizzamento aperto sul tuo sito. Non incolpare Google o Facebook o altri per la tua scarsa implementazione.
Esistono alcuni casi di utilizzo legittimi per avere un reindirizzamento sul tuo sito. Il più grande è quello di reindirizzare il browser dopo il login alla pagina web (sul tuo sito) che l'utente ha originariamente richiesto. Questo deve solo reindirizzare dal tuo sito web alle pagine del tuo sito web, sul tuo dominio.
Come risolverlo? Il tuo endpoint di reindirizzamento (example.com/redirect? & destination = ht.tp: //foo.com ...) convalida l'URL di destinazione. Consenti solo reindirizzamenti alle pagine del tuo sito, nel tuo dominio.
Maggiori informazioni sul mio blog: link
Aggiornamento: esiste un problema di reindirizzamento aperto quando si utilizza Facebook per l'accesso utente OAuth. Quando configuri la definizione dell'app su Facebook, assicurati di inserire l'URL di reindirizzamento specifico del dominio nel campo di reindirizzamento fornito. Facebook consente a questo campo di essere lasciato vuoto. Se lasciato in bianco, Facebook stesso agisce come un reindirizzamento aperto durante l'elaborazione degli accessi degli utenti per il tuo sito web.
Facebook dovrebbe risolvere questo problema semplicemente non permettendo che il campo dell'URL di reindirizzamento sia lasciato in bianco.
Come altri hanno affermato, questa non è una nuova idea. Eran Hammer (uno dei creatori della specifica Oauth 1.0, che dimesso dal comitato Oauth 2.0 ) ha scritto una buona sinossi della vulnerabilità, quasi 3 anni fa. La sua descrizione non ha ottenuto un logo di fantasia o alcuna copertura mediatica sensazionale.
Ecco un video di YouTube che contiene il cercatore originale che ti guida attraverso la vulnerabilità: link .
OpenId e OAuth forniscono entrambi un campo che consente a un sito di terze parti di specificare un reindirizzamento quando l'autenticazione è completata e ha esito positivo. Ad esempio, vai su Good Reads, vogliono che tu acceda al tuo account Facebook. Good Reads dirà a Facebook, "hey, quando l'utente si autentica correttamente, reindirizza nuovamente a link ." La vulnerabilità è che alcuni di questi siti di terze parti consentono di specificare i reindirizzamenti nei relativi URL ( link ) e potrebbe non convalidarli prima che reindirizzino l'utente. Quindi, un utente malintenzionato potrebbe creare un collegamento "Accedi con Facebook" per un sito valido come Good Reads e potrebbe specificare l'URL di reindirizzamento come qualcosa di simile a link (supponendo che Good Reads abbia fatto questo tipo di reindirizzamento), il tuo popup di accesso a Facebook mostrerebbe che Good Reads (un sito perfettamente normale per te) vuole autenticarsi con Facebook, ma quando esegui l'autenticazione e il reindirizzamento a Good Reads, se Good Reads non convalida l'URL di reindirizzamento, verrai reindirizzato immediatamente al link .
La correzione sarebbe per le terze parti per convalidare i reindirizzamenti, ma ciò potrebbe richiedere del tempo. L'altra cosa è che CNet ha riferito che gli aggressori potrebbero essere in grado di sottrarre informazioni attraverso questo piccolo scambio, ma non sono sicuro se ciò sia possibile. Qualcun altro può commentare l'argomento. Ma ottenere un utente su un sito sbagliato è probabilmente abbastanza buono per loro.
Questa è una forma di uomo nell'attacco centrale in cui un sito può afferrare le tue credenziali OpenID. Funziona perché le fonti di openID (facebook, google, ecc.) Non eseguono controlli sufficienti quando vengono inviate query openID.
Non c'è nulla che l'utente possa fare al riguardo, tutto ciò che puoi fare è essere molto cauti nell'usare Oath e openID. Se un sito che non ti aspetteresti di utilizzare openID apre una finestra openID, quindi non permetterlo. Se sospetti che le tue credenziali openID siano state acquisite, vai alla fonte di autenticazione (facebook, google, qualsiasi altra cosa) e cambialo lì il prima possibile.
Dal sito web,
Covert Redirect è un'applicazione che accetta un parametro e reindirizza un utente al valore del parametro SENZA la convalida SUFFICIENTE. Questo è spesso il risultato dell'eccesso di sicurezza di un sito Web nei suoi partner.
In altre parole, la vulnerabilità di Covert Redirect esiste perché non esiste una convalida sufficiente degli URL reindirizzati che appartengono al dominio dei partner.
Quindi immagina di aver eseguito una qualche forma di link di phishing che hai aperto. Diciamo che ho finto di essere la tua banca. In condizioni normali, dovrei creare un dominio falsificato per ingannarti. www.y0urb4nk.com e spero che abbiate fatto clic sul collegamento. Con l'attacco Covert Redirect, un utente malintenzionato sfrutta Oath / OpenID per utilizzare le informazioni della banca reale per estrarre il phish per me. Invece di usare y0urb4nk.com ora posso usare yourbank.com (il sito reale) per estrarre l'hack. Questo è il difetto spiegato.
Quindi in poche parole:
attacker [ exploit oauth/openid ]
generate phishing attack
send vulnerability to target
domain is legitimate attacker abuses this
user falls for exploit and enters data
now send this data to attacker instead of legit domain
game over
Difficoltà? A breve termine sarebbe di smettere di usare OpenID / Oauth fino a trovare una soluzione