Home/ Questions/Q 276679
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T00:57:32+00:00

Note: This question has broadened in scope from previous revisions. I have tried to

  • 0

Note:

This question has broadened in scope from previous revisions. I have tried to simplify the issue so it can be easily reproduced by anyone.

Using Fiddler, I can replay an arbitrary request to my default page after erasing my Authorization header from the HTTP request, and I am able to get a response of 200 OK with valid data.

Bounty Update

Here are the steps to reproduce this exact behavior:

1. Create a "New Website" in ASP.NET, feel free to name it "InsecureWebsite"

2. Edit web.config to deny all unauthenticated users:

<authentication mode="Windows" />
  <authorization>
    <deny users="?"/>
  <allow users="*"/>
</authorization>

3. Publish the website to an arbitrary directory on a DEV server and create a virtual directory for the application

4. Ensure the application has script access (.ASP) and Integrated Windows Authentication enabled

5. Open Fiddler to capture the traffic

6. Load the page in your favorite browser and look at the "Inspectors" tab within Fiddler, you’ll see a request similar to:

GET /InsecureWebsite/ HTTP/1.1
Host: dev.subdomain.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: NTLM
{Base64-encoded authentication data}

The initial request to Default.aspx will return a 401 Unauthorized, will go into negotiation, and then finally return a 200 OK.

In Fiddler I can then erase the Authorization header directly from a replayed request to Default.aspx and still get a 200 OK. How is that possible?

Solution

It turns out that Fiddler uses the same underlying connection when making the requests, so once the connection is authenticated, any request on the same connection will also be authenticated as the same user as the initial request. You can turn this feature off in Fiddler here:

Screenshot of Fiddler options http://john.cognitivedelay.com/images/fiddler-options.gif

Once this has been unchecked, any replayed requests from within Fiddler will return a 401 Unauthorized as I would expect.

Thanks to all who offered their time to respond!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Edit: per updated question:

    Are you doing the replay in Fiddler itself, or by making a direct connection to the webserver? It might be that Fiddler is reusing an existing HTTP connection (which it can do, as a proxy)… I think IWA might mark the whole connnection as authenticated, not just the current request, which means that any future requests on the same connection re-use the authorization and authentication from the first negotiation…

    Original answer:
    Try 

    [WebMethod(EnableSession=true)]  
[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]

    and see if that helps?

    (Possibly [PrincipalPermission(SecurityAction.Demand, Role="myDevRole")] if that’s more appropriate for you…)

    • 0