At the moment I'm using Modernizr to detect if the client is blocking cookies and provide warnings if it's going to prevent them doing something i.e login or add to cart.
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/cookies.js
However I've found that if you use the Advanced privacy settings to block cookies this is not detected so the user doesn't get any warning and the site will appear to be broken.
I can't seem to find anything that suggests any way around this.
The Modernizr test is a purely client-side test. If IE's settings fool that test, it seems like you'll need to set a cookie in your main response, then do an ajax call and see if the cookie went back to the server. If it did, cookies aren't blocked; if it didn't, they are.
This also has the advantage that it's an end-to-end test: It doesn't matter where the cookie was blocked (the browser, a proxy, etc.), it'll tell you whether cookies currently work for that user in that environment with your site.
Related
A user of me extension recently reported that when he blocked 3rd party cookies, it killed our extension as well. I've traced the issue down to localStorage being inaccessible. I have "storage" and "unlimitedStorage" set in the manifest.json permissions. I am looking into switching to chrome.storage.local, but because it's async, I need to rework a fair bit of code.
Does anyone have an easy workaround?
Just thought of a workaround while typing this up and tested it:
setting an Cookie Exception of chrome-exception://* Allow lets my extension access localStorage.
Not perfect, but it'll do for now.
We have a file sharing service, http://ge.tt, and a few extensions for Chrome. One of them which adds extra capabilities to Gmail.
In this extension we ask users to login to Ge.tt before they are able to use the extension. Since they are already logged in on Ge.tt it would be great that they didn't have to log in again, and it causes some users to misunderstand how it works.
What would be a good way to go around and tackle this problem? Does others have the same issue?
For example Grammarly extension can detect if you are logged in to the grammarly site
They are using this permission (and actually it is enabled on ALL sites, they can read even httpOnly cookies on any site)
N.B. don't know why they are listening for cookies, they could (as pointed by #alex-k ) just make a request to api.grammarly.com/is-authenticated
because I see they don't use same-site=strict or lax
this is a screenshot after I logged out and extension made request to log some action on their site, server set anonymous cookie to my browser
You can simply make an HTTP request from the extension to the user-only page to see if they are logged in. Something like ge.tt/my-profile-ping which returns 1 if user is logged in, 0 otherwise.
Extensions share the same cookies the browser does, so you just need to test if they are logged in and continue displaying logged-in-only data in your extension.
Also, don't forget to enable requests in your extension manifest for domain ge.tt, and www.ge.tt, and probably the https version also (if you haven't already)
Something like this in your manifest.json:
...
"permissions": [ "http://ge.tt/*", "https://ge.tt/*", "http://www.ge.tt/*", "https://www.ge.tt/*" ]
...
I'm trying to store a value on another domain using an iframe (actually, I'm using the xauth library at http://xauth.org/info/). However, when I try to store anything using Chrome, it comes back with "QUOTA_EXCEEDED_ERR: DOM Exception 22", which I've come to recognize as an access error. I've mocked up a couple of very simple pages below to duplicate the effect:
File 1.html:
<html>
<head/>
<iframe src='http://127.0.0.1/2.html' />
</html>
File 2.html:
<html>
<head/>
<script>
console.log(localStorage);
localStorage.setItem('test', '123');
</script>
</html>
If I place both of these on my local server and access localhost/1.html it embeds a frame from 127.0.0.1 (which Chrome considers a separate domain), and I get the same access error as above. At a guess, it looks like even though I'm embedding an iframe from another domain, and the script inside that iframe references the localStorage for that domain properly (as I can see with the console.log(localStorage) line), the permissions for writing to localStorage are coming from the top page's domain.
In short, it looks like no iframe can write to localStorage in Chrome. Does anybody know if there's a way around this particular security "feature"? Or am I doing something wrong?
The problem only occurs when third-party cookies are disabled. Newer versions of Firefox and Opera are also blocking it. In IE and Edge it is still possible although third-party cookies are disabled. If the localStorage would not be blocked in the iframe, a web tracker could simply include a iframe, read the cookie, send it to the parent script, and then send it to the server.
The reason why this is not blocked in IE and Edge is that these browser allow websites to send third-party cookies, which were previously set as first-party cookies, to the server although third-party cookies are blocked. For example, if a user visits facebook on a regular basis, he gets first-party cookies from facebook. When he then visits other websites with facebook's share button, facebook can track him although third-party cookies are disabled. I really do not know why IE and Edge do not block third-party cookie sending, but I would not use these browsers anyway.
The errors the browsers show when third-party cookies are disabled:
Chrome and Opera: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
Firefox: SecurityError: The operation is insecure.
IE and Edge: No error, access to localStorage in iframe is possible although third-party cookies are disabled.
So in conclusion, it is not possible to bypass this security feature (in Chrome, Firefox, Opera) and this is good in order to ensure users' privacy.
This is an old post, but if someone else see it- you can use postMessage
https://stackoverflow.com/a/40469196/4836581
Well, localStorage is domain-based and there is no reason for your example code to fail. What it actually does is to set the test item to 123 for 127.0.0.1 whereas it will leave the localhost localStorage empty.
This might not be the answer to your initial problem of QUOTA_EXCEEDED_ERR, but just try to switch to private browsing on Chrome (Ctrl+Shift+N) to see if you still have the error. Without further information on what you were initially doing, I can't tell much but I believe that quota exceeded means what it means...
And I think Chrome's quota is 2.5mb unlike FF which has 5mb of localStorage quota.
Notice how Firebug can access the DOM of cross domain iframes and even allow you to modify them? I'm wondering if there is an firefox addon extension or a config setting that will allow a page on our intranet to do this.
Longer explanation:
I have a two "kiosks" in our reception area that the public can use. As we're running in kiosk mode (fullscreen, no chrome), I have created a small web application consisting of a menu and an IFRAME. The menu allows users to browse to approved sites and also perform actions like printing. It also gloms onto requests for popup windows and instead overlays them in a modal iframe rather than allowing the browser and OS chrome to be exposed - breaking the "kiosk" experience.
Obviously, this works perfectly on anything internal because it's all on the same domain. It gets trickier when browsing external sites because the XSS protection kicks in and you can't see the DOM inside the IFRAME.
I have also tried using a web-based proxy server on the same domain (PHProxy for example), which works okay, but there are horrible edge cases where it doesn't work - a big one is the CAPTCHA on our website forms. So that's pretty much not an option for me.
Basically I think the only solution that will work for me is to modify the browser in some way using a security setting or an addon. Any ideas?
Thanks guys very much for you time and consideration. It is VERY much appreciated.
--Iain
There is a way for unpriviledged JavaScript code (loaded from a web page) to request more privileges in Firefox. This is an old, non standard API that prompts the user for permission and if accepted allows the JavaScript to do things normal JavaScript cannot. One of these things is to bypass Same Origin Policy.
Sample code:
try {
// ask user for permission
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
} catch (e) {
// user refused permission
alert('Permission "UniversalBrowserRead" was denied.');
}
//Should now be capable of bypassing same origin policy if user accepted
Since the kiosk browser does not restart (I suppose) very often, the dialog just has to be accepted once. Not sure this is the most elegant solution but might work, at least for now (the API is old and might disappear).
Here is a link for more details: http://www.mozilla.org/projects/security/components/signed-scripts.html#privs-list
While looking for the exact privilege name I found this page about Security Policies in Firefox. This would be a much nicer solution. I have never used it, so I cannot give more info, but here is the link, might be a good place to start looking:
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
Hope this helps!
I found an addon called CrossDomain. The addon hasn't yet been updated for newer versions of Firefox. In the end, I solved this whole problem by writing an HTA and using the internet explorer rendering engine - which made my IT manager happy :). Here is the link to CrossDomain in case this helps someone one day. Thank you everyone for your submissions.
https://addons.mozilla.org/en-US/firefox/addon/13004/
Why not use Greasemonkey, it will allow you to run your script on any page.
I have a URI here in which a simple document.cookie query through the console is resulting in three cookies being displayed. I verified this with trivial code such as the following as well:
var cookies = document.cookie.split(';');
console.log(cookies.length);
The variable cookies does indeed come out to the number 3. Web Developer on the other hand is indicating that a grand total of 8 cookies are in use.
I'm slightly confused to believe which is inaccurate. I believe the best solution might involve just reiterating the code above without the influence of Firebug. However, I was wondering if someone might suggest a more clever alternative to decipher which tool is giving me the inaccurate information.
One reason might be that the other 5 cookies are HTTPONLY:
http://msdn.microsoft.com/en-us/library/ms533046.aspx
If the HttpOnly attribute is included
in the response header, the cookie is
still sent when the user browses to a
Web site in the valid domain. The
cookie cannot be accessed through
script in Internet Explorer 6 SP1,
even by the Web site that set the
cookie in the first place. This means
that even if a cross-site scripting
bug exists, and the user is tricked
into clicking a link that exploits
this bug, Windows Internet Explorer
does not send the cookie to a third
party. The information is safe.
Firefox also respects this flag (as of v2.0.0.5).
I'm pretty sure the web developer toolbar shows cookies for domain and sub-domains.
So it will show cookies for
abc.xyz.com
xyz.com
whether you are on a page of either domain