Perché un URL di callback sottodominio con caratteri jolly in OAuth è considerato non sicuro?

Question

Perché un URL di callback sottodominio con caratteri jolly in OAuth è considerato non sicuro?

#1 da (2 voti)
#2 da (1 voti)

2

In questo post: link

Enter your full callback URL(s) in this field. This means you should be providing the entire path, such as https://mysite.com/oauth/callback. Do not use wildcards, and do not use only the domain.

Il post dice che i caratteri jolly non sono sicuri.

Successivamente, il post offre un esempio che mostra solo una vulnerabilità di un URL di callback arbitrario .

Mi chiedo perché un callback come https://*.mysite.com/oauth/callback non sia sicuro. Sembra che nessuno dei provider OAuth lo supporti (ad esempio Google e Facebook).

Grazie.

oauth2

posta Tanin 26.02.2018 - 01:10

fonte

2 risposte

Leggi altre domande sui tag oauth2

Passaggio della stringa di query in un'API stripe Problema con metasploit RHOST LHOST

score 2 · Answer 1

Ci sono altri motivi per cui questo non è sicuro:

OAuth può essere reindirizzato a qualsiasi sottodominio con un token di perdita di segnale jolly e così via Esempio: se hai solo un sottodominio e non possiedi l'intero carattere jolly, l'utente malintenzionato può registrare altri sottodomini e creare un attacco di phishing davvero valido come la pagina di accesso o pubblicare pagine Web dannose
Ogni token emesso in questo modo sarà di origine incrociata con caratteri jolly (non so quante app hai sotto questo carattere jolly)
Se hai ssl solo per alcuni caratteri jolly utente sottodominio, l'attacco MitM è facile in quanto posso reindirizzare a un tuo servizio web non HTTPS e ottenere token e login come quell'utente
A seconda dell'implementazione dei provider OAuths e del tuo se hai SSL per * .example.com, l'utente malintenzionato può comunque utilizzare . .example.com in MitM attaccare l'utente finale mentre il DNS prende questo ma il. Certo se OAuth non convalida se sottodominio del sottodominio

Domanda correlata: Qualcuno può spiega la vulnerabilità "Covert Redirect" in OAuth e OpenID?

score 1 · Answer 2

La prima cosa che viene in mente è che gli attacchi da subdomain takeover diventano più potenti. Ciò può anche consentire, ad esempio, che il software di helpdesk ospitato su support.example.com generi token oauth validi per admin.example.com per l'escalation dei privilegi.

E, per i bonus, ci sono persone in esecuzione su hosting provider che danno un sottodominio gratis. Quindi, se riesco a generare un token oauth da uno, posso ottenere un token valido per chiunque altro.