Attualmente sto testando un'applicazione web, che sembra avere una vulnerabilità di reindirizzamento aperto, poiché ricevono un parametro redirect_url
tramite GET. L'applicazione reindirizza l'utente a questo URL in seguito.
Tuttavia, eseguono alcuni URL fissi che accettano e rispondono con 400
per qualsiasi altro URL.
L'URL previsto dall'applicazione è simile al seguente: https://subdomain.example.com/foo/bar
.
Ho cercato di restringere ciò che esattamente corrispondono. I seguenti tentativi fallirono tutti, poiché l'URL non fu accettato.
- Schema:
http://subdomain.example.com/foo/bar
- Sottodominio:
https://foobar.example.com/foo/bar
- Dominio:
https://subdomain.test.com/foo/bar
- Directory 1:
https://subdomain.example.com/bar/bar
- Directory 2:
https://subdomain.example.com/foo/foo
Inoltre ho cercato di ingannare l'applicazione con un nome utente nell'URI: https://[email protected]/foo/bar
Tutto sommato, sembra essere molto ben implementato.
Q: La mia domanda è, se ci sono altri approcci sull'esclusione del meccanismo di corrispondenza dell'URL, non ci ho pensato.
Modifica
Con i suggerimenti di @ Trickycm ho provato i seguenti approcci:
- Attraversamento directory:
https://subdomain.example.com/foo/bar/../../../../test
- Attraversamento directory:
https://subdomain.example.com/../../../../test/foo/bar
- Varie codifiche (ad es. URL), schema di modifica, sottodominio, dominio, directory con ciascun
- riempimento Null-Byte
- Iniezioni SQL
- URL di lunghezza estrema
- Vari set di caratteri URL (ad esempio cinese, russo, indiano)
- Varie combinazioni di quanto sopra
Nessuno dei quali ha avuto successo, questo sembra essere implementato in modo molto sicuro.