How should I protect domain joined hosts in the same AD domain from the Related Domain Cookie Attack?

Suppose there is an AD forest called example.com. This company has a variety of internal and external web applications:

  • store.example.com (customer facing)
  • partnerPortal.example.com (internal/partner facing)
  • payroll.example.com (internally facing)

The forest also has workstations on the same domain workstation001.example.com ... etc.

Since this answer describes how easy it is to alter cookies, I think this is an opportunity for a confused deputy issue, where the authority granted is the DNS name granted to the computer.

Would it be a security risk to have end users and servers under the same shared domain? Keep in mind that most AD deployments fall into one of these configurations:

Forest/Domain Name     External DNS Name       Vulnerable to Related Domain Attack
Contoso.com            Contoso.com             Yes
AD.Contoso.com         Contoso.com             Yes                 
Contoso.Local          Contoso.com             No

What is the best way to mitigate this?

  • 1
    I cannot think of a single reason that payroll.example.com should be accessed outside of the network within an office. Its only asking for trouble. – Ramhound Mar 5 '12 at 13:09
  • @Ramhound - It is very easy to substitute "payroll" with "shopping" or any other site the business considers high value. – halfbit Mar 9 '12 at 14:37
  • Quite often payroll may be partially or fully outsourced so some type of sharing outside the network would be required. – Rory Alsop Mar 9 '12 at 15:14
  • @RoryAlsop To futher your point, more servers are being outsourced (Salesforce, etc), and the ability to inflict an attack is only getting larger and getting spread amongst more people/companies – halfbit Mar 9 '12 at 15:23

I don't think this has anything to do with Active Directory. It is a question about internal web applications.

Yes, I imagine there is some security benefit to placing the internal apps on totally separate domains. However, this may be annoying from a usability perspective (it may be more convenient for your users to have all the services under a single easy-to-remember domain name), and I'm not convinced that the usability hit is worth it, given that the security risks are probably modest. In terms of resistance to internal attacks, I suspect at most sites there will be other more effective ways to harden yourself against internal/insider attacks. But that's something you'll have to evaluate for yourself; it is a risk management exercise.

I don't know if there are better ways to mitigate the risk while maintaining the same domain name structure. There may be ways to implement the critical webapps (e.g., payroll.example.com) in a way that limits the impact of those kind of attacks, but I just don't know what ways those might be, alas. Sorry about that.

  • I don't see the risk limited to internal web applications. I updated the question to describe deployments where external web applications are vulnerable as well... – halfbit Mar 9 '12 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.