2

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?

Community
  • 1
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
  • 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 05 '12 at 13:09
  • @Ramhound - It is very easy to substitute "payroll" with "shopping" or any other site the business considers high value. – makerofthings7 Mar 09 '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 09 '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 – makerofthings7 Mar 09 '12 at 15:23

1 Answers1

1

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.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 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... – makerofthings7 Mar 09 '12 at 14:49