[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=13747#comment-13747 ] 

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

There is a lot of implied encoding and decoding going on here and you have to be really sure about which particular API you are in front of or behind of in order to know what is needed, the fact that this .  By the time you get to double and triple encoding it can make you brain melt especially since encoding is not the strict inverse of decode (encode(decode('%')) != decode(encode('%'))), but that's all by the by.

I believe that I have located an extraneous decode, which escaped the usual case since the ':' that happens in the usual &target=cookie:wibble didn't get in the way of anything else.

This needs some serious testing, but I can make a patch available should you want to test locally.

> 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
>
> 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