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.)
Improve this question
5
  • @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
    Commented Jun 6, 2018 at 10:21
  • Yes - it's your question :) I just wanted to neaten it.
    – user173641
    Commented Jun 6, 2018 at 10:27
  • 1
    I would reject anything not using HTTPS. Let the user host their images on a server with HTTPS.
    – ThoriumBR
    Commented Jun 6, 2018 at 12:33
  • @ThoriumBR so, we would also scan the CSS and reject it if any HTTP links are in it?
    – Joshua Fox
    Commented Jun 6, 2018 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
    Commented Jun 6, 2018 at 16:52

2 Answers 2

Reset to default
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.

Improve this answer
5
  • This is also how eg. bulletin board softwares nowdays do this, with a cache that expires after some days.
    – user155462
    Commented Jun 6, 2018 at 10:43
  • @user155462 Yes, I won't really claim it's my original idea :)
    – vidarlo
    Commented Jun 6, 2018 at 10:44
  • 2
    It wasn't meant like that :D Just that this is a usable good solution
    – user155462
    Commented Jun 6, 2018 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
    Commented Jun 6, 2018 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
    Commented Jun 6, 2018 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).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .