Given a cookie with the common attributes (name, id, etc), is there anyway we can identify if the cookie is a third-party cookie? By that we mean a cookie that has been placed by website B while visiting website A. At the moment, I can see no ways of achieving that but perhaps I've missed something. I'm working on a project related to user privacy online and would like to get a list of websites that left third-party cookies in user's browser. I use Mozilla Firefox Browser.
There's no way to tell when looking at the store of cookies. The issue is that a cookie is always first party with respect to some site; the third-party-ness relates to the provenance of the cookie. The only way to identify if a cookie was a third-party cookie is to examine the actual header which set the cookie and see if that cookie was set for a domain other than the originating one. Everything is made far more complex by the fact that a cookie can be set for a whole domain (thus foo.bar.com is allowed to set for .bar.com so that grill.bar.com will also see the cookie) and determining whether a suffix is a domain or not is not at all easy (e.g., some countries have multi-level domains).
The final problem is that it's easy enough for the site to request some resource from another domain for real, and set the cookie that way. That's formally not a third-party cookie, as it is being set by the domain it references, but it works in effectively the same way.
Every cookie is set for a domain. You can compare domain names to identify 3rd party cookies. But maybe I did not fully grasp your question.
Based merely on list of cookies created so far in the browser, there is no way to say if a cookie is a third-party cookie.
Related
I am setting the cookie from a local HTML file as below using cookie.js library
$.cookies.set("Demo","Dummy Data");
From another domain I am trying to get the cookie value using below code
alert($.cookies.get("Demo"));
But it is returning me null.
Please help me on this
This is by design. You can only get the value of a cookie which was set on the current domain.
What you are asking for is not possible due to the security measures built in to web browsers.
The best alternative is to make a JSONP AJAX request which can cross domains.
You can not read a cookie set by another domain.
Take a look at this thread about cross-domain cookies:
Cross domain cookies
Basically, this is a security feature. If domain.com set a cookies, domain1.com should not have any access to it, otherwise you could get authentication tokens and other stuff for any website.
Unfortunately, it is returning null because cookies from another domain are not accessible. This is a security feature.
Consider, for example, your session cookie for some website. If I could access that cookie via JS on another domain, then my malicious website (that I trick you into visiting), can then take that session information and give it to some hacker. Then it becomes much more likely that the hacker can hijack your session. All too commonly, there are not other measures in place to make sure that the session used is used by the same person, so all a blackhat needs is the ID and voila - total access as you to the website. Say you're logged into your bank on one window, and then have my hacked evil webiste open in the other... now I might be able to access your bank account. Whoops!
So - it's not possible, and for good reason!
Indeed, this is not possible because of SOP (Same Origin Policy).
You can solve this problem with cross domain methods like: postMessage, JSONP, xmlHttpRequest or iframe to name a few.
However, you have to be concerned about security issues. This podcast explain how to breack cross domain barrier. The posts below also have solutions for your problem.
Stackoverflow Posts
How do I set cookies from outside domains inside iframes in Safari?;
Resizing an iframe based on content;
I am implementing one advertising system in which when one user puts down script code into their website A. what I want to do at that time is set up a cookie into website A while it display response or resource of website B(Advertising System), so in present day when user comes again , I can log it's entry. I have read down this question and came to know that it is possible to set cookie into other website A when that website A is display content from another website B
In script I am executing one rest API and returning one response like below..
source_image = "http://example.com/media/format.png"
response = Response({'success':source_image})
response.set_cookie( 'cookie_name', 'cookie_value' )
return response
Now I am able to see cookie set in browser of the response of this url. But when I reload it ,cookie does not get display. Also why it is not getting display in the cookies section of the site in which I have put down script code.
Am I doing right thing to set up a cookie? And I have tried to set cookie's expiry date for 1 day. But still it is getting destroyed..Please help..
There are a few important things to know about cookies and browsers and how they interact across domains.
Websites can set cookies for their own website
Websites cannot set cookies for a different website
Cookies can be set on the response or using things such as JavaScript
The first two may seem confusing, especially when some sources say they are possible. It's important to note that they only affect cases where the response is directly setting the cookie using the Set-Cookie header, which allows a website to directly set a cookie. There are some special cases for things like subdomains, but in general you should not expect browsers to respect cookies set on other domains that you don't control.
If you were allowed to arbitrarily set cookies on other websites, this would open the door for websites to arbitrarily set and unset cookies you are using, even if they are unrelated. This would include the ability to log someone out across domains in just the response alone, which isn't possible.
The third point is important for cases like advertising, as cookies can be set using the Set-Cookie header (or response.set_cookie in Django) or using JavaScript through the document.cookie property. As JavaScript can included from any domain using the src property on <script> tags, any domain can manage cookies on another domain if it is included through JavaScript. This is important to how many analytics services, such as Google Analytics, work becuase it allows them to store unqiue cookies on each website for each user that is being monitored, even though they do not have full control over the response. They also typically use tracking beacons in the form of images to send data back to the external domain and associate it with the stored cookie.
The answer you linked to talks about this with images, but explains that it does not actually set the cookie on another domain. The cookie which is being set using the image or frame is stored only on the external domain, and cannot be accessed from the domain including the remote image.
Make sure that the HTTP header of "Set-Cookie" is being passed to the client in the HTTP response.
Try adding in the "domain" attribute for the cookie so the browser knows where to send the cookie.
I have read the OWASP information and also a range of articles including Jeff Atwood's Protecting Your Cookies article and I still feel I need to understand HttpOnly cookies better.
This came about because I needed to add some Google Adword tracking code to a site. This javascript needed to set and read a cookie on the website's domain and I assumed that this was an issue. The website is a .Net application with httpOnlyCookies="true" in the web.config, so I assumed that the best approach would be to replace the javascript and write the cookie from the backend to ensure that the generated cookie was HttpOnly. I could then easily read the cookie in the server-side too.
I understand that setting the HttpOnly of a cookie property largely prevents a cookie from being read and manipulated by the client. But what I don't understand is:
Given the example above, would there have been a problem with me using the javascript implementation?
Would it still have been ok to write the cookie using javascript (but still read it using the server-side)? I'm thinking not as the cookie is then not a HttpOnly cookie
If I have done the right thing (moving everything to a server-side implementation), why are Google Analytic cookies always implemented as non-HttpOnly cookies? Surely they pose a security issue too?
So as the title says, I guess what I'm asking is - when (if ever) is it appropriate to have non-HttpOnly cookies on your domain?
So this is much more straightforward than I assumed. According to the comments left by #mah above, flagging a cookie as HttpOnly is redundant when the cookie contains non-sensitive information.
The httpOnly option was response to JavaScript tricks to steal user's session cookie. It was because the session cookie is a temporary credential that allows you access to user's logged-in session on the server.
In case of any other, non-session cookies it really depends on your own risk assessment. If you're not really concerned about slightly increased exposure without httpOnly or you just have a business need to access their values from JavaScript, just ignore this option.
Some security scanners or incompetent pentesting teams will report missing httpOnly flags for each cookie just because it's trivial to spot and allows them to easily inflate their report. But explaining the actual purpose and origin of httpOnly should be sufficient to counter that.
On my previous websites, I used to use a cookie to display a pre-home page only on the first visit. That worked great (see for example here), but using cookies is not so trendy today, so I want to avoid it as much as possible.
Now, my new website projects almost always have pre-home launched via javascript (showing a modalbox), so I don't need to do any action on the server side. I'm considering to use HTML5 localStorage instead of cookies, with a fallback on cookies if the browser does not have localStorage. Is this a good idea? What is the impact in terms of usability, privacy protection and website performance?
Using localStorage will improve usability for users that have disabled cookies. But I know that some HTML5 features are only opt-in (like geolocalisation) in some browser. Is there any restriction like that for localStorage on any browser ? Is there any case where I will get a JS error if localStorage is available but deactivated for my site ?
Usability
The user will not know if you are using localStorage or a cookie. If a user disable cookies, localStorage will not work either.
Performance
There is no noticeable speed difference between the two methods.
sessionStorage
sessionStorage is only for that browser tab's session. If you close the tab, the session will be lost and the data will be lost too, it's similar to a session variable on any backend language.
localStorage
localStorage will be available for any tab or window in the browser, and will exist until it is deleted by the user or the program. Unlike a cookie, you cannot setup expiration. localStorage has a much larger storage limit as well.
Your Questions
You are not using this data server side, so you don't need a cookie. localStorage is never sent to the server unlike a cookie.
If the user disables the cookies, localStorage will not work either.
Fallback Example
You can use a Modernizr to verify if localStorage is available and if not, use store a cookie instead.
if (Modernizr.localstorage) {
// supports HTML5 Storage :D
} else {
// does not support HTML5 Storage :(
}
You can also forego Modernizr and use the check typeof Storage !== 'undefined'.
Comparing LS vs cookies is comparing apples to oranges.
Cookies and LS are completely different things for different purposes. LS is a tool that allows your client (javascript code) to store its data locally, without transmitting it to the server. Cookies is a tool for the client-server communication. The whole point of cookies is to be sent over with each request.
In the past cookies were often abused to emulate the local storage, just because it was the only possibility for a javascript application to write anything to the client's hard drive. But generally LS is not a replacement for cookies, so if you need something that both client and server should read and write, use cookies, not LS.
One point to add, unlike cookie normally shared cross protocol, the storages stick to same-origin policy. As a consequence sites share the same domain but hosted on different protocol do not share the stored data.
Say if your website need to work across http and https. For example, when user clicked the "purchase link" they will land on https secured checkout, then the checkout won't be able to retrieve the data previously stored on http site, even when they share the same domain.
It doesn't look easy for the server to read the localStorage. That may come in handy though, knowing your data is all client-side, making it safe from sniffing.
Cookies can't be written over, only added to and read:
alert(document.cookie);
document.cookie = "nope";
alert(document.cookie);
The one thing I didn't like about using 'localstorage' is that all your script code is visible when you 'inspect' (F12) the page. Go into SOURCES and from the left panel locate your website name and open it. All your code within the tags is totally visible. So if you've got some sensitive values on display, liked hashed passwords, special words, they all there for the world to see. I'm not sure what the world will do with this info, but it's not very secure.
I'm looking at using Amazon Cloudfront to distribute my JavaScript.
What I'm not clear on, however, is what happens to cookies if I do that. For example, if my site is example.com, and I'm including JavaScript from foo.cloudfront.net, does that JavaScript have access to cookies I set on example.com and visa versa? What's the best approach for cookie safety when you are serving your assets from another domain?
The javascript executes in the context of example.com, so no matter where it's served from will be able to access those cookies, and those cookies only. This encapsulation, which presumably is what you meant by cookie-safety, is enforced by the browser and shouldn't be something that you need worry about.
There might be third party cookies set in the distribution of the files (that depends on the distribution network, in this case Amazon's), although that won't be visible to the javascript, nor should it interest the javascript. If there are third party cookies set you should mention that in your privacy policy.
And to answer the question in the header; no, setting a cookie in code distributed from another domain does not count as third-party, since it executes under example.com, and will therefore only be able to set cookies under than domain.
Doesn't matter where the javascript code itself is hosted, what's important is the context in which it's running in - so the cookie will be correctly set to whatever host your main page is loading from...