[security] security hole in signature algorithm

[Martin Atkins]

Josh Hoyt wrote:
> On 11/19/06, Dick Hardt <dick at sxip.com> wrote:
>> By manipulating the return_to parameter, an attacked can impersonate
>> another user at an RP.
> 
> it's hard to do a careful reading of your message with mhy 2-year-old
> playing piano in the background, but I don't think I understand your
> attack.
> 

If I'm understanding correctly, this is an exploit of how many web 
frameworks parse a query string with duplicate keys:

     /blah/wibble?a=1&b=2&a=3

Most frameworks model the query string as an associative array, so we 
end up with one of:

{ a => "1\03", b => "2" } (Perl cgilib ReadParse & LiveJournal)
{ a => "1", b => "2" } (First occurrence wins)
{ a => "3", b => "2" } (Last occurrence wins)

Of these, I'd guess that the last is the most common, but given that we 
can't demand a particular framework to be used those which do "First 
occurrence wins" will be vulnerable to a hypothetical class of attacks 
where the arguments are duplicated in the return_to URL.

One approach to fix all such attacks would be to have IdPs strip out 
openid.whatever arguments in the return_to query string, though now 
we've given them the burden of parsing that URL where before they just 
had to stick stuff on the end of it.

Another alternative would be to mandate a particular algorithm for 
parsing the query string at the RP. This requires RPs to re-invent query 
string parsing in spite of their framework, but in some cases this 
probably isn't a bad thing. PHP in particular has a rather-broken 
implementation which turns dots into underscores as a hangover from when 
it automatically registered global variables for each argument; This 
means the openid arguments end up like "openid_return_to", which would 
actually bypass the "fix" outlined in my previous paragraph.