Even if I enforce HTTPS and use anti-forgery tokens, it seems like Windows Authentication could be inherently insecure because it does not require that the user explicitly passes credentials from the client to the server.

In environments where folks are using older browsers that may not enforce CORS (and especially if these folks have disabled their browser's referrer header for whatever reason) - I'm not sure what would stop a malicious website from establishing a session on a user's behalf - the users don't even have to login!

The confusion, for me, all comes down to one point - the initial authentication:

  1. If I have a website hosted on some local domain - for simplicity let's just refer to it as abc.com (although for an intranet application it's probably just an IP address).
  2. A valid Active Directory user opens their browser and unwittingly goes to xyz.com (unwittingly because they don't know this is a malicious site setup by one of their former, but now laid-off and disgruntled co-workers)
  3. xyz.com makes a valid request to abc.com

Windows Authentication is admittedly somewhat of a black box to me - my assumption here is that the request to abc.com will be considered valid and the response will provide the session cookie needed for future requests. At this point, here are my questions:

  • Will the browser have a valid session cookie for further requests to abc.com or will the browser drop the session cookie because there are no active tabs/windows open for abc.com?
  • Even if the cookie is marked with HttpOnly, can't the attacker still access the cookie via TRACE or does the browser have a way to notify the server that the cookie should no longer be valid?

If the malicious website can be prevented from accessing/hijacking a cookie, I can see how it might be possible to reasonably secure an intranet website that uses Windows Authentication by enforcing that a user, who does not yet have an anti-forgery token, could enter the website by accessing a specific page (landing page) which would first make a request that would not return any protected data, but instead would return the valid session cookie and an anti-forgery token in a custom header of the response. All future calls would need to include the anti-forgery token provided by the previous request and failure to do so would require the user to enter through the landing page again. Since this anti-forgery token would be held in memory (by something like a request interceptor), it should not be accessible to javascript running on other domains (and assuming due diligence has been taken to prevent XSS attacks from accessing the token). A new token would be issued with each response from the server, the interceptor would grab it and then include it in the appropriate header on the next request from the client to the server.

Note that this is, of course, all assuming there's not some malicious program running outside of the browser.

  • I'm not sure your question - if you're using anti forgery tokens, won't this protect your intranet from CSRF? Commented Sep 23, 2015 at 14:45
  • The part I'm confused about is the initial exchange of credentials. I see somewhat how this works now via the Wikipedia link below, but I'm still unclear how the exactly the Kerberos protocol prevents requests across domains (assuming that Kerberos is used - it should be the case)
    – Jordan
    Commented Sep 23, 2015 at 15:34
  • If the anti forgery token is checked, this will prevent a CSRF attack. Commented Sep 23, 2015 at 15:39
  • But there is no anti-forgery token on the initial request
    – Jordan
    Commented Sep 23, 2015 at 15:40
  • 1
    It doesn't matter if it is returning sensitive data, the Same Origin Policy will prevent an external domain from reading it. You only have to worry about "unsafe" requests from being made (those that change data). Commented Sep 23, 2015 at 15:43

3 Answers 3


You initial request is likely to be a GET request, which if implemented as per standards will be a "safe method". That is, it doesn't make changes to any state.

Safe requests do not need to be protected because the Same Origin Policy prevents another origin (i.e. domain, protocol or port) from reading the response. Note that the request would still be made from the foreign domain, just that it has no way of reading the response in the request made through the user's browser.

Unsafe requests (which should be implemented as POSTs), should make use of a CSRF prevention method because even though the response can't be read in a cross-origin request, the requests is still made, and as it is "unsafe" it will have consequences (e.g. deleting an object that the user has permission to delete).

In this respect, "Windows Authentication" acts just the same as cookies in that it authenticates the user in their browser, but does not prevent cross-origin requests from making changes without some type of prevention mechanism (e.g. Synchronizer Token Pattern or X-Requested-With header to protect AJAX requests).


"Windows Authentication" is not an actual method of authentication. On a MS IIS server, when you implement Windows Authentication, you will then have to pick either "NTLM" (which is old, slow and rather insecure) or "Negotiate", where the server will try to authenticate you using Kerberos, and then fall back to NTLM if the conditions to use Kerberos are not met.

In Kerberos' case, I don't really think that relying on a KDC to authenticate the user is not a bad thing and would be less secure than having the Web server do the job.

I suggest you take a quick read on Wikipedia's Kerberos protocol page, so you can start with the right assumptions.

  • Yes I am making some big assumptions here :) just going on what I observed with fiddler.. I'll read up on it. Thanks!
    – Jordan
    Commented Sep 23, 2015 at 13:12

I think what I was missing is that the same origin policy is applied when the request comes back to the client and the browser won't let the client decrypt the response if the client hosting domain is not the same as the server domain - this then makes it clear why CSRF tokens are not necessary for requests that are idempotent.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .