0

Cookies are set and stored as a name/domain/path to value attributes mapping, but only name-value pairs are presented to both JavaScript and web servers. This asymmetry allows cookies with the same name but different domain and/or path scopes to be written into browser; a subsequent reader can read out all same name cookies together, yet cannot distinguish them because the other attributes such as path are not presented in the reading process.

  • 3
    Integrity would only be at risk if you could write to a cookie you didn't own. You seem to be talking about reading cookies, which is a confidentiality issue. – schroeder Nov 1 '16 at 7:58
  • Do you have a source or example of this happening? When can a server read the cookies of another domain when they have the same cookie name? – schroeder Nov 1 '16 at 8:01
  • @schroeder Sort of integrity issue because in case original cookie is overwritten by another one and that new cookie is included when server calls, rather than the original one. – Muhammad Faraz Nov 1 '16 at 8:08
  • Ok, then you need to include that detail in your question, because you only make the case for reading cookies. – schroeder Nov 1 '16 at 8:18
  • 1
    What "subsequent readers" are you talking about? – Anders Nov 1 '16 at 8:18
1

The Same Origin Policy creates a security boundary for client-side data defined by protocol, port and domain.

The Same Origin Policy for cookies is slightly looser, allowing the protocol and port to differ, and the domain can optionally share cookies with subdomains. Note, as you say, this is optional for the cookie writer only, not the reader.

That is, foo.example.com can write a cookie that example.com can read, even if it doesn't want to.

The solution to this is to only have one application per domain. That way two applications cannot set cookies for each other.

e.g. Vulnerable

Application running on example.com/foo which can set set cookies for example.com/bar

Not Vulnerable

Application running on foo.example.com - this is completely isolated from bar.example.org

| improve this answer | |
0

This is not a problem.

Due to the Same Origin Policy, client scripts (e.g. JavaScript) should only be able to read and write cookies belonging to the current domain. So for the client script interacting with the cookie, there is only one cookie per name - it should not even be aware of cookies for other domains. Therefore it does not need to specify what domain it is reading cookies from - it is always the current one.

Requiring that to be specified would be like your car key asking you what car you want to unlock every time you press the unlock button - obviously it is your car, the only car the key can unlock.

In a similar fashion, when the browser sends a request to http://example.com it only includes cookies for example.com, and no cookies belonging to other domains even if they have the same name as example.com cookies. A browser doing anything else would be a major malfunction and a critical security issue, but to my knowledge no major browser vendor has so far messed up that badly.

I do not know what kind of "subsequent readers" you are talking about. Only the browser is supposed to read the cookies, and it is the responsibility of the browser to enforce the SOP.

(Subdomains makes this slightly more complicated, but I think that is beside the point of your question.)

| improve this answer | |
  • Just got a question while reading this post . If a server hosting multiple sites and I am accessing them via ip address how will the browser select which cookie is for which as site. ? – Arjun sharma Nov 1 '16 at 9:32
  • 1
    @8zero2.ops I think the IP address is counted as a separate origin, so if you serve example.com from 127.0.0.1 the browser will not send cookies stored for example.com if you type in 127.0.0.1. – Anders Nov 1 '16 at 9:34
  • No I mean how to distinguish cookies for a.a.a.a:80 and a.a.a.a:8080. If both are plain http sites .. I am browsing via my browser – Arjun sharma Nov 1 '16 at 9:48
  • 2
    @8zero2.ops Different ports mean different origin. Except for IE who does not always follow that, I think. – Anders Nov 1 '16 at 9:50
  • Ohk .. I will check it whether ports are accountable for storing different different cookies ..thank you – Arjun sharma Nov 1 '16 at 9:53

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.