Bug 1478744 - All HTTP parameters should be verified
Summary: All HTTP parameters should be verified
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.8.0
Assignee: Simo Sorce
QA Contact: Chuan Yu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-06 20:01 UTC by Alexis Solanas
Modified: 2018-09-19 14:12 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-06 22:09:48 UTC
Target Upstream Version:
asolanas: needinfo-


Attachments (Terms of Use)

Description Alexis Solanas 2017-08-06 20:01:51 UTC
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%3DeyJ0aGVuIjoiLyIsIm5vbmNlIjoiMTQ5ODY1NzA3MTkzOS0xNzcwMjYzOTMxNTk3NDk0NDI3OTQxODkxN
<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

Comment 1 Kurt Seifried 2017-08-30 15:22:09 UTC
(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@redhat.com when replying so I odn't lose this in my BZ spam.

Comment 2 Jordan Liggitt 2017-10-31 16:23:39 UTC
> 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.

Comment 3 Jessica Forrester 2017-10-31 20:09:20 UTC
Just marking targeted 3.7.0 so it stays on the radar till we confirm what if any problem exists here.

Comment 4 Jordan Liggitt 2017-11-02 14:24:51 UTC
Moving to auth since the reported URL is part of the OAuth flow, not the management console

Comment 5 Mo 2017-11-06 20:47:27 UTC
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).

Comment 6 Simo Sorce 2017-11-06 22:09:48 UTC
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.

Comment 8 Simo Sorce 2017-12-12 19:55:24 UTC
Maybe open a new RFE bug


Note You need to log in before you can comment on or make changes to this bug.