(In reply to Alexis Solanas from comment #0)
> Description of problem:
> 
>  The http parameter "then" is not validated properly, and it's possible to
> perform URL redirections.
> 
> 
> Version-Release number of selected component (if applicable):
> 
>  Openshift 3.5.5.31
> 
> 
> How reproducible:
> 
>  Always
> 
> Steps to Reproduce:
> 
>   1.
> https://<ip-of-your-console>:8443/
> login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-
> console%26response_type%3Dtoken%26state%3DeyJ0aGVuIjoiLyIsIm5vbmNlIjoiMTQ5ODY
> 1NzA3MTkzOS0xNzcwMjYzOTMxNTk3NDk0NDI3OTQxODkxN
> <your-redirected-url>%252Fconsole%252Foauth
> 
> Actual results:
> 
>   The traffic can reach a different URL
> 
> 
> Expected results:
> 
>  The http parameters should be checked to avoid html injection
> vulnerabilities. 
>  A warning showing that the traffic is going to a different site, or forcing
> the user to accept that it's being redirected to a different site.
> 
> 
> Additional info:
> 
>  This request comes from an internal security audit performed by a customer

Is the token checked? E.g. can I only do HTTP URL redirection if I guess the correct token? Or can I blindly create a URL that when clicked redirects them? Please set a needinfo against kseifried when replying so I odn't lose this in my BZ spam.

> https://<ip-of-your-console>:8443/login?then=%2Foauth%2Fauthorize%3Fclient_id%3Dopenshift-web-
console%26response_type%3Dtoken%26state%3DeyJ0aGVuIjoiLyIsIm5vbmNlIjoiMTQ5ODY1NzA3MTkzOS0xNzcwMjYzOTMxNTk3NDk0NDI3OTQxODkxN
<your-redirected-url>%252Fconsole%252Foauth

This example URL does not result in a redirect to <your-redirected-url>

After login, control is returned to the OAuth server, which verifies the requested redirect against the allowed redirects for the specified OAuth client, and displays an error to the user unless a recognized redirect_uri is specified.

Please provide more details with the exact URL and redirect behavior that is being observed.

Just marking targeted 3.7.0 so it stays on the radar till we confirm what if any problem exists here.

Moving to auth since the reported URL is part of the OAuth flow, not the management console

The only way for an attacker to "exploit" this is to get a user to click on a malicious link that redirects them.  Of course, if an attacker can do that, they can just as easily get a user to click on a malicious link directly.  The data POSTed on the login form is never transmitted to the URL in the "then" parameter, thus no information is leaked.  Furthermore, there is no XSS vulnerability as we never render this parameter to the user.  Lastly, there is no way to trick the server side code into having a malicious "then" parameter.  Getting the user the click a malicious link is the only way to change it.

There is no real security issue here.  The login and OAuth pages are decoupled in the code (to "validate" the "then" parameter, they would need some awareness of each other), and we would prefer to keep it that way instead of trying to defend against an attack that cannot actually do anything.  Adding complexity to this area of the code is dangerous since we risk adding bugs to the login flow (which could easily end up being real security issues).

Changing the redirect_uri parameter invariably results in a parameter validation error (at least in 3.6/3.7).

Changing the then parameter may result in an internal attempt to reach the path (note, not the URI, then is strinctly interpreted as a path) specified as the anonymous user, which generally results in authorization errors or it may report discovery paths which are accessible as the anonymous user. In either case no information disclosure is possible, nor a redirect.

Alexis if you can provide an exact reproducer that contradicts this statement feel free to reopen.

Maybe open a new RFE bug