Mixed Content error because of a request to adxk.net - google-chrome

I'm developing a small web app (bootstrap + jquery + nginx + api backend) and today I stumped upon a peculiar error in Chrome, on Ubuntu 16.04.
Mixed Content: The page at 'https://localhost/data/' was loaded over
HTTPS, but requested an insecure XMLHttpRequest endpoint
'http://adxk.net/blacklist_tds.php?url=https%3A%2F%2Flocalhost%2Fdata%2F&ref=https%3A%2F%2Flocalhost%2Foverview%2F&country=PL'.
This request has been blocked; the content must be served over HTTPS.
My page serves all content via https and I'm not making this request.
Firefox doesn't seem to do this request.
What (the heck) is adxk.net?

This sounds like the work of a dodgy Chrome Extension to me. Developers can use the chrome.webRequest API to intercept web requests from your tabs and redirect them somewhere else. I recommend you take a look at what you have installed at chrome://extensions/.
If in doubt, create a new Chrome profile by clicking your name in the top right corner, then 'Switch person', then 'Add person'. This will completely isolate you from any rouge extension/plugin.

Related

Odd Behavior on Image Size in HTTPS

I have been learning HTML and CSS and i am creating a WebSite there is a section where I add 3 images, and this images have an odd behavior when displaying.
when I access to the website on Samsung Internet under HTTP i get them as expected: like this
but when I access under HTTPS i get: this
I have notice that it works under HTTP and HTTPS on other browsers like chrome.
This issue is an instance of mixed content that occurs when HTML pages load over a secure HTTPS connection but link to resources (images, CSS, or JS) over an insecure HTTP connection. This is generally triggered by inputting an image within the page that runs over an HTTP connection. When you upload and post images but do not update the image links on the page after getting an SSL certification, the browsers will recognize them as insecure elements.
For your own domain, serve all content as HTTPS and fix your links. Often, the HTTPS version of the content already exists, and this just requires adding an “s” to links – http:// to https://.
For images hosted on other domains, use the site’s HTTPS version if available.
sitechecker

Chrome browser http links on a secure page taking to https domain

We have recently secured a web application with certificates so as to use https. Let us call this WebApp-A. This WebApp-A runs on port 8081. There is another server running at port 8744 on the same box which does not use https. Let us call this WebApp-B. A page on WebApp-A has links to pages on WebApp-B. The links that point to WebApp-B on WebApp-A page start with http and not https as expected. Note that domain for the both are same except the port number. Now the problem we are facing is, when a user clicks on a WebApp-B link on the WebApp-A page, which uses https, it takes to a https url for WebApp-B too, despite source showing the url to start with http. This behavior is seen on Chrome and Firefox, but not on IE. The behavior is inconsistent too. Sometimes it takes to https and sometimes to http. Things work when the URL goes to http but not when it goes to https. Can someone explain this inconsistency?

Chrome extension - Disable Blocking of Mixed Content [duplicate]

This question already has an answer here:
Since v38, Chrome extension cannot load from HTTP URLs anymore, workaround?
(1 answer)
Closed 6 years ago.
So I'm building a Chrome extension that takes images from the current tabs and sends those images to a server to host the image. It works great for many sites, but on major sites like Instagram and Pinterest, it won't work because the browser blocks mixed content (HTTP and HTTPS). I get the following error message in the console:
Mixed Content: The page at 'https://www.instagram.com/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint. This request has been blocked; the content must be served over HTTPS.
I checked this post and it doesn't appear to help me with regards to extensions spcifically: https://productforums.google.com/forum/#!topic/chrome/OrwppKWbKnc
Also, I tried to add the server URL to the permissions in manifest.json and that did nothing for me, either.
My question is this: is there a way for me to have a Chrome extension that allows mixed content for just my server or is my only option to switch my server over to HTTPS?
If you send http request from content scripts, since it lives in the same context with the webpage, it will be restricted by SOP, which is browser behavior.
You could move your http request from content scripts to background page (either by Message Passing or some other trigger like browser Action), since background page lives in the context of the extension, while extension itself can bypass the SOP by adding server URL to permissions.

Mixed content in Chrome and IE

In my HTTPS enabled site I have added an iframe that should show content from my other site, but it is not working under https.
<iframe src="//myothersite.com"></iframe>
In Firefox latest version everything works good.
In Chrome, the iframe isn't loaded and in the console I see these two errors
Mixed Content: The page at 'https://mysite' was loaded over HTTPS, but requested an insecure resource 'http://myothersite.com'.
This request has been blocked; the content must be served over HTTPS.
Failed to load resource: net::ERR_CACHE_MISS
In IE content load incorrectly and I see an alert message; if I click Allow Insecure Content, it loads correctly.
The question is: how I can do that IE and Chrome as in Firefox (load mixed content without any alerts)?
Note: I haven't changed any browser settings.
Actually Firefox has started to do the same: How to fix a website with blocked mixed content
It makes sense. If the user access a site using HTTPS is expecting to have a secured experience, and he may not be aware of parts of the application loading under not secure connections. That is the reason why the browser blocks such inconsistency.
You will need to provide HTTPS on myothersite.com.
Obviously it's best not to have mixed content to prevent MITM attacks but for those who can't control the url this should do the trick:
Change the src="http://linkToUrl.com" to
src="//linkToUrl.com/script.js"
enter image description here
when i set the url :
from a https request, it report error :
Mixed Content: The page at 'https://127.0.0.1/index.html' was loaded over HTTPS, but requested an insecure resource 'http://127.0.0.1:8080/download/1.txt'.
This request has been blocked; the content must be served over HTTPS.
Failed to load resource: net::ERR_CACHE_MISS
when i added the target="_blank" to the url: <a target="_blank" href="http://127.0.0.1:8080/download/1.txt">, it works! , it works!
it's well known that target="_blank" means opening the linked document in a new window or tab or a new request!
I'm sorry this isn't as technical as the other answers, but I had the same problem linking jsquery like this, and for me it fixed just by changing http:// to https://. It may not work, but it worked for me and it might work for you.
Problem is mixed content, the browser won't allow us to just do that.
You need change url from:
http://example.com
to
//example.com
I'm having other complication with CloudFlare, it doesn't load as the file has been cached as http. Just go to CloudFlare and "Purge Everything" in cache tab, or else turn on "Development Mode".

Hosting Facebook iframes on pages on Cloudfront

I've switched my Facebook page to pull an iframe as a result of Facebook's recent announcement that they were supporting iframes in pages. Since you need to host the iframe page outside of Facebook, I figured it would be nice to do using Cloudfront to host the files (an HTML page, a CSS stylesheet and a jpg image). Unfortunately, despite setting the permissions on the Cloudfront files to 744, the iframe page loads correctly in a browser, but when called from Facebook, I get this error message.
When I host the same files on my Media Temple server, the iframe on the actual Facebook page also loads correctly.
Is there a reason why Facebook and Cloudfront don't play together? I haven't been able to find one so far.
Unfortunately Facebook loads the iframe page using an HTTP POST, not an HTTP GET and is not compatible since Amazon has a REST interface and properly uses POST to upload/modify content.
Best,
David Bullock
I ran into this problem today and it caused some headscratching. As David Bullock points out the problem is that Facebook loads the HTML page via a POST request but S3 (and thus by extension CloudFront) won't serve resources in response to this (it returns 405 Method Not Allowed).
You can host your CSS, scripts and images on S3 / CloudFront, but the initial HTML page has to be on some other server. If you're concerned about load or latency from across the globe then you could try implementing a tiny redirector that forwards the Facebook POST request to the CloudFront-cached location (you'll have to return 303 See Other to do this redirection so the browser makes a GET request instead: see RFC 2616).
There is a shockingly easy workaround to the fact that AWS rejects POST requests and the fact that Facebook requires page tabs to be hosted via HTTPS: just redirect the request through https://bit.ly/….
Yes, it's really that easy.
Host the HTML page wherever you like. HTTP is fine.
Create a bit.ly-shortened URL to the page.
Use it—substituting https:// for http://—as the "Secure Page Tab
URL" as you create your Facebook Page Tab.
Activate the tab using this highly-undocumented dialog URL: https://www.facebook.com/dialog/pagetab?app_id=app_id&redirect_uri=bitly_url
Boom: done.
OK, it can be done: but you need to host the images on Cloudfront and the rest of the content on S3. Amazon provides a set of clear instructions on how to this. Issue solved.
Use Cloudfront to trap the 405 error and serve your html as the "Custom Error Response" page to the desired index page
Updated:
This was down voted, however I'm going to help lots of Facebook developers with the following. The final Issue that we had with hosting a facebook application on S3 was with CORS. We fixed the 405's by doing a "Custom Error Response" See this link for details:
http://blog.celingest.com/en/2014/10/02/tutorial-using-cors-with-cloudfront-and-s3/