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:
- 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).
- 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)
- 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?
Note that this is, of course, all assuming there's not some malicious program running outside of the browser.