Authorization header and redirects

[Franz]

I hope this is the right place, i haven't found a place to create a support ticket for fiddler...

I am having a problem with Fiddler following a 307 redirect to an URL that needs authentication. Specifically, I let Fiddler issue an OPTIONS request to https://myserver/foo. The server needs authentication, so a challenge and response is performed and Fiddler repeats the intial request with an Authorization header. So far so good. Now the server actually cares for Fiddler's request for the first time and responds with a 307 status code, redirecting to https://myserver/foo/ (note the trailing slash). Fiddler now repeats the last request for the new URL, but with the Authorization header not being stripped.

The problems with this are twofold:

1.  The Location header of the 307 response might point to an untrusted location. Now Fiddler sends trusted data inside the Authorization header to a potentially hostile location.
2. Some webservice implementations such as WCF (and according to https://github.com/request/request/issues/450 also Amazon S3) create a "400-Bad Request" error when presented with an unexpected Authorization header (i'm guessing this is the case when no challenge and response preceded).
   
   

Let me show you an example. The following 4 requests comprise:

• The initial anonymous request (response being 401 Unauthorized with WWW-Authenticate: NTLM)
• The initiation of the handshake (response being the challenge for the client)
• Answer to the server's challenge with Authorization header (reponse being the 307 redirect to the new URL)
• Request to the new URL, IMHO erroneously still with the Authorization header from the last request.

Initial anonymous request:
OPTIONS https://myserver/foo HTTP/1.1
User-Agent: Fiddler
Content-Length: 0

Response:
HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: NTLM



Initiation of the handshake:
OPTIONS https://myserver/foo HTTP/1.1
User-Agent: Fiddler
Content-Length: 0
Authorization: NTLM (...)

Response:
HTTP/1.1 401 Unauthorized
Content-Length: 0
WWW-Authenticate: NTLM (...)



Answer to the server's challenge:
OPTIONS https://myserver/foo HTTP/1.1
User-Agent: Fiddler
Content-Length: 0
Authorization: NTLM (...)

Response:
HTTP/1.1 307 Temporary Redirect
Content-Length: 0
Location: https://myserver/foo/



Request to the new URL:
​OPTIONS https://myserver/foo/ HTTP/1.1
User-Agent: Fiddler
Content-Length: 0
Authorization: NTLM (...)

Response:
HTTP/1.1 400 Bad Request
Content-Length: 0


When i repeat the last request without the Authorization header, everything works fine, i.e. challenge and response are repeated and ultimately, the desired 204 response with the Allow header is returned.

In my opinion, Fiddler should never retain an Authorization header following a redirect! Since to my knowledge there is no definite rule that flat out fordbids that behaviour, calling this a bug might be exaggerated. But in order to play nicely with various web services and also with security in consideration, i think this issue should be addressed.

Thank you.

[Eric Lawrence]

Hello, Franz--

Thanks for writing. Can  you be specific about what you mean when you say "I let Fiddler issue an OPTIONS request"?

Thanks again,
Eric Lawrence
Telerik

[Franz]

By "I let Fiddler issue an OPTIONS request" I meant that I issued a request with the HTTP Verb OPTIONS (instead of e.g. POST), to the aforementioned URL, with the request Composer.

[Eric Lawrence]

Ah, thanks for clarifying. Yes, the Composer has the option to "Follow Redirects" and, when enabled, Fiddler doesn't currently do a very good job of cleaning up the request headers for the subsequent request.

There's a tradeoff here (because Fiddler doesn't maintain its own cookie jar, and because there are scenarios where the Composer user may wish for a OAUTH bearer token to apply to the post-redirection request) but I agree that these headers should be stripped by default.

This fix will be in the next build.

Thanks for reporting!

Eric Lawrence
Telerik