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.