[JIRA] Commented: (SDSJ-103) decoding of returnX query string parameter

[Rod Widdowson (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SDSJ-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918#comment-13918 ] 

Rod Widdowson commented on SDSJ-103:
------------------------------------

<Leaving resolved until the release vehicle is decided upon>

> decoding of returnX query string parameter
> ------------------------------------------
>
>                 Key: SDSJ-103
>                 URL: https://issues.shibboleth.net/jira/browse/SDSJ-103
>             Project: Shibboleth Discovery Service - Java
>          Issue Type: Bug
>      Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability ) 
>    Affects Versions: 1.1.3
>            Reporter: pbrusten at idp.protectnetwork.org
>            Assignee: Rod Widdowson
>             Fix For: 1.1.4, 1.2
>
>   Original Estimate: 0 minutes
>          Time Spent: 4 hours
>  Remaining Estimate: 0 minutes
>
> I have a situation where I pass the target parameter 'by value' instead
> of a cookie. (by omitting the relayState parameter in the SessionInitiator)
> The protected resource has several query string parameter, e.g.:
> https://sp.example.com/secure/index.php?key1=value1&key2=value2
> The SessionInitiator is set to go to our central discovery service,
> where the user will select his/her insitution. Next the user's browser
> is pointed to:
> GET
> https://ds.example.com/DS/WAYF?entityID=https%3A%2F%2Fsp.example.com&returnX=https%3A%2F%2Fsp.example.com%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dhttps%253A%252F%252Fsp.example.com%252Fsecure%252Findex.php%253Fkey1%253Dvalue1%2526key2%253Dvalue2%26forceAuthn%3Dfalse&returnIDParam=entityID&FedSelector=ALL&action=selection&origin=https%3A%2F%2Fidp.example.com&cache=session
> HTTP/1.1
> The returnX parameter is correctly URLencoded I believe, because the
> 'target' parameter is encoded twice, which seems good.
> But in response to the above request, the browser is redirected to:
> Location:
> https://sp.example.com/Shibboleth.sso/DS?SAMLDS=1&target=https://sp.example.com/secure/index.php?key1=value1&key2=value2&forceAuthn=false&entityID=https%3A%2F%2Fidp.example.com
> The target parameter is now *entirely* decoded and as a consequence the
> second query string parameter (and more if present) is passed to the
> first URL and isn't part of the target query string parameter anymore...
> I created a little test script which decodes the value of the returnX
> parameter:
> String URL =
> "https%3A%2F%2Fsp.example.com%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dhttps%253A%252F%252Fsp.example.com%252Fsecure%252Findex.php%253Fkey1%253Dvalue1%2526key2%253Dvalue2%26forceAuthn%3Dfalse";
>         try {
>             URL=URLDecoder.decode(URL, "UTF-8");
>         } catch (UnsupportedEncodingException e) {
>             e.printStackTrace();
>         }
>         System.out.println(URL);
> This results in:
> https://sp.example.com/Shibboleth.sso/DS?SAMLDS=1&target=https%3A%2F%2Fsp.example.com%2Fsecure%2Findex.php%3Fkey1%3Dvalue1%26key2%3Dvalue2&forceAuthn=false
> So I believe that for some reason the DS has decoded the returnX parameter twice instead of once.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira