There's something about bacon that just makes some folks happy (me included). Alan is our resident "bacon makes everything better" team member, and so as a team we're always on the lookout for interesting bacon sites. Twitter, too, is full of baconites, and I often find interesting nuggets there on, shall we say, nothing if not eccentric bacon-oriented sites.

After finding Bacolicio.us, however, I became technically intrigued. Given a domain as part of the URI, the site will overlay a very tasty and realistic image of bacon over the requested site. Part proxy, part prank, the site was an amusing diversion into the capabilities of HTML these days.

clip_image002

Where this gets interesting is how the site works. It strips off the domain sent as part of the URI and then builds a page that includes the requested site in an IFRAME with a DIV overlay of the bacon image (which is hosted on S3, by the way, in case you were looking for yet another use case for cloud computing environments).

Sound familiar? Perhaps a bit like modern phishing attacks but in reverse? That's because this entertaining site is very much like current attack models that inject the same type of code into a site, usually via XSS or SQL injection, and use the overlay to hide the fact that they're capturing user names and passwords and silently sending them off to be collected where they will later be used to send Nigerian princes all your money.

The reason I bring that tidbit up is that while the technique of overlaying data/information/images on a page has a variety of actual, real business use, it's not exactly secure. In fact, depending on the implementation it can be quite dangerous, especially if it's implemented in a way that's reusable and easily turned on and off. Any piece of code that includes content external to the document via HTTP or language-specific "include" mechanisms is a potential security hole and should be treated as a possible attack vector.

But there are valid uses for such techniques: important announcements that are only meant to be displayed for specific periods of time, branding, and temporary site status information are among the possible valid uses of such techniques. I'm sure there are a plethora of other examples; that's part of the awesomeness that is the Internet and technology - someone is always coming up with a way to implement something cool using existing technology in a way that's not been thought of before.

A much better, more secure option is to use network-side scripting to insert the overlay. This removes the need to use more dangerous techniques like IFRAMEs and other methods of dynamically including content from an external, possibly (probably) untrusted, source.

The actual implementation of inserting an overlay is a fairly simple thing: find the end of the document and insert the appropriate HTML/CSS code to display the overlay into the document, then return to the user.

I'm including the network-side scripting code I implemented to insert in an overlay on every page served by my local BIG-IP. It finds the tag and replaces it with a DIV containing an image and text for the overlay. The advantage of using network-side scripting to insert the overlay is that it doesn't rely on external content and therefore doesn't open up your application to potential exploitation. It is, in a nutshell, safer than the alternatives.

You should be able to use any network-side scripting technology, such as mod_rewrite, to implement a similar solution. As long as you are able to fully inspect the HTTP payload, and transform it, you, too, can "brandalize" your content.

Or put an image of bacon over every page. As an April Fool's Day joke, of course.

 

Thanks to many of the users here at DevCentral, especially Blondie, who wrote the core find/replace code in the forums for this iRule. You can see the actual iRule running on our (Don and I) BIG-IP here. Note the overlay of the "powered by BIG-IP" and the F5 logo; that's the piece that's inserted by the iRule.

when HTTP_RESPONSE {
HTTP::collect 4294967295
}

when HTTP_RESPONSE_DATA {
set find ""
set replace