Facebook iFrame security error (document.domain) raised by hasPasswordField_ - javascript

We have a project that use standard Facebook API used mainly for login and registration purpose.
Since we use Sentry to receive error notification, the following one (in home page) occurs often:
SecurityError: Blocked a frame with origin "https://www.mywebsite.com" from accessing a
frame with origin "https://www.facebook.com". The frame being
accessed set "document.domain" to "facebook.com", but the frame requesting access did not.
Both must set "document.domain" to the same value to allow access.
at hasPasswordField_ (/en:1:368)
at hasPasswordField_ (/en:1:499)
at findPasswordForms (/en:1:173)
at global code (/en:10:27)
It's strange because the methods
hasPasswordField_ / findPasswordForms
don't exist on the project code.
Because the error currently occurs only on
iOS Chrome Mobile, version: 59.0.3071 | 60.0.3112
There is a Chrome internal component that is trying to access to the Facebook iFrame or is Facebook searching for some password fields on the webpage?
UPDATE:
After a further search, I found this post on Sentry GIT page:
https://github.com/getsentry/sentry/issues/5267
they suggest simply to ignore the error.
Any idea how to face it differently?
Any help will be appreciated!

It says here that the bug has been fixed in version 61. https://crbug.com/709132

Related

MSAL.JS 1.2.0 Login Redirect - Unsafe JavaScript attempt to initiate navigation for frame with URL '' from frame URL ''

We're currently migrating our SPA's (Angular 8) authentication library from ADAL.js 1.0.16 to MSAL.js 1.2.0.
The authentication process works fine with the newest MSAL version on Chrome v76.0.3809.100 and Firefox v68.0.2.
However, on Safari v13.0.4 we have two scenarios, depending on the state of the "Prevent cross-site tracking" property:
- Checked: the application works fine.
- Unchecked: the login process stops on the redirect, and we get the error message below:
Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://myapplication.com/' from frame with URL 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=token&scope=...'. The frame attempting navigation of the top-level window is sandboxed, but the 'allow-top-navigation' flag is not set.
Inspecting the iFrame, the sandbox tag provides two values: allow-scripts and allow-same-origin, and not the allow-top-navigation as expected on the error message.
Additionally, there is another issue associated with MSAL and Safari, that blocks the acquire token process, which is solved unchecking the "Prevent cross-site tracking" property:
https://github.com/AzureAD/microsoft-authentication-library-for-js/wiki/Known-issue-on-Safari
The bottom line is, just turning off the "Prevent cross-site tracking" is not an option once that we also faced the error when acquiring a token silently.
I'd appreciate getting some directions on this issue. Thanks.

Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document [duplicate]

Uncaught SecurityError: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.
No clue how to go further on this...when all I did was `
Works in Firefox, not in Chrome.
Could be something related to http://help.twitch.tv/customer/portal/questions/6299203-javascript-errors-in-chrome-
I had the same problem with localStorage, and fixed it like this :
Under Settings > Privacy > Content settings, change the cookies' settings to "Allow local data to be set" or the second option (in my case, it was previously on "Block sites from setting any data").
Edit
On newer Chrome versions, make sure the first option is ticked here: chrome://settings/content/cookies
I had the same issue, but my problem was a script blocking plug-in ScriptBlock that I had set to allow the site but was still blocking some actions and not reporting it.
Disabled the script blocker and voila!
If you still want to block most 3rd party cookies, you can add an exemption. I usually can do it through the cookie button that pops up in the AddressBar, but it wouldn't let me for localhost. I had to add it via chrome://settings/content/cookies Picture of chrome://settings/content/cookies
For the latest chrome browser, this might work and better guide for you. And it works for me.
Settings > Privacy and security > Cookies and other site data > Allow all cookies
That should work perfectly.

Why is same-origin-policy blocking this javascript call on a local domain?

I've got a local dev site running on http://mysite.local/
(it's a Django admin site with Grappelli installed, if that's any relevance).
The admin site opens a popup window for some operations (i.e. via showRelatedObjectLookupPopup())
Due to previous similar issues with same-origin-policy (in production, the admin site loads some URLs from a CDN domain, which can trigger it) we have a "normaliser" JS function that explicitly sets:
document.domain = "mysite.local";
Both in the parent and in the popup, on page load.
The popup contains a link with an onclick handler that triggers a JS function in the parent:
onclick="opener.dismissRelatedLookupPopup(window, '422'); return false;"
Clicking this link in Chrome or FF results in a similar browser error:
Permission denied to access property "dismissRelatedLookupPopup" on
cross-origin object
or
Blocked a frame with origin "http://mysite.local" from accessing a
cross-origin frame.
Both the popup and the opener URLs share the same protocol, domain and port.
This is only an issue on the local domain. On dev/uat/production sites, (i.e. dev.mysite.com), all of which have their domain set to the superdomain "mysite.com" by the above "normaliser" function, the popup can successfully call the JS function in the parent.
What's stopping it on the local domain? What have I missed?
It seems that switching the local domain, as per the original suggestion from #charlietfl, has indeed fixed the issue. It now runs locally as local.mysite.com instead of mysite.local, and the same-origin error has gone. I'm still unclear on what was triggering the error (was it because the the domain had only two parts as opposed to three? Was it something specific to domains ending in ".local"?) but in the unlikely event that anyone else trips up on this, that's what fixed it for me.

Firefox localstorage from iframge - SecurityError: The operation is insecure

I have 2 subdomains:
www.example.com = For logged in users only
internal.example.com = Public website
Since I use localstorage to store some informations on internal.example.com which I need on www.example.com I had implemented the following solution:
I load on www an iframe located on internal. I set on both sides the document domain value to the "parent domain"
document.domain = "example.com";
Now on www, I can access the localStorage of internal over www by doing the following:
frames['internalFrameName'].window.localStorage;
Now I can read and write values. This works in Chrome and Internetexplorer, and it worked in Firefox until the last update to FF30. Now I get the error:
SecurityError: The operation is insecure.
Any ideas how to fix it?
You could use a messaging system to communicate between the both frames. Then the iframe can just send you the local storage data.
This might help you with that: How to communicate between iframe and the parent site?
You need to use frames['internalFrameName'].postMessage(message, targetOrigin, [transfer]);
Gecko throws the error message when cookies are disabled so besides the object detection for localStorage (which I'm sure you're doing in the code you didn't post) first check for support for cookies.
Change:
if (window.localStorage)
To:
if (document.cookie && window.localStorage)

addthis: JS security error for addthis utility frame

I'm trying to use addthis on my page. When using Chrome, I receive a JavaScript security error.
Unsafe JavaScript attempt to access frame with URL <AddThis url> from frame with URL <local url>. Domains, protocols and ports must match.
The only frame I've got in this page is an AddThis-generated one, with the title "AddThis utility frame".
Is there any way to get over this?
I've seen this in addthis's implementation of nucaptcha for their version 250. Try upgrading to their 300 version, they went back to recaptcha.

Categories