tags:

views:

283

answers:

5

We have a site which is accessed entirely over HTTPS, but sometimes display external content which is HTTP (images from RSS feeds, mainly). The vast majority of our users are also stuck on IE6.

I would ideally like to do both of the following

  • Prevent the IE warning message about insecure content (so that I can show a less intrusive one, e.g. by replacing the images with a default icon as below)
  • Present something useful to users in place of the images that they can't otherwise see; if there was some JS I could run to figure out which images haven't been loaded and replace them with an image of ours instead that would be great.

I suspect that the first aim is simply not possible, but the second may be sufficient.

A worst case scenario is that I parse the RSS feeds when we import them, grab the images store them locally so that the users can access them that way, but it seems like a lot of pain for reasonably little gain.

A: 

I don't know if this would fit what you are doing, but as a quick fix I would "wrap" the http content into an https script. For instance, on your page that is served through https i would introduce an iframe that would replace your rss feed and in the src attr of the iframe put a url of a script on your server that captures the feed and outputs the html. the script is reading the feed through http and outputs it through https (thus "wrapping")

Just a thought

Raine
It seems to me that this would leave me in the same situation as I am in now; I'm already showing the content in an HTTPS page - the problem is that there are <img> tags in the content with http:// src values - which don't get shown and cause an annoying message to occur.
El Yobo
well, yes, if you keep the original links to the images, there is no way to avoid the issue. The wrapper script would have to scan the rss feed content for images and remove those. As you mentioned in another comment - you don't want to load the content that causes the popup and show something informative instead. That's the reason for the "script in the middle"
Raine
You may even do this without the iframe, right in your main backend script, but in this case you are waiting for the rss feed to come back before being processed and output on a page. I would do an iFrame so that your page loads asynchronously with the rss feed. There's also ajax option if you want to go there to avoid the iframe. Just curious - what is your backend platform?
Raine
+1  A: 

Simply: DO NOT DO IT. Http Content within a HTTPS page is inherently insecure. Point. This is why IE shows a warning. Getting rid of the warning is a stupid hogwash approach.

Instead, a HTTPS page should only have HTTPS content. Make sure the content can be loaded via HTTPS, too, and reference it via https if the page is loaded via https. For external content this will mean loading and caching the elements locally so that they are available via https - sure. No way around that, sadly.

The warning is there for a good reason. Seriously. Spend 5 minutes thinking how you could take over a https shown page with custom content - you will be surprised.

TomTom
Easy there, I'm aware that there's a good reason for it; I think that IE's behaviour is better than FF in this regard. What I am aiming for is _not_ to load the content; I just want to avoid the intrusive popup style warning and to show something informative in place of the content.
El Yobo
No chance for that - unless you rewrite the HTML on the way out. Any javascript post load attempt already has shown the dialog.
TomTom
+1  A: 

Regarding your second requirement - you might be able to utilise the onerror event, ie. <img onerror="some javascript;"...

Update:

You could also try iterating through document.images in the dom. There is a complete boolean property which you might be able to use. I don't know for sure whether this will be suitable, but might be worth investigating.

UpTheCreek
Interesting, I didn't even know there _was_ an onerror event. I'd have to rewrite the HTML (as it's coming from an external source), but it's already being sanitised with HTML purifier, so adding that as a filter may be possible.
El Yobo
A: 

It would be best to just have the http content on https

Daniel
If I didn't make this clear in my question, the HTTP content is on other people's server's not mine. Specifically, it is <img> links in HTML that I have retrieved from RSS feeds. I have emphasised this in the question now.
El Yobo
Oh ok, would http://www.webproworld.com/webmaster-forum/threads/81513-https-images-and-css-files help at all?
Daniel
+4  A: 

Your worst case scenario isn't as bad as you think.

You are already parsing the RSS feed, so you already have the image URLs. Say you have an image URL like http://otherdomain.com/someimage.jpg. You rewrite this URL as https://mydomain.com/imageserver?url=http://otherdomain.com/someimage.jpg&amp;hash=abcdeafad. This way, the browser always makes request over https, so you get rid of the problems.

The next part - create a proxy page or servlet that does the following -

  1. Read the url parameter from the query string, and verify the hash
  2. Download the image from the server, and proxy it back to the browser
  3. Optionally, cache the image on disk

This solution has some advantages. You don't have to download the image at the time of creating the html. You don't have to store the images locally. Also, you are stateless; the url contains all the information necessary to serve the image.

Finally, the hash parameter is for security; you only want your servlet to serve images for urls you have constructed. So, when you create the url, compute md5(image_url + secret_key) and append it as the hash parameter. Before you serve the request, recompute the hash and compare it to what was passed to you. Since the secret_key is only known to you, nobody else can construct valid urls.

If you are developing in java, the Servlet is just a few lines of code. You should be able to port the code below on any other back-end technology.

/*
targetURL is the url you get from RSS feeds
request and response are wrt to the browser
Assumes you have commons-io in your classpath
*/

protected void proxyResponse (String targetURL, HttpServletRequest request,
 HttpServletResponse response) throws IOException {
    GetMethod get = new GetMethod(targetURL);
    get.setFollowRedirects(true);    
    /*
     * Proxy the request headers from the browser to the target server
     */
    Enumeration headers = request.getHeaderNames();
    while(headers!=null && headers.hasMoreElements())
    {
        String headerName = (String)headers.nextElement();

        String headerValue = request.getHeader(headerName);

        if(headerValue != null)
        {
            get.addRequestHeader(headerName, headerValue);
        }            
    }        

    /*Make a request to the target server*/
    m_httpClient.executeMethod(get);
    /*
     * Set the status code
     */
    response.setStatus(get.getStatusCode());

    /*
     * proxy the response headers to the browser
     */
    Header responseHeaders[] = get.getResponseHeaders();
    for(int i=0; i<responseHeaders.length; i++)
    {
        String headerName = responseHeaders[i].getName();
        String headerValue = responseHeaders[i].getValue();

        if(headerValue != null)
        {
            response.addHeader(headerName, headerValue);
        }
    }

    /*
     * Proxy the response body to the browser
     */
    InputStream in = get.getResponseBodyAsStream();
    OutputStream out = response.getOutputStream();

    /*
     * If the server sends a 204 not-modified response, the InputStream will be null.
     */
    if (in !=null) {
        IOUtils.copy(in, out);
    }    
}
sri
+1 sound response
mdma
Very sound, and I think this is what I'll roll with. We're using PHP, but the implementation will also be trivial. I'll also implement caching on our side, as I don't want to download the image every time someone requests it (for performance and bandwith usage). The suggestions for the security approach are sound (although we'll also apply our standard security model as well as the above) as well. Thanks for your suggestion.
El Yobo