I load some HTML into an iframe but when a file referenced is using http, not https, I get the following error:
[blocked] The page at {current_pagename} ran insecure content from {referenced_filename}
Is there any way to turn this off or any way to get around it?
The iframe has no src attribute and the contents are set using:
frame.open();
frame.write(html);
frame.close();
Note: While this solution may have worked in some browsers when it was written in 2014, it no longer works. Navigating or redirecting to an HTTP URL in an iframe embedded in an HTTPS page is not permitted by modern browsers, even if the frame started out with an HTTPS URL.
The best solution I created is to simply use google as the ssl proxy...
https://www.google.com/search?q=%http://yourhttpsite.com&btnI=Im+Feeling+Lucky
Tested and works in firefox.
Other Methods:
Use a Third party such as embed.ly (but it it really only good for well known http APIs).
Create your own redirect script on an https page you control (a simple javascript redirect on a relative linked page should do the trick. Something like: (you can use any langauge/method)
https://example.com That has a iframe linking to...
https://example.com/utilities/redirect.html Which has a simple js redirect script like...
document.location.href ="http://thenonsslsite.com";
Alternatively, you could add an RSS feed or write some reader/parser to read the http site and display it within your https site.
You could/should also recommend to the http site owner that they create an ssl connection. If for no other reason than it increases seo.
Unless you can get the http site owner to create an ssl certificate, the most secure and permanent solution would be to create an RSS feed grabing the content you need (presumably you are not actually 'doing' anything on the http site -that is to say not logging in to any system).
The real issue is that having http elements inside a https site represents a security issue. There are no completely kosher ways around this security risk so the above are just current work arounds.
Note, that you can disable this security measure in most browsers (yourself, not for others). Also note that these 'hacks' may become obsolete over time.
Based on generality of this question, I think, that you'll need to setup your own HTTPS proxy on some server online. Do the following steps:
Prepare your proxy server - install IIS, Apache
Get valid SSL certificate to avoid security errors (free from startssl.com for example)
Write a wrapper, which will download insecure content (how to below)
From your site/app get https://yourproxy.com/?page=http://insecurepage.com
If you simply download remote site content via file_get_contents or similiar, you can still have insecure links to content. You'll have to find them with regex and also replace. Images are hard to solve, but Ï found workaround here: http://foundationphp.com/tutorials/image_proxy.php
I know this is an old post, but another solution would be to use cURL, for example:
redirect.php:
<?php
if (isset($_GET['url'])) {
$url = $_GET['url'];
$ch = curl_init();
$timeout = 5;
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$data = curl_exec($ch);
curl_close($ch);
echo $data;
}
then in your iframe tag, something like:
<iframe src="/redirect.php?url=http://www.example.com/"></iframe>
This is just a MINIMAL example to illustrate the idea -- it doesn't sanitize the URL, nor would it prevent someone else using the redirect.php for their own purposes. Consider these things in the context of your own site.
The upside, though, is it's more flexible. For example, you could add some validation of the curl'd $data to make sure it's really what you want before displaying it -- for example, test to make sure it's not a 404, and have alternate content of your own ready if it is.
Plus -- I'm a little weary of relying on Javascript redirects for anything important.
Cheers!
add <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> in head
reference: http://thehackernews.com/2015/04/disable-mixed-content-warning.html
browser compatibility: http://caniuse.com/#feat=upgradeinsecurerequests
You will always get warnings of blocked content in most browsers when trying to display non secure content on an https page. This is tricky if you want to embed stuff from other sites that aren't behind ssl. You can turn off the warnings or remove the blocking in your own browser but for other visitors it's a problem.
One way to do it is to load the content server side and save the images and other things to your server and display them from https.
You can also try using a service like embed.ly and get the content through them. They have support for getting the content behind https.
Using Google as the SSL proxy is not working currently,
Why?
If you opened any page from google, you will find there is a x-frame-options field in the header.
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Sites can use this to avoid clickjacking attacks, by ensuring
that their content is not embedded into other sites.
(Quote from MDN)
One of the solution
Below is my work around for this problem:
Upload the content to AWS S3, and it will create a https link for the resource.
Notice: set the permission to the html file for allowing everyone view it.
After that, we can using it as the src of iframe in the https websites.
You could try scraping whatever you need with PHP or another server side language, then put the iframe to the scraped content. Here's an example with PHP:
scrapedcontent.php:
<?php
$homepage = file_get_contents('http://www.example.com/');
echo $homepage;
?>
index.html:
<iframe src="scrapedcontent.php"></iframe>
Use your own HTTPS-to-HTTP reverse proxy.
If your use case is about a few, rarely changing URLs to embed into the iframe, you can simply set up a reverse proxy for this on your own server and configure it so that one https URL on your server maps to one http URL on the proxied server. Since a reverse proxy is fully serverside, the browser cannot discover that it is "only" talking to a proxy of the real website, and thus will not complain as the connection to the proxy uses SSL properly.
If for example you use Apache2 as your webserver, then see these instructions to create a reverse proxy.
Try to use protocol relative links.
Your link is http://example.com/script.js, use:
<script src="//example.com/script.js" type="text/javascript"></script>
In this way, you can leave the scheme free (do not indicate the protocol in the links) and trust that the browser uses the protocol of the embedded Web page. If your users visit the HTTP version of your Web page, the script will be loaded over http:// and if your users visit the HTTPS version of your Web site, the script will be loaded over https://.
Seen in: https://developer.mozilla.org/es/docs/Seguridad/MixedContent/arreglar_web_con_contenido_mixto
All you need to do is just use Google as a Proxy server.
https://www.google.ie/gwt/x?u=[YourHttpLink].
<iframe src="https://www.google.ie/gwt/x?u=[Your http link]"></iframe>
It worked for me.
Credits:- https://www.wikihow.com/Use-Google-As-a-Proxy
Related
I have two websites.
Both websites sit on the same hosting environment.
I have broad control over the hosting environment.
One website is a Drupal website and the other is a static (plain HTML website).
I try to iframe-embed one of the HTML webpages of the second, static website into the Drupal website, but I get:
iframe refused to connect
When checking the Drupal website from browser console, I get:
Refused to display 'https://example.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
I don't understand this error (shouldn't sameorigin be the correct directive to allow embedding?).
What security directive should I change, and where, to allow the iframe to be displayed?
I have already tried to put the following directive in .htaccess of the second, static website:
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>
You should read up about origins (they're very important; they are the concept that underlies most web security boundaries). An origin has nothing to do with the physical, logical, or legal source of a web page; the browser does not, and cannot, know any of that. An origin is simply the tuple (ordered fixed-length collection) of Protocol, Hostname, Port. ("Hostname" here typically meaning the fully-qualified domain name, not just any part of it, but local-network sites often just use hostname.) You say you "have two sites", by which I assume you mean they have different domain names. If they have different domain names, they can't have the same origin, because all three parts of the tuple must match. Thus, specifying SAMEORIGIN on one of them will obviously not allow the other to frame it; they aren't the same origin! As far as anybody's browser knows, the parent page is an unrelated malicious site trying to violate the security constraints of the would-be guest page.
Possible solutions:
Remove the X-Frame-Options directive from the guest page. This will let anybody frame it, though, so make sure that's OK if you do it (if the second page is static and unauthenticated then of course it is; anybody could simply fake the embedding by serving the same static content so XFO is doing nothing for you).
Replace the X-Frame-Options header (on the guest page) with a Content-Security-Policy header that specifies a frame-ancestors directive allowing the parent site.
Move both pages to the same origin, either by copying the page to the other server/site, or adding a server-side fetch for that path which grabs it from the other server.
Use CORS to request the embeddable content across origins, and embed the response HTML in the parent page, possibly in an iframe's srcdoc. (Included only for completeness; this is almost certainly not the best approach here, as configuring CORS correctly is far harder than the other options.)
<meta http-equiv="refresh" content="3; ,URL=http://www.redirectsiteurl.com">
Trying to redirect from my website but would like to know if it is possible to show the redirect site url instead of the url redirected to. In some web host, they have the option for stealth domain forwarding but unfortunately mine doesn't have this option so I am trying to work around it with META REFRESH
If you're referring to not changing the URL to redirect to another (in my experience), these "stealth redirects" are nothing more than frame-based redirects that take up the entire display:
<body style="height:100%;margin:0;padding:0;">
<iframe width=100% height=100% src="http://stackoverflow.com"></iframe>
</body>
(jsFiddle)
Otherwise, you're going to need to set up a reverse proxy using something along the lines of mod_proxy (a necessity if the page you're "redirecting" to prohibits frames from external locations).
I don't think you do with just HTML. Can you run php? or another scripting language. You probably want to set an HTTP status code of 301 or 302 and redirect.
In php you'd do the following (I know you haven't specified php, but what you're asking is not possibly with just html/js).
header("HTTP/1.1 301 Moved Permanently");
header("Location: somewhere.php");
exit;
This question already has answers here:
shorthand http:// as // for script and link tags? anyone see / use this before?
(2 answers)
Closed 9 years ago.
I had never noticed that before, but if you go to the Google libraries pages, all the HTML is coded with the src=//expression, i.e. for Jquery :
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>
But if you go to the Jquery page, they told to us to embed the code with an src=http://
like
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
I don't really get what the difference between the two of them?
What's the pros & cons of these use?
EDIT :
Ok, i uderstand the meaning of this, the first one allows you to keep the same protocol for loading the lib, http or https. But is that it? There is no speed/security/deeper reasons for that ?
Seems weird to me, the src=http://works everywhere, the first one don't works on a local file, so why should i use the src=//expression ?
It's a protocol-relative URI - if it appears in an http page it'll be treated as http:// but if it appears in an https page it'll be treated as https://.
If a page loaded over https includes other resources that are loaded over http then browsers will present a warning or may even consider the page as a whole to be "insecure". In order to ensure that the user doesn't get a "broken padlock" all images, JS and CSS files must also be https (not necessarily loaded from the same server or protected by the same certificate, but they must all be https connections that the browser knows to trust).
An http page loading https resources is less of an issue, but since you don't really gain anything in terms of the user experience by doing this, you might as well just load the resources via http too.
It is used to use the same protocol as the source page.
If the page is loaded used http protocol then the library files will be loaded using http, if https is used to load the page then the library also will use the same protocol
In my website with SSL certified URL, I need to include http content for static contents - JS, CSS, Images etc.
E.g. the page at https://www.example.com will refer to http://subdomain.example.com/images/a.jpg.
Is there a way to include HTTP element within HTTPS page, avoiding any security alerts in the browser?
No. The security warnings are there for a reason and cannot be bypassed.
What if someone altered the JS en-route with a man-in-the-middle attack? They could add their own code and have full access to the DOM, making the SSL worthless.
To be secure, you need to load the entire page over HTTPS, not just the HTML document. If you are secure, then the warnings about being insecure will go away.
You don't need to define http:// when calling your static assets. You can use the protocol-relative url, basically you can do this :
<img src="//subdomain.abc.com/images/a.jpg" alt="">
It will get the image through the same protocol as the page you're on.
Paul Irish will explain that better than me on his blog
I don’t think you can bypass security alerts (on browsers that give them) if your https page includes http content. But check whether the references work with https as well (depends on the server of course). If they do, you can use URLs like //subdomain.example.com/images/a.jpg which means that the protocol (http or https) of the page itself will be used.
I did a search and could not find an answer on here to my question. What I am confused about is what URLs on an https page need to be https, as opposed to http.
I am making a series of pages my website that must be accessed over https. At the top of the pages is a menu. I accidentally included a style sheet into the page using http, instead of https, and all the browsers I tried gave me a warning about insecure content. But, I can leave the menu links at the top of the page http, and there's no problem.
So, am I correct in saying that things that are being loaded onto the page, such as style sheets and images, need to have https in the link, but that plain old href links can just have http in them?
Thanks for your advice.
Generally your secure pages such as purchase page, credit card etc processing pages are set to https or sometimes all pages such as websites for banks or other financial institutes or even login pages.
You can leave it to browser to deciper http or https part by using what is called protocol-relative URLS in which you simply do not specify either of http or https and still browser will be able to figure it out. An example:
//example.com
//google.com
Let's say your domain is foo.com, you would specify all URLs like:
//foo.com/page1.html
//foo.com/otherpage
So you simply leave the http or https part in your URLs.
To know more about protocol-relative URLS, see:
http://paulirish.com/2010/the-protocol-relative-url/
Yes, all links that are used to create the page itself (the HTML, the CSS, JavaScript, the images) need to be served over https. That means all URLs of that domain need to be served over https.
Links to other websites can be http just fine. You may want to check if those links can be visited over https as well because then the user will use a secure connection to visit those website as well.