Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Goto URL with multiple query string parameters incorrectly decoded #5

Closed
ogis-miyamura opened this issue Jun 13, 2018 · 0 comments · Fixed by openam-jp/forgerock-ui#2
Milestone

Comments

@ogis-miyamura
Copy link
Contributor

ogis-miyamura commented Jun 13, 2018

Title

Goto URL with multiple query string parameters incorrectly decoded

Description

OpenAM needs to be able to redirect an unauthenticated user to a specific URL after they authenticate. This URL may contain multiple query string parameters, such as "http://www.google.com/?foo=bar&hello=world". This URL it is expected to be encoded and passed into the XUI as a URL like so:

/openam/XUI/#login/&goto=http%3A%2F%2Fwww.google.com%2F%3Ffoo%3Dbar%26hello%3Dworld

The REST endpoint "/openam/json/authenticate" also expects to receive this URL as an encoded parameter. This is used to start the authentication process, and the goto URL provided to the authentication process will be retained throughout the lifetime of the session that will be created.

The problem is that the encoded value passed into XUI is being decoded before it is passed to the authenticate endpoint. This is especially problematic when URLs contain multiple parameters, as it causes the URL-splitting logic to incorrectly parse the subsequent parameters of the goto URL as being additional parameters to the authenticate endpoint (unrelated to the goto URL). For example, the above would be passed in like so:

/openam/json/authenticate?goto=http://www.google.com/?foo=bar&hello=world

Thus, the value for the "goto" parameter would only be "http://www.google.com/?foo=bar", and there would be another (likely ignored) parameter "hello=world" treated separately.

The expected behavior is for the XUI to submit this goto URL encoded, like so:

/openam/json/authenticate?goto=http%3A%2F%2Fwww.google.com%2F%3Ffoo%3Dbar%26hello%3Dworld

This is especially troublesome for the OAuth flow. In that case, the "authorize" endpoint redirects unauthenticated users to the XUI login page, with a URL like so:

/openam/XUI/#login/&realm=%2F&goto=http%3A%2F%2Frich.example.com%3A8080%2Fopenam%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26scope%3Dopenid%2520profile%2520email%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A8443%252FoauthReturn.html%26state%3Dlogin%2526provider%253Dopenam%2526redirect_uri%253Dhttps%253A%252F%252Flocalhost%253A8443%252FoauthReturn.html%26client_id%3Dopenidm

However when the XUI loads, it submits the goto URL it was provided to the "authenticate" endpoint without retaining the encoding, so that the authenticate endpoint only sees a goto URL with a value like so:

http://rich.example.com:8080/openam/oauth2/authorize?response_type=code

The remaining, critically-important OAuth parameters are missing from the URL, so that when the authentication process completes the authorization endpoint is unable to process the request and the user can't return to their requested application (the RP) with the authorization code.

Steps to reproduce

Expected Results

In the address bar, query string parameters are restored to their original state.

Actual Results

The second and later query string parameters are lost in the address bar.
The redirect destination URL after 'goto=' is decoded.

Reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants