Scenario peggiore OPEN URL REDIRECTION e perché google non lo copre in bug bounty

1

L'OPEN URL REDIRECTION secondo me può rivelarsi molto pericoloso creando attacchi come il phishing.

Ma sembra che Google lo consideri un bug di livello molto basso e non fornisce alcuna ricompensa monetaria per questo. Quindi la mia domanda arriva qui in gioco, quello che lo scenario peggiore può accadere con il reindirizzamento dell'URL aperto.

1> Can i run some system commands by webpage ?

2>If it found in any login page (because login pages mostly redirect after entering credentials) which is using HTTP not HTTPS, can the user sessions be hijacked or Can the credentials be stolen

3> Can the victims traffic be routed as desired (by acting as a proxy by malicious user or generally MITM) .

A mio parere, so che i possibili vettori di attacco sono

1> Victim can be tricked by phising ,

2> Root access by serving some browser exploits ,

3> Victim can be made a part of BOT network by opening a connection to some IRC.

    
posta user38257 22.09.2014 - 21:05
fonte

1 risposta

1

Sembri un po 'confuso riguardo al concetto. Un reindirizzamento aperto è solo un reindirizzamento. accedi a http://google.net/redirect?http://stackexchange.com e indica al browser: vai a http://stackexchange.com .

Il fatto che si tratti di un reindirizzamento aperto significa che posso inviarti ovunque (come una pagina web di un utente malintenzionato), solitamente incorporando nel link la pagina in cui ti verrà inviato.

1> Victim can be tricked by phising

Sì, è possibile che la vittima abbia visto un link a google.net e poi abbia pensato che stia visitando quel sito (e quindi inserisca ciecamente le sue credenziali di google), senza notare che l'url ora mostra evilattacker.com.

1> Can i run some system commands by webpage ?

Non considererei quanto sopra come running system commands . Tuttavia, potrebbe essere possibile utilizzare un reindirizzamento aperto per bypassare le protezioni della politica dell'origine stessa.

2>If it found in any login page (because login pages mostly redirect after entering credentials) which is using HTTP not HTTPS, can the user sessions be hijacked or Can the credentials be stolen

Per lo più no. A meno che il reindirizzamento non ritorni (cioè, quando ti rimanda all'URL controllato da un utente malintenzionato) viene aggiunto un token, o ci sono alcune informazioni nell'intestazione Referer (un token, il tuo nome utente ...), la pagina finale non lo fa ottenere alcun privilegio aggiuntivo dall'aver fatto il login, in quanto sarà gestito da cookie che non vengono inviati alla pagina di attacco.

2> Root access by serving some browser exploits ,

Questo non è corretto. Se il tuo obiettivo era quello di servire al browser un exploit, avresti potuto farlo direttamente. Ricorda che il primo passo è far sì che l'utente segua un url controllato da un aggressore. Il reindirizzamento aperto può aiutarti a ingannare l'utente (vedi 1), ma l'accesso root non può essere considerato una conseguenza di un reindirizzamento aperto.

3> Can the victims traffic be routed as desired (by acting as a proxy by malicious user or generally MITM) .

No. Il server non agisce come proxy (ottenendo il contenuto a tuo nome e trasmettendolo a te), proprio come un redirector: ti invia da qualche altra parte.

E in particolare:

3> Victim can be made a part of BOT network by opening a connection to some IRC.

Un reindirizzamento aperto non ti permette di connetterti ad irc, dato che il browser non sarà in grado di seguire un collegamento irc: // (se è in grado di gestirlo - più vince-, che si avvierebbe un'applicazione / plugin, non ti connettono automaticamente¹).

¹ E la connessione a irc non ti compromette automaticamente, comunque.

    
risposta data 22.09.2014 - 21:22
fonte

Leggi altre domande sui tag