On every website I visit I get a pop up that it use cookies and accept their cookie policy.
While in modern browsers we have localStorage, sessionStorage, indexDB and other that I might not be aware of.
So what are the specific reasons to use it while there are a number of reasons which leads to security threats due to use of cookies.
Because cookies can be used in (for example) PHP, while the localStorage and so on is only usable within the client environment.
So the new technologies are fine within any client-based application, but are not very useable in PHP or any server sided application.
Related
Given a third-party webpage www.somepage.com handing out specific URLs to subscribed websites in the format of www.somepage.com/site/3ir3jsd - how can I track that a user having an account on www.somepage.com has visited one of the subscribed websites without resorting to cookies / localStorage ?
A standard approach would be to store a cookie for www.somepage.com and add www.somepage.com/site/3ir3jsd via an IFrame. This has several issues as new laws and browser defaults prohibit third-party cookies and local storage to be loaded.
Is there some other mean to achieve this? I see that this is a potential privacy issue and would of course ask for permission to do this and would prefer secure / non-privacy-infringing methods. All major browsers have to be supported which rules out browser extensions too (looking at you Internet Explorer 9-11). Maybe JavaScript? But I don't want the user to have to "login" to my pages service on every subscribed webpage. Storing their session cookie in the first-parties localStorage / cookie is a potential security risk though (which would be needed when using JavaScript + storing their session data).
Another approach I have checked is client certificates but they are poorly supported (read: often unsupported) by mobile browsers and the use-ability of adding them is horribly in most of them too.
How do login sessions work while on Tor, since Tor browser disables cookies? Always has confused me how the site can differentiate users.
I know there are additional ways other than cookies, but still none the wiser how they work while on Tor.
Actually Tor Browser forces cookies to be discarded at the end of the browsing session. Cookies are small pieces of data that websites use to keep notes on who you are. They are commonly used as a login token, or as an identifier for adveritsment companies to track you across multiple sites. By discarding all cookies when you start a new browsing session, these cannot be used to track you across sites.Tor Browser disables the Flash plugin, which has its own form of persistent storage. As Flash applets auto-load on most systems, this again prevents a method of tracking you across sessions.A similar story applies for HTML5 storage capability. Websites can store data on your machine with the use of HTML5. This data can be much larger and more varied than cookies, and is technically distinct; but the risks in terms of being used as a tracking mechanism are the same.
The first part answers the question: "Actually Tor Browser forces cookies to be discarded at the end of the browsing session." So cookies are used like any normal website until you finish the session, then they are deleted.
Actually Tor Browser forces cookies to be discarded at the end of the browsing session. Cookies are small pieces of data that websites use to keep notes on who you are. They are commonly used as a login token, or as an identifier for adveritsment companies to track you across multiple sites. By discarding all cookies when you start a new browsing session, these cannot be used to track you across sites.Tor Browser disables the Flash plugin, which has its own form of persistent storage. As Flash applets auto-load on most systems, this again prevents a method of tracking you across sessions.A similar story applies for HTML5 storage capability. Websites can store data on your machine with the use of HTML5. This data can be much larger and more varied than cookies, and is technically distinct; but the risks in terms of being used as a tracking mechanism are the same.
Facebook has done great work on preventing eavesdropping (with tools like Firesheep) by supporting https on all facebook.com pages, but does not provide similar levels of security for 3rd party sites.
Right now it's possible to eavesdrop the traffic from a 3rd party website which is using the Facebook JS SDK and get a user's signed fbsr_APP_ID cookie which a website should use to authenticate their users.
Is there a way to set this cookie with the secure parameter so that it's only transmitted over HTTPS connections?
I have read both the documentation and the JavaScript SDK source code and it doesn't seem possible. So if it's not possible, which other authentication method would you suggest to avoid eavesdropping of this cookie?
I think I'm too late for the bounty, but I'll happily take the "accepted answer" :)
As noted in the remark, on FB.init you specify, whether you want the facebook JS SDK to set cookies for you with the cookies option, it even looks like by default no cookies are set: https://developers.facebook.com/docs/reference/javascript/FB.init/
Then afterwards use your own javascript to store the fbsr_APP_ID any way you want (secure cookie, client side storage, etc).
I several classic ASP websites that use session state for maintaining login state and user preferences. The code doesnt read or write to any cookies, it just uses "session" variables which rely on the default ASPSESSION cookie SET by IIS.
As no data is actually written / read to the cookie in ASP code (only IIS reading the cookie and linking the user to a session ID) - I would interpret this usage of cookies as having no privacy impact / being "privacy neutral", so I would not need to inform the user of the use of cookies.
Link to ICO Guidlines
You should analyse which cookies are strictly necessary and might not need consent.
and more:
It might be useful to think of this in terms of a sliding scale, with privacy neutral cookies at one end of the scale and more intrusive uses of the technology at the other.
However, I am not a lawyer.
So, I guess I am asking:
1) Is your interpretation of this usage of cookies in agreement with my view that these are "Privacy Netural" cookies, and wont require consent?
2) What situation have you faced with your use of cookies, and what changes you made to comply? (eg, popups, expaned T&C's etc)
3) Any other thoughts?
Thanks again,
Williard
Will this idea work? It seems pretty stupid, because my app is simply checking that the browser sent two copies of the same information (ie the session key).
Also, remembering to make this check sounds very tedious. Do web frameworks such as Rails and CakePHP have things that make it easier to write XSRF-proof web apps?
Assuming that the session key is not leaked (which could happen if your PHP is poorly configured and uses session.use_trans_sid) and you are not vulnerable to session fixation attacks, yes, this is secure. This is because a request forger cannot read your cookies, and thus does not know what the correct value is.
You may be interested in CSRF Magic, which claims to allow you to protect your application by including a single file.