SEC7111 HTTP security compromised by Microsoft Edge extension - javascript

I implemented an edge extension where my popup has embedded iframe while loading the popup, it throws an error i.e.
SEC7111: HTTPS security is compromised by ms-browser-extension://SecureInput_55A39EC1FD424BE88AD67FFE91F90A63/pages/notification.html
SEC7111: HTTPS security is compromised by ms-browser-extension://SecureInput_55A39EC1FD424BE88AD67FFE91F90A63/scripts/lib/underscore-min.js
How to fix these issues?

We're aware of this issue and are tracking it publicly: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8748330/
From what we've seen in our tests, however, these exceptions are merely cosmetic (i.e. we're displaying the message, but do not actually prevent the loading of any resources).
If you are actually seeing resources being blocked, please let me know, as this is something we are not aware of.

Related

Do I have to switch to https to use "SharedArrayBuffer" in chrome 92?

My website does not work with chrome 92. With chrome 91 everything was fine. The problem is "SharedArrayBuffer" are not enabled since chrome 92. When I try to enable it by adding the header "Cross-Origin-Embedder-Policy: requre-corp and Cross-Origin-Opener-Policy: same-origin" I get the error message:
"The Cross-Origin-Opener-Policy header has been ignored, because the origin was untrustworthy. It was defined either in the final response or a redirect. Please deliver the response using the HTTPS protocol. You can also use the 'localhost' origin instead. See https://www.w3.org/TR/powerful-features/#potentially-trustworthy-origin and https://html.spec.whatwg.org/#the-cross-origin-opener-policy-header."
Does "Please deliver the response using the HTTPS protocol" mean I have to switch to HTTPS only to use "SharedArrayBuffer"? If so whats the reason?
Yes, you need to use HTTPS.
Certain features (which includes SharedArrayBuffer, due to the revelations of Spectre-style attacks) are security-sensitive and require a greater degree of isolation. COOP/COEP allows the browser to isolate your page from other sites to a greater degree, which allows this feature to be safer to use.
Some features, including COOP, have significant effects on how the browser treats content from your origin. The browser can't be sure that this assertion hasn't been tampered with unless it is delivered from a potentially trustworthy origin (if that's not localhost, this means over HTTPS).

Ignore X-frame-header using javascript

I would like to ignore X-frame header on my website so that iframe can load external websites. There are chrome extension like
this one which works perfectly. How can I implement same concept through javascript?
You can’t use frontend JavaScript code running in a browser to cause the X-Frame-Options response header to be ignored. X-Frame-Options is a security feature designed in part as a defense against clickjacking attacks. If any site could just use some JavaScript code to cause browsers to ignore X-Frame-Options, that would pretty much make it completely useless.
That’s the reason why the only way you can cause it to be ignored in your own browser is by intentionally opting-in to insecure browsing by installing an extension as mentioned in the question.
But you can’t use JavaScript to force insecure browsing on other users by bypassing security features like X-Frame-Options that browsers have built-in support for.

Chrome blocking iframe requests as cross-origin request even when origins are the same

This one has me stumped.
I have a web app that has a file upload/download area. Files are downloaded in the background via a temporary iFrame element. This is a single-paged AJAX application and the UI is written in Javascript, jQuery and uses the jQuery.FileDownloader.js to manage the iFrame. The application runs over HTTPS and the site and download URL are on the same exact domain. The back-end is a RESTful application. This has worked great for months. Until today.
All of a sudden, when attempting to download a file in Chrome, the browser reports an error of "Blocked a frame with origin https://example.com from accessing a cross-origin frame."
The problem is that the origin of the main site and that of the iframe are the exact same domain. I have ensured that the domains are the same as well as the protocol. Chrome is the only browser that throws up the cross-origin error. IE, Firefox, Opera, Safari... all work as expected. It's only in Chrome and it's only as of today. To make things worse, no updates were made to the browser. It truly is spontaneous. I've also ruled out plugins as the cause by running in Incognito mode, where none are allowed to run by my settings, as well as disabling my anti-virus software. This problem is being exhibited on other computers, in other locations (not on our LAN or subnet), all running Chrome.
And, again, both domains of the parent frame and the embedded iframe are identical. This only happens against the production server which runs over HTTPS. Other non-HTTPS sites (e.g. our dev environment, localhost) don't have the problem. Our SSL is valid. Since this is a single-paged AJAX application, we're trying to avoid popping up another window for the download.
Hopefully, someone can offer some advice. Thanks in advance.
Update: After additional research, I have found the solution to this problem is to enclose the filename in the response header in double-quotes.
I have found the cause of the problem. It turns out that Google Chrome has problems with files that have commas in their filename. When downloading the file via a direct link, Chrome will report that duplicate headers were reported from the server. This has been a long-standing problem with Chrome that has gone un-addressed. Other browsers are not susceptible to this problem. Still, it's a fairly easy problem to troubleshoot and, indeed, when I searched on this error, the first search result had the solution: remove commas from filenames when handling a request from Google Chrome.
However, this wasn't a direct link, it was an AJAX-request, which results in a different exception. In this case, the error provided by Chrome is the cross-origin request exception and this is what made it so difficult to troubleshoot.
So, the tl;dr of it all is to strip out commas in the names of uploaded files.
Another instance I found where this issue occurred is after executing code similar to:
document.domain = '[the exact same domain that the iframe originally had]'
Removing this line of code got rid of this error for me.

No 'Access-Control-Allow-Origin' header - Same Domain?

Today I attempted to browse a new feature recently deployed to our testing environment (NOT LOCAL). After navigating to the new feature I was met with a blank page. Confused, I checked Chrome's console and found an error:
XMLHttpRequest cannot load https://test.mytestsite.com/SomeApplication/api/SomeController/SomeMethod/8?Id=523283&SecondId=1612w3426653.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://test.mytestsite.com' is therefore not allowed access.
This code makes an ajax call to a WebAPI (on the same domain) to retrieve some information on document.Ready. I understand the error and I'm familiar with it's typical cause. However, this call is being made from within the same domain AND it works for the other developers on my team.
Symptoms:
- Does not work for IE or Chrome/Incognito
- Does work for FireFox
- Works on all browsers for at least 4 other developers on the same domain that I reside on. (Indicating to me that this is an environmental issue)
Possible causes:
- I was doing some CORS research several weeks ago and perhaps I configured some Windows 7 setting to cause this to happen?
Google is saturated with the standard CORS issues, so I'm asking here and hopefully someone can help.
The issue at hand was due to inconsistencies between environments.
In our production environment SSL is enforced with a redirect in IIS, while in our testing environment it is not. I was navigating to the site via a bookmark using http. Updating the bookmark, as #epascarello suggested, fixed the problem.

Inter frame SOP - Chrome Extension

In a Chrome Extension, I'm trying to get gmail compose body content.
An error jumps out sporadically, and does not prevents it from working.
This is being run as a content script. I believe permissions are not the issue here, because when there is a permission missing, the error is different and the operation is blocked by Chrome, definitely not the case.
Error comes out in this line:
encodeURIComponent($canvas.find('iframe').contents().find('body').text());
where
var $canvas = $('#canvas_frame').contents();
Any information on this error and a possible turnaround?
You can not read cross site content using javascript. XSS Auditor of Google Chorme will never allow this.
Please have a look at http://en.wikipedia.org/wiki/Same_origin_policy
UPDATE 1 -
There is support for cross site communication using window.postMessage() in Chrome 2+. Please have a look at this documentation https://developer.mozilla.org/en-US/docs/DOM/window.postMessage
To give a good answer, we need more information:
where exactly you are running this code, is it in the web page, the extension's content script or the etension's background script?
Also, what does your manifest.json file look like? Which sites have you asked for permission to run on.
I suspect this is a case of a badly-written error message and really it is saying: your extension does not have permission to run on apis.google.com. In that case, simply add permissions for apis.google.com. More details are in the Chrome extensions docs: http://developer.chrome.com/extensions/manifest.html#permissions

Categories