I'm currently testing a web application, which appears to have an open redirect vulnerability, since they receive a parameter redirect_url via GET. The application redirects the user to this URL later on.
However, they do some fixed URLs they accept and respond with 400 for any other URL.
The URL the application expects looks like the following: https://subdomain.example.com/foo/bar.
I've tried to narrow down what exactly they are matching. The following attempts all failed, as the URL was not accepted.
- Scheme:
http://subdomain.example.com/foo/bar - Subdomain:
https://foobar.example.com/foo/bar - Domain:
https://subdomain.test.com/foo/bar - Directory 1:
https://subdomain.example.com/bar/bar - Directory 2:
https://subdomain.example.com/foo/foo
Furthermore I've tried to trick the application with a username in the URI: https://[email protected]/foo/bar
All in all, this seems to be very well implemented.
Q: My question is, if there are other approaches on bypassing the URL matching mechanism, I haven't thought of.
EDIT:
With @Trickycm's suggestions I've tried the following approaches:
- Directory traversal:
https://subdomain.example.com/foo/bar/../../../../test - Directory traversal:
https://subdomain.example.com/../../../../test/foo/bar - Various encodings (e.g. URL), altering scheme, subdomain, domain, directories with each
- Null-Byte padding
- SQL Injections
- Extreme length URLs
- Various character set URLs (e.g. Chinese, Russian, Indian)
- Various combinations of the above
None of which were successful, this seems to be implemented in a very secure manner.
