Bug 40138 – Authorization header is sent from an HTTP Auth protected site on redirect

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Tosh]

If I am on a Basic Auth protected website and click a link to download a file which sends the browser a 302 redirect to a new site hosting

[Tosh]

ARG!!  Hit ENTER at the wrong time...

If I am on a Basic Auth protected website and click a link to download a file which sends the browser a 302 redirect to a new site hosting the file to be downloaded, then the Authorization header is sent to the new site, like this:

mysite.com/protected/download?fileID=123

Returns a 302 redirect to:

newSite.com/notProtected/download?fileID=123

The above URL will be sent the Authorization header from the original site.

Normally this is probably not a problem, but some web services these days accept either the option of Authorization headers or URL tokens to access their resources, and when BOTH are sent this causes errors.

I would expect Authorization headers to be sent ONLY to sites the browser knows are requesting them.

I hope this was a coherent bug report.

[Alexey Proskuryakov]

Are you seeing this with nightly builds from <http://nightly.webkit.org>?

[Tosh]

(In reply to comment #2)
> Are you seeing this with nightly builds from <http://nightly.webkit.org>?

I can't even be certain it's a webKit bug as it only happens with Safari 4.0.5 on OSX 10.5+ and 10.6+.  On 10.4+ the above behaviour is not exhibited.

I've also reported the same bug to Apple in case that matters.

[Alexey Proskuryakov]

Can you please test this with a nightly build? Since there is no test case or example site for me to easily reproduce the problem, I'd like to know the results of your testing.

Nightly builds don't permanently replace anything in your OS or Safari installation, so there is no danger in testing them.

[Tosh]

Created attachment 62349 [details]
Screen shot of Webkit Nightly Build after 302 redirection from Basic Auth page to no AUTH page

Screen shot of Webkit Nightly Build after 302 redirection from Basic Auth page to no AUTH page.

You should note:
Referer:http://www.filistics.com/tosh/files.pl?projectID=30

The above URL is Basic AUTH protected.  It sets a 302 redirect to a resource on S3, with the AUTH info contained in the URL.

But you will also see in the headers:
Authorization:Basic dG9zaDp0b3No

S3 doesn't like having TWO AUTH possibilities since both methods could be valid, so it throws an error.

It seems WebKit it passing along the Basic Auth status when it shouldn't be.

[Tosh]

Damn that's kinda incoherent, let me know what I need to clarify, sorry.

Tosh

[Alexey Proskuryakov]

<rdar://problem/8225016>

[Brady Eidson]

Firefox seems to automatically send credentials if the redirect is to a page in the same security origin, but strips them if the page is not.  We should probably match.

[Brady Eidson]

Created attachment 76595 [details]
Patch v1

[Alexey Proskuryakov]

Comment on attachment 76595 [details]
Patch v1

View in context: https://bugs.webkit.org/attachment.cgi?id=76595&action=review

> WebCore/platform/network/cf/ResourceHandleCFNet.cpp:485
> +    if (!protocolHostAndPortAreEqual(request.url(), redirectResponse.url()))
> +        request.clearHTTPAuthorization();

So, we're preserving the authorization header in more cases than Firefox? This doesn't seem great, although I can't imagine a practical situation where this would be a problem.

> LayoutTests/http/tests/loading/authentication-sent-to-redirect-expected.txt:8
> +frame "<!--framePath //<!--frame0-->-->" - didReceiveServerRedirectForProvisionalLoadForFrame
> +frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame

Does this test need to dump these? All this logging is good for is making tests flaky.

[Brady Eidson]

(In reply to comment #10)
> (From update of attachment 76595 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=76595&action=review
> 
> > WebCore/platform/network/cf/ResourceHandleCFNet.cpp:485
> > +    if (!protocolHostAndPortAreEqual(request.url(), redirectResponse.url()))
> > +        request.clearHTTPAuthorization();
> 
> So, we're preserving the authorization header in more cases than Firefox? This doesn't seem great, although I can't imagine a practical situation where this would be a problem.

I *think* we're matching Firefox.

See my comment earlier:
"Firefox seems to automatically send credentials if the redirect is to a page in the same security origin, but strips them if the page is not."

This code matches that by stripping the auth headers only when the security origin of the two involved URLs differ.

> 
> > LayoutTests/http/tests/loading/authentication-sent-to-redirect-expected.txt:8
> > +frame "<!--framePath //<!--frame0-->-->" - didReceiveServerRedirectForProvisionalLoadForFrame
> > +frame "<!--framePath //<!--frame0-->-->" - didCommitLoadForFrame
> 
> Does this test need to dump these? All this logging is good for is making tests flaky.

It gets these simply by being an http/loading test.  You're right, they're not needed (though I don't forsee flakiness in this case), so I'll move them to a different directory.

Thanks for the review!

[Brady Eidson]

http://trac.webkit.org/changeset/74084

[WebKit Review Bot]

http://trac.webkit.org/changeset/74084 might have broken Qt Linux Release
The following tests are not passing:
http/tests/misc/authentication-sent-to-redirect.html

[Brady Eidson]

(In reply to comment #13)
> http://trac.webkit.org/changeset/74084 might have broken Qt Linux Release
> The following tests are not passing:
> http/tests/misc/authentication-sent-to-redirect.html

I don't see this failure on their bot anymore, but their bot isn't in great shape ATM.

It's quite possible Qt's networking had the same bug the Mac and Windows ports had, and they probably should fix it in the same manner.