I have noticed today for the first time that Chrome (and only Chrome) does not pay attention to protocol-relative URL references. For example:
<img src='//www.example.net/image.png />
should source as https when it appears on https pages, and should source as http when it appears on http pages. IE and FF are still working this way, but Chrome is now sourcing it only as
//www.example.net/image.png
so when it appears on an https page, the page becomes unsecure. Anyone else notice this recently?
Chrome does respect protocol relative URL's, looking at your example it is malformed (there is no closing ' on your path.
Related
I am attempting to embed one site into another site. I control both servers, which I will refer to here as "site1.com" (the site in the browser) and "site2.com" (the site I am trying to embed).
HTML embed code
Attempt 1, using iframe tag:
<iframe height="600" width="600" name="my other site"
src="https://site2.com/foo/bar">
Unable to display--your browser does not support frames.
</iframe>
Attempt 2, using object tag:
<object type="text/html" height="600" width="600" name="my other site"
data="https://site2.com/foo/bar"></object>
Things I know are not the problem
Secure/insecure mismatch
I've read that Firefox will not allow an HTTP embed into an HTTPS page. Both sites are HTTPS, so there is no mismatch. The loaded resources (CSS, etc) are also https, from same origin, so there is no mixed-content problem.
I have tried setting security.mixed_content.block_active_content to false, in case I was mistaken about this, but the iframe was still blank.
Invalid or untrusted certificates
Both sites are using valid certificates, signed by a proper trusted authority, and are not expired. In fact, we are using a subdomain wildcard certificate, so they are both using the same certificate (they both are in the same subdomain).
X-Frame-Options
The site that I am trying to embed has this response header:
X-Frame-Options: ALLOW-FROM SITE1.COM
Content-Security-Policy
The site that I am trying to embed has this response header (wrapped here for readability):
Content-Security-Policy:
frame-ancestors https://site1.com;
default-src 'self';
script-src https://site1.com 'self' 'unsafe-inline';
style-src https://site1.com 'self' 'unsafe-inline'
Extra disclosure, possibly not needed - these headers are being generated by a Django application server, using this config and the "django-csp" module.
X_FRAME_OPTIONS = 'Allow-From site1.com'
CSP_FRAME_ANCESTORS = ('https://site1.com',)
CSP_STYLE_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CSP_SCRIPT_SRC = ('https://site1.com', "'self'", "'unsafe-inline'")
CORS
My understanding is that CORS is only in play when the request contains an "Origin" header. That doesn't seem to be happening here. I have also tried addressing CORS by using this header:
Access-Control-Allow-Origin: https://site1.com
But that appears to have no effect.
Ad blocker
I do not have an ad blocker in this Firefox install. I also removed all of my extensions and re-tested after a Firefox restart, the "blank iframe" behavior remains the same with no extensions installed at all.
Observed behavior
I have tested using the following browsers.
Google Chrome 58.0.3029.81 (64-bit) (macOS)
Safari 10.1 (macOS)
Firefox 53.0 (64-bit) (macOS)
Microsoft Edge 38.14393.0.0 (Windows 10)
Using Chrome, Safari, and Edge, the frame is shown like I expect - site2.com appears as a box inside of the site1.com page.
Using Firefox, I am shown an empty space of the size specified (600x600). If I used iframe, then there is a black border around it. If I used object, it's just a blank area with no border.
The most interesting thing is that if I open the developer console and reload the page, I see the requests to fetch site1.com and its CSS and so on, but there are no requests made for site2.com. It isn't that there is a problem showing site2.com, it is never requested at all.
Also, the developer console shows no errors or warnings about this. If there were an error condition or security exception preventing the loading of the second site, I would expect some sort of warning to be logged.
This has been driving me crazy for a few days. Any suggestions appreciated.
I reproduced the issue on my server which serves 2 domains, and then fixed it this way:
X-Frame-Options: ALLOW-FROM https://SITE1.COM
I added https://, as seen in MDN page for X-Frame-Options
You can observe the difference here (only with Firefox of course, as with other browsers both frames are shown): I pushed a php page that inserts the header without or with https://, and created this fiddle that insert 2 iframes: Firefox shows first iframe as empty, and second one with content (which echoes the value in header) on the right.
Since you are forced to put a "serialized origin" (protocol+FQDN), I wondered if you can put multiple entries, or wildcards. My understanding of RFC 7034 says you cannot.
Now about this detail:
The most interesting thing is that if I open the developer console and
reload the page, I see the requests to fetch site1.com and its CSS and
so on, but there are no requests made for site2.com. It isn't that
there is a problem showing site2.com, it is never requested at all.
That's because it was cached. I also saw that, but a force-refresh rightly showed a new request was made.
If you knew the source code (right click and view source of url to embed - but you control it in this case so you can copy and paste) and it was only a reasonably small amount of code (probable because you're using an iframe), then you could use the HTML5 srcdoc attribute to embed the html code, instead of pointing to the url. This would save a lot of hassle regarding unknown factors regarding the site you want to embed (CORS etc..) which you would not usually know if you didn't have control over the second site.
According to caniuse.com the srcdoc property has full support in Firefox since vsn 25 onwards (so since Sept 2013).
Hope this helps (Here's a tested jsfiddle example)
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
My web page sometimes (rarely) shows "there are some insecure resources" warning icon (yellow lock) like in the screenshot below. However that occurs rarely and now I caught another one I don't want to miss it again so I can't risk losing the page.
The page is at the URL: https://eksisozluk.com/sedat-kapanoglu-ve-40-kisiye-hapis-talep-edilmesi--3960310 . You will probably not see the warning (unless it's Firefox) because I didn't in my consecutive tries on Chrome and I was logged in when I got the error. So let's assume you and I will never see that warning icon on Chrome again.
Devtools was not open when I was using the site, so "Network" tab is empty. That part won't work.
"Resources" shows all JS and CSS entries as https there is no single resource from http there.
The page has jQuery loaded so I tried queries $('*[href^="http:"]') and $('*[src^="http:"]') to no avail. The page contains some external http links (not resources, plain a href's) but that wouldn't trigger the alarm.
I'm using Kaspersky Anti-Virus and it uses a proxy to scan incoming/outgoing traffic. That could be causing some trouble although I haven't had any issues so far with other web sites.
I tried "view page source" and searching it for http resources but only tag with http resource link was:
<meta name="twitter:image" content="http://eksisozluk.com/content/img/ilogo120.png" />
which actually exists in the page when the icon is green too. So that cannot be the reason.
Isn't there a way to directly view the "insecure content" whatever that is in Chrome?
When I view the page in Firefox it says "partially encrypted" but it doesn't show what's not encrypted either. All the items in "Media" tab start with "https://".
Actually now I'm able to reproduce the issue continuously on Firefox. I looked at the network tab and "nothing" shows as http:// yet Firefox tells me "partially encrypted". I'm not sure if Firefox is saying that for the same reason Google does (because Firefox is consistent and insistent about it), but I'm providing both scenarios in case they belong to the same root cause.
I finally wrote this code in Chrome console to find the culprit:
$("*").each(function (index, elem) {
var attrs = elem.attributes;
for(var n = 0; n < attrs.length; n++) {
var attr = attrs[n];
if(attr.nodeValue.indexOf("http://") >= 0) {
console.log("FOUND: <" + elem.nodeName + " " + attr.nodeName + "='" + attr.nodeValue + "'>");
console.log($(elem));
}
}
});
The output shows no interesting stuff. Only <META content> for twitter reference, <A href>s and two <TD title="http://...">s that Mvc-Mini-Profiler inserted. None of them justify the warning of course. Here is the full output: http://pastebin.com/kgV8XHgN
So this looks really interesting. There is NOT a single element in DOM that contains an "HTTP" link yet Chrome warns about "insecure" content. I'm very troubled by it.
There are NO iframes on the page. ($("iframe") returns [])
EDIT: DAMN I lost the page :( (navigated to a link and back button turned to SSL icon to green). I knew it wouldn't last long. But I still appreciate any help since it wasn't the first time I saw that issue.
Just had this problem – if you check the Javascript Console in Chrome it will now tell you where the problem lies.
I had the same issue yesterday, and found http://www.whynopadlock.com/
It shows which elements are not secure, and it also verifies certificate chains.
Btw, if your site can be loaded both http and https, then omit http: from external urls.
Not:
src="http://external.dom/external.js" or "https://external.dom/external.js"
Just:
src="//external.dom/external.js"
Then the browser will use http or https depending on what the page is loaded as
I just spent an hour with a similar problem, I got the green ssl lock in Chrome and IE but not in Firefox (only after page reload).
First of all: To debug SSL issues, the httpfox plugin seems to be better than firebug's network tab. Firebug showed all sources as https, but looking at httpfox, I quickly found the culprit: Google Analytics was loading the ___utm.gif tracking pixel via http. This tracking pixel came from the previous page, where I was tracking a Google Analytics event which was attached to a button click.
This seems to be a bug in Firefox: When tracking a GA event from a http page to a https page (e.g. Proceed button click), FF will load the tracking pixel via http on the https page, causing the error.
I removed the event from the button and FF stopped complaining about the partially encrypted connection.
It sounds most likely that an AJAX resource was used with an http:// URL... you would most likely need the network panel or console to check that.
Firefox's built-in developer tools have them.
A quick solution is to add target="_blank" in each <a> element. It will open the link in new window. Working on all browsers.
This example to load a url in an iframe works. However when I change url to something like http://www.yahoo.com the iframe doesn't load antyhing
Here is an example side by side.
In Network tab of developer tools for Chrome, I see that request to Yahoo was cancelled. In FF it doesn't give any errors, just doesn't return any content. IE9 gives a message that It cannot display this content.
This happens in Chrome, FF and IE9 (I haven't tested previous versions of IE).
That is because Yahoo itself prevents this from happening.
It has been noted here: https://stackoverflow.com/a/9013722/476786
To see for yourself, try setting the source to http://www.google.com/ which won't work as well, but then try http://www.bbc.co.uk/ and that will work.
Possibly works as described here: https://stackoverflow.com/a/2896705/476786 using X-FRAME-OPTIONS
If the site hosting the webpage forces the use of a secure HTTPS connection, some browsers (chrome for sure) will require that all network resources use HTTPS as well.
Basically if your site forces HTTPS, try setting src="https://yahoo.com"
This won't solve OP's answer directly due to it being a limitation of Yahoo itself, but other people viewing this page might be experiencing this issue as a result of this (I was).
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.