Centralized Discovery Service and URL decoding

[Cantor, Scott]

On 10/25/13, 9:51 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>We¹re having a problem with the Shib Centralized DS and doubly-encoded
>URLs. A string that we¹re encoding twice because it¹s supposed to still
>be URL-encoded when it gets back to the SP seems to be decoded.

When you invoke a DS, there should never be anything doubly encoded unless
there's a parameter attached to a URL that is itself a DS parameter.

The return location is NOT doubly encoded, it's encoded once. If it
contains a parameter itself, then that gets encoded first before it's ever
attached to the URL that is itself eventually encoded as a parameter to
the DS.

You never doubly-encode a particular parameter. You only encode parameters
in a nested fashion, inside out. Part of a parameter may be doubly encoded
by the end but never twice by itself.

> 
>Box, in the beta of their new sync service, has the need to include a
>parameter as part of the return URL that is, itself, another URL. They
>want that parameter value to remain URL-encoded when it gets back to them.

That's fine but they should be the ones sending the parameter in the first
place, so if it's wrong, they must have failed to encode it properly to
start with when they included it. They basically attached an unencoded
parameter to the return parameter itself, and that ends up decoded for use
as a redirect back and then fails. That's a standard "failure to encode a
parameter" bug.

> 
>Of course, the DS also expects the return URL to be URL-encoded.

Yes, and whatever state it's in, it gets decoded (once) and then used as
the location to redirect back to (with additional parameters attached to
signal back the IdP).

> So, the smart folks at Box decided they¹d just encode the parameter,
>then encode the whole return URL string. End result: the parameter is now
>doubly encoded.

I don't think that's what they did, but you didn't post a complete trace.

> 
>Funny thing is that, by the time the return URL gets back to Box, even
>the parameter seems to be completely decodedŠ as if the DS id decoding
>twice.

I don't think that's possible.

>Is the DS doing some logic after it decodes the return URL to see if it
>still seems to have further decoding in it and, if it does, looping
>through again? Or do we need to look beyond the DS to find the source of
>this craziness?

I think they probably failed to encode the URL they included as a
parameter to their own, nothing very unusual.

-- Scott