2

I allow users of my webapp to provide a URL for their own images. They can also provide CSS which may contain URLs to images.

If these URLs are HTTP then the browser does not show the padlock in the URL bar.

What is the best practice for avoiding this?

  • Rewriting HTTP addresses as HTTPS, including URLs inside CSS? (Perhaps, after checking that the resource exists at the HTTPS address.)
  • Rejecting any URL that is not HTTPS?
  • Copying the image or CSS (with its referenced images) into my system? (This would mean, for better or worse, that the content would not change as the original does.)
Joshua Fox
  • 239
  • 1
  • 10
  • @Joshua Jones Thank you for the edit. Is it OK if I leave URL, URLs, image-URL in default font. It seems that the usage of those words is English rather than a direct code reference (so we *would* have HTTP and HTTPS in code font). – Joshua Fox Jun 06 '18 at 10:21
  • Yes - it's your question :) I just wanted to neaten it. –  Jun 06 '18 at 10:27
  • 1
    I would reject anything not using HTTPS. Let the user host their images on a server with HTTPS. – ThoriumBR Jun 06 '18 at 12:33
  • @ThoriumBR so, we would also scan the CSS and reject it if any HTTP links are in it? – Joshua Fox Jun 06 '18 at 14:18
  • Yes, scan the CSS and if any `http`, `ftp`, `gopher` or whatever else is found, reject and throw an informative error message. – ThoriumBR Jun 06 '18 at 16:52

2 Answers2

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.

vidarlo
  • 12,850
  • 2
  • 35
  • 47
  • This is also how eg. bulletin board softwares nowdays do this, with a cache that expires after some days. – user155462 Jun 06 '18 at 10:43
  • @user155462 Yes, I won't really claim it's my original idea :) – vidarlo Jun 06 '18 at 10:44
  • 2
    It wasn't meant like that :D Just that this is a usable good solution – user155462 Jun 06 '18 at 10:51
  • @user155462 This will avoid Mixed Content warnings, but it will also create the same vulnerability as just using the user's to provide HTTP links. Whenever that cache expires, the attacker has the opportunity to interpose fake images, right? At least if you grab the image when the URL is first given, the user has the opportunity to see if the resulting image is the expected one. – Joshua Fox Jun 06 '18 at 14:19
  • 1
    @JoshuaFox IMO adding fake images for the given URL is a different question from just ensuring that you get a padlock on the browser. If you want to ensure no MITM as well, please either post a different question or update your existing question. I vote for a new question – Limit Jun 06 '18 at 17:34
0

Use Content Security Policy with directive upgrade-insecure-requests: Content-Security-Policy: upgrade-insecure-requests;

Browsers will internally replace all http: requests to https: one. Here you can cee how it works, just open Dev Tool console.

Also you can use Content-Security-Policy-Report-Only: block-all-mixed-content; report-uri /csp_endpoint to find all mixed content, but you neet to get CSP violation reports somewhere (/csp_endpoint).

granty
  • 181
  • 3