Is it possible that you disable setting cookies in javascript while stil being able to read them?
In my website i set cookies only in php, but it would be usefull that i can read them from Javascript.
I know there is a httpOnly flag while creating cookie but that restrict read and write access from Javascript.
The reason why i want to restrict write access is of course security as user can easily set cookie even from browser and i want to prevent that.
What you can do is create two cookies:
MY_COOKIE_HTTP_ONLY
MY_COOKIE
With the same values in the backend. One which is http only and the other which isn't. The MY_COOKIE_HTTP_ONLY cookie will be used in the backend and MY_COOKIE will be used in the browser. If attacker changes the value of MY_COOKIE in the browser side, well that basically is ok since if attacker has access to your browser, they can do all sorts of things but only in the browser side.
And on the other hand, you will be able to identify this situation by comparing the values.
Shortest answer: No. It's not possible.
you can prevetn the browser from setting javascript cookies by overriding the setter of document.cookie
document.__defineGetter__("cookie", document.__lookupGetter__("cookie") );
document.__defineSetter__("cookie", function() {} );
As others have stated, you can't stop users from editing files on their own computers, which is effectively what you would need to do to stop them from editing a cookie.
That doesn't mean you're out of options though. You could include an authentication code (like HMAC) in the cookie. The user will still be able to read and change that cookie, but at least you will be able to detect when they do and ignore the provided data.
Related
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.
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.
The way to delete cookies in javascript is to set the expiry date to be in the past. Now this doesn't actually delete the cookie, at least in Firefox. It just means the cookie will be deleted on browser close.
This is a problem for us: we have a product that involves archiving web pages from potentially many sites, with all this content stored on our server. And to make sure that pages render properly we include all js as well. However often cookies are set by js, and given that the page is cached on our server, these cookies are set under our domain.
So over time cookies from dozens of archived sites build up under our domain. And eventually the Cookie header exceeds the max content length, resulting in an HTTP 400 error code.
And because our clients are mostly in corporate environments they never reboot their machines or close their browsers: they can be left on for months. So this "soft" delete doesn't work, at least not reliably.
Is there any way to physically remove cookies intra-session in javscript? Or alternatively, is there any way to stop them being set?
It's not possible. Period. I've been struggling with this for several weeks without finding a solution.
Whoever invented the cookie getter/setter should be %insert_painful_punishment_here%.
Particularly Internet Exploder is a beast when it comes to deleting cookies. I can't remember the exact issue, but I think it involved https and cookie names containing ;.
All I can offer is a workaround: Send a response body with your 400 response, something like 'please restart your browser'.
In addition to setting the expiration in the past, set the value to an empty string. This will at least reduce the size of the cookie immediately.
I would think that cookies should be deleted immediately in all browsers. For example, when I log out of a website, Firefox does not require me to close my browser to delete the cookie that shows that I am logged into the site. If this isn't happening, I suggest you look into Firefox bugs and possibly open a new one with them.
In the meantime, I'd look at my web server and see if it is possibly to set the max content length to something higher than it already is.
You could overwrite the cookie with a new one.
"It is because we are NOT using iframes that we have this issue. The cached page is being rendered by our server, so any cookies get set under our domain." --OP
If you have no control over the javascript that is setting the cookies (which seems extremely odd, why do you not have control?), you can constantly read and empty the cookie, dumping the data to another larger database (preferably server-side, or perhaps HTML5 client storage).
Hello
A web site was developed and deployed to client. In some cases, I need to set the flag HttpCookie.HttpOnly = true. Okay - I have done it. Next question:
Is Cookie available after setting flag in JavaScript?
or maybe some restriction when I am using JavaScript?
or do I need to make some changes in existing JavaScript?
The purpose of using HttpOnly is to prevent Javascript from accessing the cookie, primarily to prevent XSS attacks. There are decent write-ups on CodingHorror and MSDN about it.
Bottom line: if you need access to the cookie with Javascript you can not use HttpOnly.