2 edited title
| link

Is Need help understanding Windows Authentication Inherently Insecure?mechanism

source | link

Is Windows Authentication Inherently Insecure?

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.