0

If I have a subdomain, and I set my cookie's scope to be / instead of examp.example.com. How can it be insecure?

Adi
  • 43,808
  • 16
  • 135
  • 167
Kratos
  • 291
  • 1
  • 4
  • 10

1 Answers1

0

You're talking about two different scoping properties. examp.example.com is a domain scope, and / is a path scope.

/ means that the cookie is valid for any URL path within the relevant domain scope. examp.example.com is that relevant domain scope.

To answer the question in your comment, yes, you want to specifically scope your cookies to your sub-domain to prevent them from being sent along with requests to other sub-domains, where they could be read by those who have no business reading them. So you do not want to scope cookies that are specifically for examp.example.com to .example.com, or rely on any cookies that are scoped to example.com.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • So by controlling the scope I can mitigate cross subdomain cookie attacks right? – Kratos Oct 30 '13 at 14:05
  • Yes. I believe the principle of an attack taking advantage of this is in finding an XSS vulnerability but not being able to intercept the cookies, so instead you use your XSS to have the cookie sent to another domain that you can intercept from (if the scope allows this). Therefore you should implement the strictest scope that allows the app to function. – deed02392 Oct 30 '13 at 14:15
  • So the path should be examp.example/ . The path determines the scope, isnt it.. Isnt there also a danger in grabbing the cookie of the subdomain in the sites main domain with XSS? – Kratos Oct 30 '13 at 14:21
  • No. The domain should be examp.example.com, and the path should be /, or something more restrictive, like /admin (If you only want the cookie to be sent to URLs containing examp.example.com/admin as the root path, for example.) – Xander Oct 30 '13 at 14:26
  • Another question. Why cant I see the domain attribute when I intercept requests say with fiddler – Kratos Oct 30 '13 at 15:19