Re: [squid-users] URLs with backslash character using Firefox breaks Digest-Auth

On 07/10/11 06:35, Jan Sievers wrote:
> Hi Amos,
>
> On 2011-10-03 06:50, Amos Jeffries wrote:
>> On 27/09/11 06:19, Jan Sievers wrote:
>>> I noticed that trying to access a resource using URLs with backslash
>>> character ('\') using Firefox 6.0.2 breaks the HTTP-Digest
>>> authentication in Squid 3.1.15.
>>>
>>> Accessing the same resource using explicitly URL-escapes in the address
>>> bar (%5C) works.
>>>
>>> Accessing the same resource with Opera works, since it escapes every
>>> ('\') character itself.
>>>
>>> I guess it's more a Firefox bug, if it's not a content provider bug :-)
>>> ignoring RFCs. But I am wondering if I can do something about it in
>>> Squid?
>>>
>>> Or if Squid could respect different URL handling of different clients
>>> and build the digest hash the same way the browser does, meaning not to
>>> manipulate the uri provided in the Proxy-Authorization header again;
>>> here not to remove the backslash character?
>>
>> This sounds a lot like http://bugs.squid-cache.org/show_bug.cgi?id=3077
>
> Well, actually it's not exactly the same bug.
>
> In #3077 it was reported, that Squid ate more from a HTTP header because
> a quoted-string ended (legally) with a backslash character ('\'), like
>
>
> uri = "/?\"
>
>
> This is not really possible to parse, if you want to allow escaped
> quoted-pairs, like
>
>
> realm = "\"myserver\""
>
>
> But here I have the situation, that a backslash character is within a
> quoted-string and not at the end, like
>
>
> uri = "/Default.aspx?path=foo\bar"
>
>
> With Squid 3.1.15 and "debug_options 29,9" this will result in
>
>
> authDigestDecodeAuth: Found uri '/Default.aspx?path=foobar'
>
>
> And therefor it will calculate a different digest hash than the client.
>
> Mentioned commit #r10998 does not fix it for me.
>
> I did not manage to build Squid 3.2.0.12 here, but I don't see why it
> should not do the same, since HttpHeaderTools.cc:370 in function
> httpHeaderParseQuotedString says
>
>
> bool quoted = (*pos == '\\');
> if (quoted) {
> pos++;
>
>
> and later it never ever decreases "pos", so it jumps over every
> backslash character and never re-includes it in the string.
>
> Or am I missing something?
>

\b is the quoted-pair for character 'b'. While Squid is decoding a
quoted-string it is required to strip the \ and convert the char to its
\-escaped binary representation.

But see below...

>
> Beside that I am still unsure, if I could blame the content provider and
> probably also the client for using unescaped backslash characters in
> URIs (links in case of the content provider) and in a HTTP-Digest
> authentication header which both should respect RFC 2396 "URI Generic
> Syntax" which in my view does not allow such characters (e.g. in the
> query part)

RFC 2617 defines domain="" field as a token which happens to use ""
around one or more URI values. That going to our quoted-string processor
is a bug. The uri= field is supposed to be an exposed URI with
%-escaping, not have quotes around it. I understand that its quoted
because the URL commonly contains ',' bytes which are worse than these
rare quoting issues. But we should not be de-quoting it anyway.

I've added patches to bug 3077 which should fix all these cases at the
same time for the parser. Question is whether this makes Squid output
the unchanged original (good) or a quoted 'upgrade' of the value.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.15
   Beta testers wanted for 3.2.0.12