The users of our website run our Chrome plugin which, amongst other things, performs cross-origin requests via XMLHttpRequest as described on the Chrome extension development pages. This has been running just fine for a few years now. However, ever since our users upgraded to the latest version of Chrome (v38), these requests have failed. Our site runs on HTTPS and some of the URLs loaded via our content script are on HTTP. The message is:
[blocked] The page at 'https://www.ourpage.com/' was loaded over
HTTPS, but ran insecure content from 'http://www.externalpage.com':
this content should also be loaded over HTTPS.
The reported line where the error occurred is in the content script where I'm issuing the HTTP call:
xhr.send(null);
I have no control over the external page and I would rather not remove SSL from our own page. Question: Is this a bug or is there a workaround that I am not aware of?
(Note: The permissions in the manifest were always set to <all_urls> which had worked for a long time. Setting it to http://*/ and https://*/ did not help.)
If possible, use the https version of that external page.
If that is not possible, use the background page to handle the AJAX request (example).
Related
I am making an ASP.NET application and would like to be able for my file upload to allow attachments to be dragged straight from Gmail. The problem is that I cannot load the data from the links dragged in because of cross-origin rules.
There are 2 problems:
First, cross-origin rules prevent me from making requests to the gmail attachment server.
Second, even if I were to make the request with cross-origin, the cookies would not be included.
I am using Chrome and only interested in doing this on my own computers.
One option is I could make a Chrome extension which allows cross-origin requests but only from my website.
Another option would be for my locally hosted server to communicate with Chrome to make the request itself.
Which of these would be the best option and how would I do it?
We recently started having issues with a web app used internally at our organization. Most users have been using Chrome to access the web app. The issue seems to correspond with the release of Chrome 90. The web app has been in place for a couple of years working with previous versions of Chrome without issue in this regard.
The web app uses an embedded iframe from a 3rd-party vendor. The vendor app does an HTTP GET to a URL within our web app to indicate success or failure. We then close the iframe and update our app accordingly. This has worked fine until recently. Now it seems that the HTTP GET from the vendor iframe is being 302 redirected to our login.
Example of 302 redirect
Prior to this and using MS Edge as the browser, the same HTTP GET gets a 200 response and our web app works as expected.
Example of HTTP 200 response
Since other browsers are continuing to work and there have been no significant changes to the web server, web app, or network access, we suspect something has changed with the latest version of Chrome and perhaps stricter security requirements. Why the 302 redirect? Does this have something with our SameSite cookie config? (Up to this point, we have done nothing specific with regards to SameSite).
We found that with the latest updates to Chrome, we had to set the ASP.Net Session cookie headers to include "SameSite=None; Secure".
This article provided the answer: https://web.dev/samesite-cookie-recipes/
We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on localhost. We have a separate HTTPS website that communicates with this application by setting the ImageUrl of a hidden image to the URL of the - this invokes an HTTP request to localhost, which the application picks up on and actions. For example, the site will set the URL of the image to:
http://127.0.0.1:5000/?command=dostuff
This was to work around any kind of "mixed content" messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.
I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:
Mixed Content: The page at 'https://oursite.company.com/' was loaded
over HTTPS, but requested an insecure element
'http://127.0.0.1:5000/?command=dostuff'. This request was
automatically upgraded to HTTPS, For more information see
https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.
I can't find any clear guidance on whether this warning is a "soft fail", and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.
Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
This answer will focus on your main question: Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
The answer is yes.
The blog post you linked to says:
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
That status entry says:
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
So this feature has been delayed, but it is coming.
Going through your question and all comments - and putting myself in your shoes, I would do the following:
Not messing with either the currently working .Net app/localhost server (HTTP), nor the user-facing (HTTPS) front-end.
Write a simple/cheap cloud function (GCP Cloud Function or AWS Lambda) to completely abstract away your .Net app from the front-end. Your current HTTPS app would only call the cloud function (HTTPS to HTTPS - not having to pray anymore that Google will not shut-down mixed traffic, which will happen eventually, although nobody knows when).
The cloud function would simply temporarily copy the image/data coming from the (insecure) .Net app to cloud storage and then serve it straight away through HTTPS to your client-side.
Testing a website locally with a self signed certificate. The cache policy of my static resources is aggressive. When inspecting network requests, images are loaded from cache but CSS/JS files are not.
What is the reason behind this?
I had the same issue recently. I found this bug report on chromium.org:
https://bugs.chromium.org/p/chromium/issues/detail?id=110649
It seems that Chromium browsers (Chrome, Brave, and others) do not cache script files, or rather do not cache them when requested in a particular way. I found that all the scripts I was requesting via jquery ajax calls using dataType: "script" (i.e. requested via xhr request) were never being cached. Safari and Firefox had no problem caching the files.
I did find that any scripts that were loaded inline in <script> tags were cached, so I am changing up my build code to add script tags to the html page for the scripts in question.
I'm guessing that this was deemed a security issue, in that chromium treats a self-signed certificate as a certificate error (even after accepting the cert), and thus the site is not to be trusted fully. I'm not clear as to why script assets embedded in the page are cached.
I am writing a basic web application that uses <iframe> elements for certain features.
The entire site uses https, including the links to and from the iframe, but when I view the website using Google Chrome and right-click on the displayed frame and look at "View Frame Info" --> Connection, I see the following message:
Your connection to www.example.com is not encrypted
The connection uses TLS 1.1.
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
Confusingly, it says that the connection is not encrypted ... and then it says that it IS encrypted.
I thought that whenever you use https://, the content is encrypted. Am I wrong? Or is Google Chrome referring to something else?
I ended up posting this issue to the Chromium bug discussion board and someone there indicated that it's a bug.