I have to uniquely identify computers that access my website. The only solution i found so far is storing an id in a cookie or something similar to identify the browser but my problem is that you could copy the cookies and use them in another browser. is there any way to detect if the cookie is copied or some better way to identify the computer?
There is no reliable way to uniquely identify a browser, because there is nothing that prevents two computers from having the exact same configurations (operation system, browser, location, cookies, flash configuration, etc).
The best that we can do is to gather as many information about the browser as possible. This is well-known approach called browser/device fingerprinting. Although the result is not perfect, it is quite good. Browser's fingerprint typically includes browser name, operating system, fonts, plugins installed, etc. You can test how unique your browser is using https://panopticlick.eff.org/.
PHP has an array called $_Server which is an associative array with information such as the visitors IP which can be used in conjunction with cookies. JavaScript also offers the "navigator" object which contains information about the browser. You can save that information to a cookie and if it doesn't match with the browser they use on the next visit, it would indicate they are not using the same browser.
Related
I am very confused as to how Safari ITP 2.3 works in certain respects, and why sites can’t easily circumvent it. I don’t understand under what circumstances limits are applied, what the exact limits are, to what they are applied, and for how long.
To clarify my question I broke it down into several cases. I will be referring to Apple’s official blog post about ITP 2.3 [1] which you can quote from, but feel free to link to any other authoritative or factually correct sources in your answer.
For third-party sites loaded in iframes:
Why can’t they just use localStorage to store the values of cookies, and send this data back and forth not as actual browser cookie headers 🍪, but as data in the body of the request or a header like Set-AuxCookie? Similarly, they can parse the response to updaye localStorage. What limits does ITP actually place on localStorage in third party iframes?
If the localStorage is frequently purged (see question 1), why can’t they simply use postMessage to tell a script on the enclosing website to store some information (perhaps encrypted) and then spit it back whenever it loads an iframe?
For sites that use link decoration
I still don’t understand what the limits on localStorage are in third party sites in iframes, which did NOT get classified as link decorator sites. But let’s say they are link decorator sites. According to [1] Apple only start limiting stuff further if there is a querystring or fragment. But can’t a website rather trivially store this information in the URL path before the querystring, ie /in/here without ?in=here … certainly large companies like Google can trivially choose to do that?
In the case a site has been labeled as a tracking site, does that mean all its non-cookie data is limited to 7 days? What about cookies set by the server, aren’t they exempted? So then simply make a request to your server to set the cookie instead of using Javascript. After all, the operator of the site is very likely to also have access to its HTTP server and app code.
For all sites
Why can’t a service like Google Analytics or Facebook’s widgets simply convince a site to additional add a CNAME to their DNS and get Google’s and Facebook’s servers under a subdomain like gmail.mysite.com or analytics.mysite.com ? And then boom, they can read and set cookies again, in some cases even on the top-level domain for website owners who don’t know better. Doesn’t this completely defeat the goals of Apple’s ITP, since Google and Facebook have now become a “second party” in some sense?
Here on StackOverflow, when we log out on iOS Safari the StackOverflow network is able to log out of multiple sites at once … how is that even accomplished if no one can track users across websites? I have heard it said that “second party cookies” still can be stored but what exactly makes a second party cookie different from a third party?
My question is broken down into 6 cases but the overall theme is, in each case: how does Apple’s latest ITP work in that case, and how does it actually block all cases of potentially malicious tracking (to the point where a well-funded company can’t just do the workarounds above) while at the same time allowing legitimate use cases?
[1] https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
I am not sure if the below answers are correct, please comment if they are not:
It seems applications can use localStorage with no problem, up to 7 days. But it won’t be persisted across multiple enclosing domains. I would even recommend using sessionStorage, since the goal is just to have nothing more than a seamless session. You can then roll your own cookie mechanism using a different set of headers, the only thing you can’t implement is http-only cookies.
They can, but ITP won’t let the JavaScript on the enclosing page store cookies (at least, not if your third party domain was flagged as a tracker by Safari).
Yeah, the description of “link decoration” technically doesn’t mention this workaround, but probably Apple has or will update its classifier to handle this workaround.
Yes, if a first-party webpage will send a request to the server and it sets a cookie in the response headers, then these aren’t blocked by ITP, even if it has an iframe to a tracking site. They say that’s not their goal.
Yes, in fact your first-party site can just let your site redirect to google.com and back quickly (like with oAuth) and thereby inform Google of whatever you wanted, without cookies. Google’s JavaScript can do this as well, if you allow it. Then the JavaScript can just load your google-hosted subdomain in an iframe and set a cookie that persists for years, tracking the user. However, ITP 2.3 seems to have also added mitigation to this, so you might use A records instead? https://cookiesaver.io/archives/analytics-guides/cname-cloaking-mitigation-eliminates-safari-itp-workarounds/
Probably the StackExchange network uses a version of #5
I was looking up alternative to cookies and I've read about HTML5 web storage here, and I've read a simpler explanation here but I still don't get how it works fully. Can someone offer a slightly non-techinical explanation so that I can then understand the technical bits. It says about browsers having to store key value pairs but where and how is it stored and why is it inaccessible to other sites? Why isn't it considered just an other form of cookies?
I'm looking for a thorough and complete alternative to cookies; as in if my organisation wants to replace all it's websites from using cookies to say an alternative for say web-storage then can we easily say 'Yes' to that requirement? Let's assume only the latest browsers are used.
How and in what ways does web-storage enhance security when
compared to cookies? Does it have potential to compromise security
in other ways? Is there someone with any real life experiences who
can share the pros and cons?
The differences between localStorage and cookies
Both cookies and localStorage are protected from access by unrelated domains by the Same Origin Policy.
The difference is that localStorage is only accessible through JavaScript, whilst cookies are accessible through JavaScript1 and sent with each HTTP request.
There isn't much of a security benefit of using localStorage as opposed to cookies. The difference between the two is because the goal is different: localStorage can be used for things you'll only use in JavaScript, whilst cookies can be used for storing things you need on the server (as well).
Both can be accessed by anyone that has access to the browser of a user's computer and both localStorage and cookies can be accessed by JavaScript that is executed on the web page. (For the latter, see the exception below.)
You can see this if you enter localStorage or document.cookie in the browser console.
You can set the HTTPOnly flag on a cookie so it isn't accessible through JavaScript.
How to use localStorage
Since there is already a lot of information available on using localStorage, I will just refer to two web sites documenting it:
DOM Storage at the Mozilla Developer Network
Local Storage at Dive Into HTML5
How the data is stored
How the data is stored differs per browser. Below, I give information on how Mozilla Firefox stores cookies and local storage.
Note: instructions on how to find your Firefox profile are available in this article at Mozilla Support.
Cookies
Firefox stores your cookies in your profile folder in a file named cookies.sqlite. This is a SQLite database. Opening the file using SQLiteStudio shows that the database contains one table, moz_cookies.
Table structure
The table is structured as follows:
Table contents
Here is a part of the contents of my cookies.sqlite database:
LocalStorage
Firefox stores your localStorage data in your profile folder in a file named webappsstore.sqlite. This is a SQLite database. Opening the file using SQLiteStudio shows that the database contains one table, webappsstore2.
Table structure
The table is structured as follows:
Structure of the column contents:
scope:
<the domain name in reverse>:<the protocol>:<the port number>
KEY:
The name name of the stored value.
value
The stored value
secure
This column isn't used.
owner
This column isn't used.
Table contents
Here is a part of the contents of my webappsstore.sqlite database:
This is the same as the data that I get when I type localStorage in the console at the web page https://login.persona.org.
Conclusion
As you can see, data from both cookies and local storage is stored by the browser in the same way. If you are concerned about the safety of data that is being stored at the user's computer, localStorage offers no security benefit over cookies.
In fact, it may even be a greater risk, because you can set cookies to expire after a certain time, whilst localStorage won't expire. Thus, data saved in localStorage may remain at the user's computer for longer than if you would have if you had used cookies.
(If, however, you only need to store data for the duration of a single session, you can use sessionStorage instead of localStorage.)
It sounds like you're looking at formulating a company-wide policy with respect to use of cookies in web application development.
As such, for a company-wide policy, be careful to consider not only your typical type webapp where server produces HTML+JavaScript, but also any potential web APIs that company web applications may be publishing. Such web APIs may be for AJAX purposes, but also may be for consumption by other type clients, for example B2B type data feeds, that may rely on some form of persistence on the consumer end. For example a "browser" like Twilio only understands TwiML, as opposed to HTML+JS, and local storage is not applicable there. And if webapp that interfaces with Twilio relies on persistent storage, local storage is not an option (whereas cookies are).
This is not to say that such applications, if such exist or will exist in your organization, cannot be (re-)designed to avoid need for client-side persistence. This is to say that local storage may not necessarily always be available in all contexts to provide alternative to cookies.
Otherwise, user2428118's answer nicely contrasts the two technologies.
I've just discovered Evercookie project on Github.
Evercookie is a Javascript API that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.
This is accomplished by storing the cookie data as many browser storage mechanisms as possible. If cookie data is removed from any of the storage mechanisms, evercookie aggressively re-creates it in each mechanism as long as one is still intact.
If the LSO mechanism is available, Evercookie may even propagate cookies between different browsers on the same client machine!
I tested it online, on this example page. I clicked "Create evercookie" button, I deleted all browsing data and I refreshed the page. The cookies that were deleted by deleting browsing data returned again there.
Where is the browser security in this thing? Is this secured?
If you want to disable Flash based cookies, use Adobe's "Global Storage Settings" panel here:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
Perform all of these Steps:
Uncheck "Allow 3rd Party Flash Content to store data on your computer"
Check "Never ask again" (a non-obvious, but important step)
Click the 2nd to last tab: "Website Storage Settings"
Delete all existing data
Chrome bundles its own Flash plugin on Windows and Mac OS X. The settings and disk storage are separate from the plugin packaged directly by Adobe, so you may need to perform the above steps twice if you use Chrome. On the plus side, the separate storage location prevents Flash from being used to synchronize cookies to or from Chrome and other browsers.
I recommend testing with my personal site:
http://noc.to
The "Zombie Cookie" section can show you exactly how cookies are being restored and help you determine if the above steps (or any tools you use) are working.
In order to create an Evercookie, all you need is:
The ability to run JavaScript (or other active content, like Flash and perhaps Java); and
The ability to access the various client-side locations where copies of the cookie data are stored.
Totally disabling access to all storage mechanisms would render most of them useless; for most of them, their whole reason for being is to allow a script to use them. So the only even remotely feasible option is restricting access by domain. I'm not sure what browsers (if any) allow that kind of granularity, though. Most can allow or block JS as a whole from certain domains, but as for what features a given domain's scripts can use...? I'm not seeing that ability in Chrome 26 or IE 10, at least.
Well, it doesn't seem to work that well.
Created the everCookie
Closed the window
Empty all elements of Firefox cache (just by going to delete recent history anc check everything except site preferences)
Closed the window
Came back to the page
Finally realized it wasn't stored
What is strange is that I dind't explicitely removed Flash cookies in Flash Website Storage Settings panel. Maybe it's integrated into Firefox. Or I may have disabled them.
I think there's several other ways to store cookies and trace you. Facebook is already tracking you all over the web, even when disconnected. Google too (do you use Chrome?). Moreover, with IPv4 addresses, we certainly can find you back (why not just after you've emptied your cache!). We also can find you back while logging back on any site, and make a link with your previous sessions.
I suggest:
Using Firefox, even it's slower than Chrome, it's still more respectful of privacy
Removing the whole Internet cache on window close (sorry you'll have to log again on your preferred sites)
Check third-party cookie options
Use browser addons with care
Check Flash & Silverlight cookie options
Avoid website reputation checking (provided that you can recognize a fishing attempt)
Use private browsing mode when you don't want to share your digital lives
I would like Akamai not to cache certain URLs if a specified cookie exist (i.e) If user logged in on specific pages. Is there anyway we can do with Akamai?
The good news, is that I have done exactly this in the past for the Top Gear site (www.topgear.com/uk). The logic goes that if a cookie is present (in this case "TGCACHEKEY") then the Akamai cache is to be bypassed for certain url paths. This basically turns off Akamai caching of html pages when logged in.
The bad news is that you require an Akamai consultant to make this change for you.
If this isn't an option for you, then Peter's suggestions are all good ones. I considered all of these before implementing the cookie based approach for Top Gear, but in the end none were feasible.
Remember also that Akamai strips cookies for cached resources by default. That may or may not effect you in your situation.
The Edge Server doesn't check for a cookie before it does the request to your origin server and I have never seen anything like that in any of their menus, conf screens or documentation.
However, there are a few ways I can think of that you can get the effect that I think you're looking for.
You can specify in the configuration settings for the respective digital property what path(s) or URL(s) you don't want it to cache. If you're talking about a logged on user, you might have a path that only they would get to or you could set up such a thing server side. E.g. for an online course you would have www.course.com/php.html that anybody could get to whereas you might use www.course.com/student/php-lesson-1.html for the actual logged on lessons content. Specifying that /student/* would not be cached would solve that.
If you are serving the same pages to both logged on and not-logged on users and can't do it that way, you could check server-side if they're logged on and if so add a cache-breaker to the links so when they follow a link a cache-breaker is automatically added. You could also do this client side if you want, but it would be more secure and faster to do it server-side. As a note on this, this could be userid-random#. That would keep it unique enough when combined with the page that nobody else would request it and get the earlier 'cache-broken' page.
If neither of the above are workable, there is one other way I can think of, which is a bit unconventional to say the least, but it would work. Create symbolically linked directory in your document root with another name so that you can apply the first option and exempt it from cacheing. Then you check if the guy is logged on and if so prepend the extra directory to the links. From akamai's point of view www.mysite.com/logged-on/page.html can be exempt from cache where www.mysite.com/content/page.html is cached. On your server if /logged-on/ symbolically links over to /content/ then you're all set.
When they login you could send them to a subdomain which is set up as a ServerAlias, so on your side it's the same, but on Akamai has differnt cache handling rules.
Following the same answer than #llevera, you can use the cookies on CloudFlare without intervention of engineers to make the change for you.
Having that sort of cookies to bypass content is a technique that its becoming more popular with the time, and even bug companies like Magento are using it for Magento 2 platform.
But solutions from above still valid, Maybe Akamai supports that that already now, we are in 2017!
A Note
I have a very good understanding of sessions and the theory of secure web-based authentication, etc., so please don't start with the basics, or give ambiguous answers. I am not looking for Best Practices, because I am aware of them. I am looking for the real risks behind them, that make the Best Practices what they are.
I have read, and agree with the principals that nothing more than a Session identifier should be stored in a Cookie at any given time.
The Story
However... I've inherited a rusty old app that stores the Username, Password, and an additional ID, in a Cookie, which is checked throughout the site as verification/authorization.
This site is always (can only be) accessed via HTTPS, and depending on your stance, is a "low-risk" website.
The application, in its current state, cannot be re-written in such a way as to handle Sessions - to properly implement such a thing would require, essentially, re-writing the entire application.
The Question
When suggesting to the-powers-that-be that storing their user's IDs/Passwords in plaintext, in a Cookie, is an extremely bad idea, what real risks are involved, considering the connection is always initiated and manipulated via HTTPS?
For example: is the only obvious way to compromise this information via Physical Access to the machine containing the Cookie? What other real risks exist?
HTTPS just protects against a man-in-the-middle attack by encrypting the data that goes across the wire. The information would still be in plain text on the client. So anything on the client's computer can go through that cookie information and extract the pertinent information.
Some other risks include cross-site scripting attacks which can enable cookie theft and who knows what kind of browser vulnerabilities which can enable cookie theft.
A given browser's "cookie jar" might not be stored securely, i.e., an attacker might be able to read it without physical access to the machine, over a LAN, or from a distributed filesystem (e.g., if the machine's storing user homes on a storage server, to allow for roaming), or via an application running on the machine.
Some browsers keep cookies in a file that can be displayed on the computer. IE6 comes to mind.
It seems to me that cookies are not all that restricted to a single site. Lots of advertising uses cookies across multiple sites. If I go to NextTag and look for a Nikon D700 camera then
I see NextTag advertisements on slashdot.org. This is an example of a cross-site cookie. Most users use the same password all over the web so if you store the password to one site and make it even a little easy to get to then malicious folks will sooner or later get to it.
To summarize this would be a very very very bad idea. On sites that I work on we don't save users passwords at all. We convert them to a hash key and save the hash key. That way we can validate the user but if we loose the content then there is no exposure of passwords. And this is on the server side, not the browser side!
Most cookies are limited time credentials. For example, session identifiers that expire after a couple hours or are forgotten when the browser windows. Even if the attacker gains access to the session cookie, they are guaranteed neither continued access to the account nor the ability to prevent the original account holder from logging in. Preventing long term account compromise is one of the reasons users are asked for their old password before being allowed to enter a new one.
A cookie containing a username and password, if disclosed, is much longer lived. Also, many users share their passwords between websites. As others have pointed out, the cookie could easily be disclosed via Cross-Site Scripting.
Finally, is the cookie marked with the "Secure" flag? If its not, an active network attack can easily force the browser to disclose it, even if HTTPS is used to serve the entire site.
People here already mentioned the "man in the middle" attack. The thing is that even with https it is still possible. There are different ways to do this - some of them relay on physical access to the network some of them do not.
The bottom line here is that even with https it is still possible for somebody to insert itself between your app and the browser. Everything will be passed through and will look from the browser exactly the same EXCEPT the server certificate. The intruder will have to send his own instead of the real one.
The browser will detect that there are problems with the certificate - usually it will either be issued to a different dns name or, more likely it will not be verified.
And here is the problem: how this violation is presented to the end user and how end user will react. In older versions of IE all indication of the problem was a small broken lock icon on the right side of the status bar - something which many people would not even notice.
How much risk this introduces depends on what is the environment and who (how trainable) the users are
Two two main vulnerabilities are cross site scripting attacks and someone accessing the user's machine.
Have you thought about just storing a password hash in the cookie instead of the raw password? It would require some coding changes but not nearly as many as swapping out your entire authentication system.