bug bounty program they are running.
I have written about an XSS bug caused in this same parameter entitled "Moves OAuth XSS" and this will cover a not so common redirect_uri bypass method. & after the xss I, "...continue testing" (quoting GLaDOS from Portal)
Anyway, there are a lot of ways to bypass redirect_uri's in OAuth, it all depends on what server side check we are facing and what limitation factors there are. for instance, in Facebook's case, if you set your applications allowed callback to https://www.anyurl.com/directory it will allow that+ anything following it. so https://www.anyurl.com/directory/anotherdirectory?y=xz is considered perfectly valid. some other sites like Coinbase & Uber implement it differently. and addition of any queries, directories or domains will be considered invalid so scenarios that worked on Facebook will be invalid.
That leaves some OAuth clients heavily misconfigured and sometimes causes serious issues like OAuth bypasses possible.
However, there are sometimes confusions on the server handling these urls (often since dealing with url encoded values) and some bypasses are possible.
Consider a site that configured its allowed callback url to https://example.com/some/path.
Possible bypasses to tamper with sub-directories:
- https://example.com/some/path/%252e%252e/%252e%252e/new/path (double encoded)
- https://example.com/some/path/.%0a./.%0d./new/path (for servers ignoring nonprintable CRLF chracters)
PoC app: https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=2KQ3D5coba76A5eg42mlu3L3Kd3btEeS&scope=location&redirect_uri=https://example.com/new/path///../../some/path/ (obviously patched)
That application, although configured to redirect to https://example.com/some/path it will redirect to https://example.com/new/path