27

I was listening to Pandora as I logged in here, and the next commercial was about InfoSec. That set me wondering as to whether that was a coincidence (probably) or if they knew somehow. To make a long story short, I was wondering whether a webpage could access cookies that it didn't put there (thus getting a rather accurate browsing history as well as information on the user). It seems to me that this should be (and probably is) defended against, but if it is, how? I can read cookies on my computer and at least see where they came from, so it doesn't seem that they are encrypted...

38

Yep this is defended against using the same origin policy, which generally prevents one site reading anothers cookies.

When you see behaviour where adverts seem to know where you've been it's likely due to 3rd party ad tracking cookies.

So as a simplified example if you go to site A which uses an ad network, that ad network can record that you were on that site by placing a tracking cookie on your PC.

Then when you go to Site B which uses the same ad network, the ad network reads the cookie that was set when you were on Site A (which it can do 'cause it's loading content from it's domains in both cases so it doesn't break same origin) and can then offer you adverts based on your browsing habits.

  • Yeah, but I use AVG's Do Not Track plugin for Firefox, which prevents ad networks on a blacklist from accessing anything on your computer. Although I am using HTTPS everywhere, could that somehow be interfering? – KnightOfNi Jan 30 '14 at 20:19
  • 4
    Well I'm hypothesizing 'cause I've not used that plug-in, but the general problem with black-lists is that they won't catch 100% of ad networks as the URLs will change quite quickly.. – Rоry McCune Jan 30 '14 at 20:22
  • I think they use certs or something, as it blocks organizations in general, not URLs. Although I haven't really checked out exactly how it works, an overwhelming majority of the ads I now see are not relevant specifically to me, so I have to assume that whatever it does has worked thus far. – KnightOfNi Jan 30 '14 at 20:25
  • 1
    In this example, site A and site B are different companies, however because they use the same ad-network provider and this provider presumably has their own javascript scripts embedded in the page that set a cookie(s). Does that mean the cookie is set to the domain of that script's source and that's why each page can read it despite of same origin policy? – ErikAGriffin Oct 28 '17 at 4:53
  • "Can a webpage read another page's cookies?", "Yep..." – Levi Fuller Dec 20 '18 at 4:56
3

A properly designed browser will not allow a website to access another website's cookies, as this would violate the cross-domain policy and be a major security issue.

Unrelated websites can implement scripts which send information to a single ad tracking network, which can then serve up customized advertisements to these participating websites based on your reported activity.

Turning on "do not track" options aren't 100% reliable as "do not track" can only work if actively honored by the website receiving the "do not track" request. Cookies can be disabled or blocked, but there are still other simple ways ad networks can track your activity:

  • Pages on unrelated sites can display an image file which resides on the ad network server. When your browser requests the image file, it will send your IP address and referral URL (the page on which the image is displayed) to the ad network server. The image URL could be enhanced with information parameters (generated by the page server). Fortunately, an Ad Blocker could block such an image.
  • When your browser requests a web page, the page server could communicate directly with the ad network and share information such as your IP address and the content you requested. You can't block this form of tracking, but it can be potentially mitigated via the use of a VPN.
  • This is not really an answer to the question. The question is about cookies and you are talking about privacy violations through plain URLs. Yet, you're not far off of one way that allowed for cookie stealing during a period (early '00s I think): badly implemented iframes. Instead of an image you could load a different page inside an iframe, and, thanks to problems in browser design, you could talk to the JS of the page inside the iframe. – grochmal Sep 8 '16 at 1:16
  • I've updated my answer to better address the question. iframe exploitation should be resolved in current up-to-date browsers. – Aufgeschissener Kunde Sep 8 '16 at 1:27
1

There could be a timing side-channel here. Supposed if a user is signed in he get a huge bunch of info, but if he signed out he gets a small sign in form. The throughput of internet channel is finite so the times user downloads the same page can he differrent depending on the content. JS allows to measure the time it takes elements to be loaded so it can be possible to determine if a user is signed in in some foreign uncooperative website. I haven't tested this idea and haven't even googled, but I know that the attack against hsts told last year on some conference uses timing side-channel.

  • Could you revise your answer to explain this in a little more detail? – HashHazard Sep 8 '16 at 17:12
  • 1
    While timing side-channel attacks might be possible/problematic, they aren't related to whether or not one website can read another website's cookies, which is what this question is about. – dwanderson May 23 '18 at 21:06
  • Not fully relevant, but an interesting answer – Orun Jul 18 '18 at 16:33
0

You wrote:

I was wondering whether a webpage could access cookies that it didn't put there (thus getting a rather accurate browsing history as well as information on the user). It seems to me that this should be (and probably is) defended against, but if it is, how? I can read cookies on my computer and at least see where they came from, so it doesn't seem that they are encrypted...

You are correct, yes, you can read the cookies' contents, because it's your computer. But that doesn't mean that the browser will let any website read them. So, those are two different things. You may also have some personal files on your computer which YOU can read but a website can't.

You have an interesting question. Until now, I assumed that each web page has its own cookies. But that turns out to be false. The truth is each domain has its own cookies. At least that's how Firefox seems to work. So, if you have three pages on your website, they can access each others' cookies.

You can't accurately see a person's browsing history from cookies. Cookies usually store the domain, expiration date, settings, counters, and whatever the user may have entered into a form. So, those are the things you can find out from a cookie. The worst case of that would be let's say you enter your credit card number on one page. The JavaScript saves the number in a cookie (CARDNO=1234567890123456) and transfers you to another page on the same domain. Then that page reads the number and verifies it and sends you to the third page, which then submits the data to the server. Sounds crazy, but it's POSSIBLE. Looking at cookies, you won't know that the user visited all three pages. All you know is what's saved in the cookie, expiration date, and the origin. In this case, if the credit card number is saved in a cookie, then that's what's in the cookie. It may be encrypted or unencrypted, yes. Web pages from other domains should not be able to read the cookies, because as you can see, that would be a huge problem. Now, since you are the owner of your computer, you can access anything on your computer, so you get to see ALL cookies saved on your computer if you want to. And that's not a security issue as long as you are the only person using your computer. If your computer gets stolen or if you share a computer with someone, you can still read another person's documents and cookies and stuff if you have an administrator account.

Cookies provide about 5KB of space for each domain to save data. It may be a little more or less. If a website needs to save a lot more data, then there is a new thing called localStorage. It works the same way as cookies, but it allows a website to save megabytes of data instead of just a couple of kilobytes. Again, as with cookies, the values in localStorage are shared across web pages within the same domain. So, if one page sets a value, another page can read that value within the SAME domain.

See Also: https://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage

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.