Authorization header and redirects

4 posts, 0 answers
  1. Franz
    Franz avatar
    5 posts
    Member since:
    Aug 2011

    Posted 16 Sep 2015 Link to this post

    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.

  2. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 16 Sep 2015 Link to this post

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  3. Franz
    Franz avatar
    5 posts
    Member since:
    Aug 2011

    Posted 16 Sep 2015 Link to this post

    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.
  4. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 16 Sep 2015 Link to this post

    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
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top