21

Update: There is more information on Subresource Integrity at MDN, which (as of 12/12/16) shows support in Chrome 45+ and FireFox(Gecko) as of 43+ Update: There is a w3c draft called Subresource Integrity describing a feature like this. It's already implemented in Chromium. For example: <script src="file.js" integrity="ni://sha256;BpfBw7ivV8q2jLiT13…"...


17

I would assume your reasoning is something like, "If the person constructing the page chose to send some of its images insecurely, then the browser should respect that this decision was done for a reason and allow it without a warning. The page is as secure as the entity providing it wanted it to be." By contrast, the reasoning of the browser developers is ...


11

Certain elements of the page are not sent via HTTPS. This means that those elements can be read by anyone sniffing the network, or modified in-transit by an active attacker. This might result in an attacker executing JavaScript on the page. As such, your browser is warning you that the page is, for most intents and purposes, the equivalent of not being ...


11

The browser doesn't know what type of information an image or other resource is supposed to convey: perhaps it's just a logo, or perhaps it's some piece of UI, or perhaps the image is the whole point of the page you're visiting. There's no way for the browser to know whether a resource is important or not to the user. When the primary (page) URL is loaded ...


7

Danger Will Robinson, Danger! The form on the site is not secure, and any data sent through that form will be in plain text. This means anyone listening to this communication will have a plain text copy of any data sent to that address. If you don't know what data is sent there then you can't know if it's safe. Without code review you wouldn't know, and ...


6

Short answer: lack of semantic information Long answer In a forum, the user naturally expects stuff to come from "unauthorised" third parties (any registered user, could be anyone really), not only from the webmaster (and authorised authors). The user fully understands that messages do not represent the webmaster opinion, and are not "authorised" in any ...


5

Would rewriting HTTP addresses as HTTPS work? Only if the webserver hosting the images accepts https as well as http. I would say the solution is to grab the images, and host a copy yourself, which you serve to your clients. Take the URL (or parse the CSS for images), download a copy, and substitute.


5

If someone else is interested, given two sites XA and XB, if XB has an iframe of XA: XA's frame-ancestors must contain XB XB's child-src must contain XA So, frame-ancestors is used when you want that a site is able to load your site in an iframe, while child-src is used when you want to allow your site to be able to load a specific site in an iframe.


4

Maybe it's best to explain the problem with mixed content. A lot of websites will store the login state into the session, and if an attacker has the session-id, he can impersonate the logged in user. The session-id must be sent along with each request, so the server can recognize the user, this will usually be done with a cookie containing the session-id. ...


4

Yes, it does add to security and yes it should be done but security is often neglected over usability. For example the Chrome notification is barely even present as opposed to the firefox popup. More importantly, to actually prevent such a threat the browser must not only notify the average user (who would have no idea what's doing on) but also give the ...


3

To add to the good points from @CodesInChaos: there was a much older mechanism to support signed Javascript. This comes from the days of Netscape 4 and it is still documented, but it is unclear whether this is still supported in Firefox. Internet Explorer never supported it, although the people at Microsoft toyed with the idea. The system piggybacked on the ...


3

Actually, tylerl, the browser does know what type of information a resource is intended to convey. The obvious risk is that information is exposed in the request (once javascript is injected into the page, it's trivial to inject data into the URL without changing the functionality, e.g. img.src=img.src+'?session=1234'; ) and it can therefore be used for ...


3

Depends on what you consider a vulnerability. If the images you load via HTTP are confidential, then sending them via plain HTTP violates their confidentiality. If the images you load via HTTP must preserve their integrity, then sending them via plain HTTP allows an attacker to modify them. This of course all depends on your use-case. There are some ...


3

If you take a look at the page source (e.g. through Chrome's fine 'inspect element' tool), you can see that the style sheet for the page specifies certain image elements. EDIT: bobince is correct, my apologies. The problem is indeed that some of the images are served through http: background:url(http://devimages.apple.com/global/elements/layout/forums/...


3

If it gets resources from a site like a CDN the certificate will be verified against the URL of this resource, in this case the CDN. The URL of the HTML file embedding these resources does not matter in this case, only the URL of the resource itself. ... with a protocoless path A path like //host/page instead of http://host/page or https://host/page ...


3

Mixed-content warnings occur when an HTTPS page requests the loading of a resource over HTTP. This is dangerous because the insecure resources are vulnerable to alteration by an active attacker or eavesdropping by a passive attacker, which violates the user's expectation of security for an HTTPS page. An anchor <a> link does not cause any resource to ...


3

If the linked resource is an image or a script, often the main concern is not that an attacker could read it, but that an attacker could hijack the request and inject a modified version of the resource to change the look or behavior of the page - scripts especially, as they could be modified to do something malicious like redirecting the user to another ...


2

The reasoning behind this is that in most cases, the unsecured content is only ad banners, and will not be of any concern. Thus IE allows insecure images on a otherwise secure page by default. Note that its NOT possible to run an image as JavaScript or executeable code, so a unsecured image cannot affect the page contents on a otherwise secure page. Other ...


2

It's a server configuration issue. No, I don't know why your server is configured to do this, since it's generally a bad idea. Using my general-purpose HTTP diagnostic tool, wget, to retrieve https://www.w1office.com/CSS/all.min.css, I get: Connecting to www.w1office.com|91.151.215.29|:443... connected. HTTP request sent, awaiting response... 200 OK ...


2

I'm not a big-time expert on this. But I can give you a small explanation with my 3year as a server admin and technologist to a web development company. The script may be a unified login check like Google does for all of its products. The reasons for chrome to report it as unsafe are - It is being loaded over HTTP not HTTPS. - The requested script or ...


2

A possible scenario is that a MITM replaces an image with one that exploits an RCE (remote code execution) vulnerability in the user's browser. Here's an example of such vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-2416 --basically you can serve a crafted image containing executable code and have that code executed on older versions of macOS and ...


1

When you see such warnings, you can use the page inspection tool of the Web browser (ctrl-shift-i in Chrome) to analyse the problem. In Google Chrome, select Security tab in the Inspection window, then reload, then go to the mixed content page (Network tab with a filter "mixed-content:something", like mixed-content:all). The warning in the Console (in the ...


1

No, not unless you are using a browser that does not block unauthenticated sources (i.e. plain HTTP) when loading an authenticated source (i.e. HTTPS). Most modern browsers will do this. The error in this case is: Mixed Content: The page at 'https://web.archive.org/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://...


1

Look at the actual request that is sending the form data. That link is HTTP, hence you are in danger. "Mixed content" warnings are given when a website supports HTTPS ony partially, that is it fetches/sends some contents over HTTP, which can be intercepted, sniffed or changed by an attacker.


1

In the case of an HTTPS iFrame from a different domain, two distinct information sources are accessed. The purpose of Microsoft's error message in the developer console may just be to remind unexperienced developers that the information source in the HTTPS iFrame might need better protection. In the case of an HTTPS script no additional information source ...


1

Since you have no control over how the browser checks for mixed content you have to have all content load over SSL, otherwise you will get mixed content warnings. You don't have to give up your private keys to a CDN if they already provide an HTTPS endpoint. The only difference is that you don't get your own custom domain. That, I think, is a pretty ...


1

Another reason why warning about mixed content is a good idea is that a MITM can replace an "insecure" image with one that exploits an RCE (remote code execution) vulnerability in the user's browser. Here's an example of such vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-2416 --basically you can serve a crafted image containing executable ...


Only top voted, non community-wiki answers of a minimum length are eligible