This is going to a very short post about a redirect_uri bypass technique I found in Moves.

Moves is a company owned by Facebook and one of the acquisitions in scope for the 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.

Anyway, there are a lot of known 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:

1. https://example.com/some/path
2. https://example.com/some/path/../../new/path
3. https://example.com/some/path/%2e%2e/%2e%2e/new/path
4. https://example.com/some/path/%252e%252e/%252e%252e/new/path (double encoded)
5. https://example.com/new/path///../../some/path/
6. https://example.com/some/path/.%0a./.%0d./new/path (for servers ignoring nonprintable CRLF chracters)   

 In moves case, I used the 5th example. it basically confuses the parser and thus let it assume /new/path/ is the allowed subdir.

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 

Attack Scenario: