I'm working for a forum owner who allows users to submit hotlinked images from other domains in their posts. If they choose to use an http version of the URL, the otherwise clean page becomes insecure in the eyes of a browser, which some percentage of the time triggers a worried email from certain users.
I can't rewrite the urls, since I can't code against the assumption that future off site images will have https available. For the same reason, I can't use protocol relative src attributes. I'm unwilling to fetch and cache the images on our server just so that they can be served over https, because of the computational expense involved.
What can I do? Is there some piece of HTML syntax or some similar which I can use to tell the browser "This image doesn't matter, and doesn't constitute a security threat"?
This isn't possible. The image may not constitute a security threat but MITM attacks could still lead to images other than the intended one being loaded over the network, and who knows what an attacker may want to supplant that image with. My suggestion would be to pass the annoyance on to your users and tell them they can only use https URLs.
Related
Is there a reliable way to stop all browsers from caching an image locally.
This is not (just) about the freshness of the image, but rather a concern about sensitive images being stored on the local drive.
Adding a random url param to the img url as suggested in similar questions does not help because that just ensures the next request is not the last request in cache (at least that is my understanding). What I really need is for the image to never be saved locally or at least not accessible outside the browser session if it is saved.
You need to send appropriate cache-control headers when serving up the response for image request. See this post for information on standard ways to do this in several programming languages.
How to control web page caching, across all browsers?
There is an alternate, and possibly more foolproof yet more complex, approach which would be to directly populate base 64 encoded images data directly into the img src attrbitute. So far as I know this would not be subject to caching, as there is not a separate HTTP request made to retrieve the image. Of course you still need to make sure the page is not cached, which gets back to the initial problem of serving up appropriate headers for primary HTML request.
I have shopping cart script in our site that is setup to be secure (https with SSL certificate). I have links in the script leading to other parts of my site that are not secure (WordPress blog, etc).
In the secure site, if I have links that are not secure ( http ), it triggers a message to user in browser, alerting of unsecured links. If I put the outgoing links in the script as relative links, when the user clicks on them and goes outside of script, it keeps them in secure mode (which we don't want for other parts of our site).
Years ago, I remember having this issue. I think I got around it by using a HTTP Redirect for every outgoing link in the secure site. Using a HTTP Redirect, I would have https://www.example.com/outgoinglink1a redirect to http://www.example.com/outgoinglink1b in the HTTP Redirect. This way, I could put https://www.example.com/outgoinglink1a in the secure site, and when it was clicked, it would lead to http://www.example.com/outgoinglink1b
In modern times, how do I have links in the secure site that lead to other parts of the site that aren't secure, without triggering SSL Error Message to user when they are in Secure part of site? Is using some type of 301 redirect in .htaccess better? Is there another preferred or easier method (than using HTTP Redirects) for accomplishing this?
Thank you for any guidance.
You can use https-2-http redirects to the unsecured site to avoid browser warnings.
But for multiple reasons, safety being one of them, I would really advice against using http and https for the same domain, even if lot of big sites still do it. You would ether have to use different cookies for the secure and the normal site, or the one cookie u use for your shopping cart can't have the secure flag, in which case you really don't need https in my opinion. Also, you will never be able to implement HSTS.
You've already gone to the lengths bought a certificate and set up an https-server, now why not secure the whole site?
Update to answer your question in the comment:
That is of course a deal-breaker, if you rely on those and the hosts haven't implemented https yes (which they probably will sooner or later, or they are going to be out of business)
Depending on what they actually do, you maybe could proxy the request to those scripts and serve them from you https-enabled server. But I would really consider this last a resort.
The slowing down part is mostly just the handshake. If you enable session resumption there shouldn't be too much overhead to actually slow down your site. Make sure your TLS session cache is big enough and that the ticket lifetime is ample.
Of course, your mileage may vary. So make sure you test your https site before going online.
I heard of such horror stories as well, but I think most of the time it's probably due to faulty or at least sub-standard implementation. Make sure you redirect EVERY single http-request to https with the 301 status and you should be fine. For some months now enabling https should actually help with your Google pagerank.
To link to an external site (differnt FQDN) you don't have to implement any trickery to avoid browser warnings - that's just linking to a different site and has nothing to do with mixed content policies.
There is a company I'm working with that says we are slowing down their web hosting software by hosting images on a separate domain.
I've told them what we are doing should only speed them up because there will be less file requests to their server.
They replied by saying that because they use HTML 4.0, their server is having to make image requests on the server side before they send content to the user.
This makes no sense to me and am trying to disprove this claim.
Am I wrong and just crazy?
I've been looking for articles on this for hours and have had no luck.
Proof that their statement is false would be greatly appreciated, and an article on this topic would be even more helpful.
Your mindset is correct. There is nothing about HTML4 that validates their claim in the context you provided us.
When you make a GET request to the server, you pull an HTML page. The browser then parses the document and makes additional requests, as declared in the document. Images are no exception. When it reaches an image, it will make a GET request to retrieve it to the specified URI. If that URI is not on the same domain, it is not going to make a request to the same domain. The server does not make the GET request for you.
Now, they could be doing something special that would cause it to operate more slowly, but nothing about the HTML4 spec would lead to it.
Simply has nothing to do with HTML 4, because you could target every Image in a <img src="http://other-server.de/bla.png" /> Tag. So if you point these tags to your own hosting solution it doesn't slow down their software, except you point these tags to their servers, and the servers fetch the images from the remote server. The browser always load resources from the URL, you put in the tag.
Except they rewrite the HTML code automatically on the fly, so they point to their servers.
EDIT: Maybe the page loads slowly because maybe your Image-Hosting-Server is responding slowly?!
What security holes can appear on my site by including external images via img tag and how to avoid them?
I'm currently only checking the extension and mime-type of image on submission (that can be changed after URL is submitted) and URL is sanitized before putting it in src attribute.
There's probably a differentiation to be made here between who is at risk.
If all you're doing is storing URLs, and not uploading images to your server, then your site is probably safe, and any potential risk is to your users who view your site.
In essence, you're putting your trust in the reliability of the browser manufacturers. Things might be fine, but if a security hole in some browser one of your users uses were to arise that involved incorrectly parsing images that contain malicious code, then it's your users who will end up paying for it (you might find GIFAR interesting).
It comes down to whether you trust the browser manufacturers to make secure software, and whether you trust your users to not upload URLs to images that might contain exploits for certain browsers. What might be secure now might not be secure come the next release.
The primary holes that can be exposed are those where corrupted images cause buffer overflows within the browser, allowing arbitrary code execution.
If you're only putting the images into an <img> tag there shoudln't be any vulnerabilities relating to sending alternative MIME types, but never underestimate the stupidity of some web browser developers...
Well, obviously, you're not doing any checks on the data, so the data can be anything (the mime-type reported by the remote server doesn't necessarily tell the truth). Plus, as you said, the data on the remote server can be changed since you're never looking at it after submission.
As such, if the link is put into lets say an <img src="..."/>, then any vulnerability that a browser might have in the image handling can be exploited.
"Sanitizing" the URL doesn't help with anything: somebody submitting a link that points to a 'bad' image isn't going to attack his own server.
We have several images and PDF documents that are available via our website. These images and documents are stored in source control and are copied content on deployment. We are considering creating a separate image server to put our stock images and PDF docs on - thus significantly decreasing the bulk of our deployment package.
Does anyone have experience with this approach?
I am wondering about any "gotchas" - like XSS issues and/or browser issues delivering content from the alternate sub-domain?
Pro:
Many browsers will only allocate two sockets to downloading assets from a single host. So if index.html is downloaded from www.domain.com and it references 6 image files, 3 javascript files, and 3 CSS files (all on www.domain.com), the browser will download them 2 at a time, with the other blocking until a socket is free.
If you pull the 6 image files off onto a separate host, say images.domain.com, you get an extra two sockets dedicated to download your images. This parallelizes the asset download process so, in theory, your page could render twice as fast.
Con:
If you're using SSL, you would need to either get an additional single-host SSL certificate for images.domain.com or a wildcard SSL certificate for *.domain.com (matches any subdomain). Failure to do so will generate a warning in the browser saying the page contains mixed secure and insecure content.
You will also, with a different domain, not send the cookies data with every request. This can increase performance.
Another thing not yet mentioned is that you can use different web servers to serve different sorts of content. For example, your static content could be served via lighttpd or nginx while still serving your dynamic content off Apache.
Pros:
-load balancing
-isolating a different functionality
Cons:
-more work (when you create a page on the main site you would have to maintain the resources on the separate server)
Things like XSS is a problem of code not sanitizing input (or output for that matter). The only issue that could arise is if you have sub-domain specific cookies that are used for authentication.. but that's really a trivial fix.
If you're serving HTTPS and you serve an image from an HTTP domain then you'll get browser security alert warnings pop up when you use it.
So if you do HTTPS, you'll need to buy HTTPS for your image domain awell if you don't want to annoy the hell out of your users :)
There are other ways around this, but it's not particularly in the scope of this answer - it was just a warning!