Our web application (based on HTML5, SVG & JS) runs fine in all the browsers except Google Chrome.
In Google Chrome, the normal javascript events run fine, however, all the javascript events attached to the iFrame are not executed. We get the error in the console:
Unsafe JavaScript attempt to access frame
At the moment, the application is locally hosted and this problem cropped up during inhouse testing.
Googling this brings up lots of posts but none suggests any concrete solution. Any suggestions?
As an additional security measure, Chrome treats every "file" path as its own origin rather than treating the entire "file" scheme as a single origin (which is what other browsers do). This behavior applies only to "file" URLs and you can force Chrome to revert to a single local origin (like other browsers) by passing the --allow-file-access-from-files switch at startup.
You can find more information on the risks associated with local origins described here: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html
Please make sure that both the iframe and main page are using the same protocol (i.e. both https or both http, but not mixed) and are on the same domain (i.e. both www.example.com and not example.com and dev.example.com). Also there's the possibility that something tries to use the file:// protocol, which will also cause this message.
Related
I am not able to run my content script on the new tab page (where it is not assigned to any url).
I looked at various posts on the subject, ie, Does content script have access to newtab page?
and What is the URL of the google chrome new tab page and how to exclude it from manifest.json
which seem to suggest it is possible.
I enabled chrome://flags/#extensions-on-chrome-urls
I have:
"permissions": [
"http://*/*",
"https://*/*",
"chrome://*/*"
],
(also tried "*://*/_/chrome/newtab*")
still no luck ... what am I missing ?
this answer Can you access chrome:// pages from an extension? mentsions "wildcards are not accepted". Is this true ? and if so how to specify the newtab page ?
The problem is that Chrome 61 and newer explicitly forbids access to the contents of its built-in new tab page (NTP) via content scripts or any other API.
The solution is to create the entire replacement page as an html file in your extension and specify it in chrome_url_overrides.
As for why, here's quoting [source] rdevlin, one of the developers of chrome extensions API:
There's a few reasons for this change. One is to enforce policy,
the other is for consistency.
We've had a public policy for awhile now that states that modification of
the NTP through anything other than Chrome URL overrides isn't allowed (though
we didn't begin enforcing this policy in many cases until July 1st). This is
merely bringing chrome code more inline with that same policy to help prevent
surprise if an extension is modifying the NTP and is taken down for policy
violations.
This is also for consistency, since we've actually treated scripts on the NTP
differently for years now, due to certain NTP magic. For example, the URL seen
by the browser on the NTP is chrome://newtab, but the url in the renderer is
https://www.google.com/_/chrome/newtab. Since chrome.tabs.executeScript checks
the URL in the browser, the script would be denied, even though content scripts
(checked in the renderer) would be allowed. In theory, these permissions should
not be different. Similarly odd, if the user is using the local ntp
(chrome-search://local-ntp/local-ntp.html), injection would already be
disallowed in both the renderer and the browser. And, if we go waaaaay back,
the NTP used to be pure WebUI with an URL of chrome://newtab, where injections
were again disallowed. Rather than have inconsistent behavior depending on the
type of script injection the extension uses, we want to have consistency
throughout the system.
P.S. Please don't edit the quoted text.
If I have an html page I'm loading at the path file://some/path/whatever.html, can javascript in that file download whatever.html and examine it? I know the same origin policy disallows access to other files, but I'm not clear on whether it also bars access to the current file when using the file:// protocol.
In short: does the same origin policy disallow any access to file:// protocol paths?
I looked at mdn's documentation on this, but it doesn't make it clear.
It depends on the browser.
I've been able to do this in Firefox (using AJAX with jQuery, there might be an easier way), but not in Chrome, which doesn't allow access to local files to JavaScript.
EDIT: just learned that you can launch Chrome with the --allow-file-access-from-files parameter, which should enable this behavior.
I'm trying to make a bookmarklet to use on youtube and other video sites in order to easily get information from the video and store it elsewhere.
From today, apparently I can't do that anymore since youtube force itself on a https connection and from what I've read on chrome's console window, the bookmarklet doesn't run on a https page. Is there a workaround?
Here is the edited code:
javascript:(function(){var jsCode=document.createElement('script');jsCode.setAttribute('src','http://[mysite]/b/enter.php?i=userid&r='+Math.random());document.body.appendChild(jsCode);}());
Google Chrome (and possibly other browsers?) blocks HTTP resources from being accessed from an HTTPS document. This is to prevent "mixed content" attacks, in which insecure HTTP scripts could be intercepted by an attacker in transit over the network and altered to perform any kind of malicious activity (e.g., leak cookies or sensitive page information to a third party). Such a violation would undo any protection granted by HTTPS.
Chrome used to provide a prominent warning that an insecure resource was blocked, but now it no longer does so, and all insecure loads silently fail. The only solution available to you at this time is to use HTTPS yourself when you serve the script.
In Firefox, if you want to run a bookmarklet that references http on an https page, the way to get around this is to temporarily disable security.mixed_content.block_active_content. There are two ways to do this.
go to about:config in a new tab, search for security.mixed_content.block_active_content and then toggle the value to false. Run your bookmarklet and then toggle it back to true (since you probably want it turned on most of the time).
use an add-on / extension to toggle the block. A quick search turned up Toggle Mixed Active Content, and a quick test seemed to work well. There may be others.
Have fun and be careful. Here be dragons!
the bookmarklet doesn't run on a https page
Why not?
Try changing to a HTTPS domain yourself. Usually HTTP content is blocked when you're on a HTTPS domain.
I have created a work-around "fix" for this issue using a Greasemonkey userscript. You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.
I'm building a web page which I can only access by ftp:
ftp://192.168.0.1.cutthis/mypage.html
This url opens the page in the browser as I would have used http protocol.
The page contains a dynamic GUI. To make its development easier, I have moved all the javascript to a machine (192.168.0.2) I have access to, so I can edit it more quickqly. In the html source code of mypage.html, the script line is:
<script type="text/javascript" src="file://///192.168.0.2/myscript.js"></script>
FF and Chrome load the script (Firebug confirms this) but don't run it. Only IE run it.
How can I force FF and/or Chrome to run the script? Or how can I solve the problem overwise?
cross-protocol scripting?
Method 1:
For Chrome try extension: LocalLinks
For FF try extensions: LocalLink, Local Filesystem Links, IE Tab
Method 2:
run Chrome with --allow-file-access-from-files flag
or may be try other flag which disables cross-site scripting (waring: this is dangerous)
configure Security Policy in FF (create special policy for your site - read here: Links_to_local_pages_don't_work, Security_Policies)
But, I'm still not sure if all of this helps. FTP: URL is a special case
MDN says of the same origin policy:
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
myscript.js is from the origin file:////192.168.0.2/ but it is being loaded into a page with the origin ftp://192.168.0.1.cutthis. My guess is that the cross-domain script cannot perform the manipulation you expect it to do because it is loaded from a different origin.
The solution would be to host both the script and the page on the same origin (i.e., also serve the HTML page over file://, or even better, serve them both on a local HTTP server).
I am getting below error in IE8
"Do you want to view the webpage content that was delivered securely"
To disable this error we need to set this option
"Internet options -> Security -> Internet -> Custom -> Miscellaneous -> Display Mixed contents"
to enable
I am looking for a solution that can be done in code (probably javascript). Please tell me guys if have face any of such problem. The reason I am looking for a programmatic solution is because I cannot expect every user to enable this option.
You need to change your website to not embed any http:// resources on a https:// website. There is no other solution (except maybe not using HTTPS at all).
Actually, it would be very bad if scripts on a website could disable this warning. Mixed content can easily compromise the whole security provided by HTTPs e.g. when a script is loaded via http - it could be easily replaced e.g. through a MITM attack or DNS manipulation and then do anything with the website itself that was loaded securely.
You can't disable this security policy using javascript.
As #ThiefMaster said, this error is produced because you have a combination of things being fetched by both http:// and https://.
If all resources that you are currently serving via http:// can successfully be served via https:// instead, then you should change them all to do so.
Once they are all consistent, the error should go away.
A better way of referencing your URLs might be to use "protocol relative URLs" instead. This means that instead of "http://myserver.com/dir/resource.js" you use "//myserver.com/dir/resource.js" (i.e. remove the "http:" or "https:"). If you change all your URLs to that format (which is perfectly valid), then if the page itself is served over HTTP, then all resources (javascript, CSS, images, etc) will be served via HTTP as well. Likewise, if the page is served via HTTPS, then all resources will be served likewise. Again, make sure you can serve all resources this way first.