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.
Related
I am trying to load socket.io using the following code:
<script src="http://cdn.socket.io/socket.io-1.4.5.js"></script>
However some users have reported the following error to me:
Failed to load https://cdn.socket.io/socket.io-1.4.5.js ERR_SSL_PROTOCOL_ERROR
Is this an automatic security setting on modern browsers? And if so can it be disabled?
The problem is not your fault!
Accessing that link in my browser fails as well, and inspecting the unsuccessful request shows that the following header was set:
Upgrade-Insecure-Requests: 1
This tells the browser to "upgrade" all http:// URLs to https://, which seems to mirror the error your users are reporting.
ERR_SSL_PROTOCOL_ERROR indicates that the SSL certificate for https://cdn.socket.io/ is incorrectly configured and thus the browser (rightly) assumes the worst, and chooses not to trust data served from that domain over the secure protocol. When the domain is configured to "upgrade" insecure requests to secure ones, and secure requests are rejected by the browser, it becomes clear why there is no way to access the content correctly at either URL.
I would contact the administrators of the website and inform them of the problem, or just simply switch to another CDN like Chris Chen suggested:
<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.4.5/socket.io.min.js"></script>
Sounds like the users who are experiencing that error are hitting the https version of your page. Best way to deal with this issue is by changing your code to:
<script src="//cdn.socket.io/socket.io-1.4.5.js"></script>
Or
<script src="https://cdn.socket.io/socket.io-1.4.5.js"></script>
The former is preferable (because it is faster for http users) unless you are working with an .html or .htm page and want to open it without a web server.
The link is not working at all from anywhere. Is it a private link that require certification?
If you just want socket.io.js, use link from https://cdnjs.com/libraries/socket.io
I am interested in switching my entire site from http over to https.
My concern is that I have some content that uses absolute http URLs.
I will need to edit each page in order to change those URLs to relative but that might take me a while to accomplish.
What I would like to know is if there is a way to use Javascript via the Google Tag Manager in order to re-write local absolute URLs to be HTTPS and not HTTP?
If this is possible, could it be used as a permanent solution?
One solution to consider is the Content Security Policy upgrade-insecure-requests directive.
The upgrade-insecure-requests directive instructs user agents to
treat all of a site's unsecure URL's (those served over HTTP) as
though they have been replaced with secure URL's (those served over
HTTPS). This directive is intended for web sites with large numbers of
unsecure legacy URL's that need to be rewritten.
It’d amount to configuring your Web server so all pages on your site get served with this header:
Content-Security-Policy: upgrade-insecure-requests
So the effect of adding that header would be: for any page at your site served with an https URL, any time a browser sees in one of those pages an http URL for an embedded (sub)resource —whether it be a URL for a stylesheet, script, image, video, or whatever—the browser will automatically (transparently) try to fetch the resource from the corresponding https URL instead.
For more details, you can see the Upgrade Insecure Requests spec.
2018-05-11 update
The upgrade-insecure-requests directive is now supported in all major browser engines (including Edge 17+ and Safari 10.3+):
https://caniuse.com/#feat=upgradeinsecurerequests
The downside of using it now is, so far it’s only supported in Firefox (since Firefox 42) and Chrome. But it also:
has an open Safari/WebKit implementation-tracking/feature bug
is under consideration by Microsoft for implementation in Edge
P.S., I work at the W3C, where we recently (finally) enabled TLS/https access to all W3C site resources—and since the W3C has hundreds of thousands (maybe millions) of pages with http URLs for embedded subresources, the way we were able to make it happen was in part by serving the Content-Security-Policy: upgrade-insecure-requests header across the entire site.
The article Supporting HTTPS and HSTS on w3.org gives more info about the deployment details.
By the time the JavaScript is executed, the problematic resources may already be loading over even loaded.
You can simply search through your code for any instances of http:// and replace those with // or relative URLs.
If your content is more complex (say, distributed over multiple machines), you can use a mirroring script (like wget --mirror http://example.net/) to download a static version of your entire page, and search that.
Then, set up HTTPS (first for you only, then for all your testers) and check that everything works fine. Once you are sure that is the case, allow everyone to come over HTTPS. Finally, a bit later, consider redirecting HTTP to HTTPS and implementing secure cookies, HSTS and HPKP.
Recently I've seen these kinds of URLs in CDN documents:
//cloudflare.cdnjs.com/foo
And I realised that they lacked the http: or https: in front of them.
Hmm, I thought, and tried implementing them in a local test, and realised that they didn't work (they resolved // to be file://, though it was supposed to be http:).
Then when I uploaded this to my testing server, it worked (resolved // to be http://).
So I was wondering, why would anybody write it without the protocol?
Thanks.
(Technically, it's not the "protocol", but the URI scheme)
For HTTP, excluding the scheme means that the UA will use the current scheme (and therefore protocol) to retrieve the file, which means some copy + pasted code can be re-used for both HTTP and HTTPS (or even SPDY) requests without triggering the "Partially secure page" warnings in browsers.
Depending on the user's security settings, browsers will often present a warning if a page serves up mixed content (both HTTP and HTTPS). Of course, you could just code your HTML using the same protocol that you intend the page to be hosted with. However, it's not uncommon to use the same HTML in both secure and non-secure portals. Furthermore, you'd really prefer your HTML to be agnostic to the underlying protocol.
Writing CDN links like this makes sure that the CDN request uses the same protocol as the host page.
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 am using the following JQuery plugin to load an image slider http://www.orionseven.com/imageloader/index.php
However this is on a secure page (https) although the images are from external urls so therefore are not on secure pages. Is there anyway I can stop IE 7 displaying the security warning? Maybe changing my code or something?
You cannot disable those warnings.
The reason you're seing them is because the user should be notified that non-secure requests are being made (and potentially compromising the security in the process). Turning them off would be bad for the user.
You should probably be hosting the images on your local server rather than expecting a third party to host them for you. That way they can all be served as HTTPS from the same site, and problem solved.
If you must fetch them from the third party server, you'll only be able to solve this issue if that third party also provides HTTPS on their server. In that case, you'd need to modify the URL used to request the images to change the protocol depending on what protocol the main page is being served with.
If you want to load them remotely and that remote server doesn't provide HTTPS, then you cannot get rid of the message -- it's there intentionally in IE to provide a legitimate security warning. You can't override it.
I have the exact same issue. Since M$ considers every single one of their users to be brain-dead and decided to lock-down the ability to bypass that warning, I've decided on a much simpler solution- Use literally any other browser. Check out this solution-
https://stackoverflow.com/a/23047482/3692082
You could proxy images through localy hosted php script.
https://server/image.php?url=foobar.com/foo.gif
<?php
echo file_get_contents("http://".$_GET['url']);
?>
some comments about cross-site-scripting vulnerability should follow:)