« May 2009 | Main | July 2009 »

10 posts from June 2009


Set X-Frame-Options to Ward Off Clickjackers

JavaScript framekillers (aka framebusters) are simple scripts that you can add to web pages that prevent your site's pages from being framed by another site. Clickjacking extends this framing technique a little further by tricking users into doing terribly unwanted things. When release candidate 1 of Internet Explorer 8 was released, Microsoft introduced a combination browser/web server technique for guarding against clickjacking by utilizing a new HTTP Response Header called 'X-Frame-Options'. Although it only works with IE8 (and not earlier versions of Internet Explorer), it does address problems in IE that render 'traditional' javascript framekillers useless.

X-Frame-Options can be set with one of two values: "deny", which prevents any kind of framing and "sameorigin", which prevents any kind of framing except from the same URL hosting the framed page.

If you want to set this up on your apache server, add the following line somewhere in your httpd.conf (or in one of your included configuration files).
Header always append X-Frame-Options SAMEORIGIN

If you're using a BigIP load-balancer, you can create an irule that will set this response header as well. The irule is really easy as well:
Setting it up under IIS is easy, too. Simply open up the Internet Service Manager, click the HTTP Headers tab, then click the Add.. button in the Custom Headers section. In the text box for Customer Header Name enter "X-Frame-Options" and in the Custom Header Value enter "DENY" or "SAMEORIGIN".

This solution looks promising. Apple Safari 4, IE8, and Google Chrome 2 already support the X-Frame-Options response header and hopefully Firefox will have native support soon as well. Browsers that don't support the header will ignore it. Until then, some combination of javascript framebusting and setting this header are still necessary.


WebSEAL: Cheap and Easy Way to Rewrite HTTP to HTTPS

One common, but minor, bit of frustration after setting an SSL Quality-of-Protection (QOP) ACL on a webseal junction is that it is not second-nature for an end-user to enter 'https' in the browser bar. Our brains still default to http but once you set that QOP level on your junction, accessing it over an unencrypted link results in one of those relatively generic-looking, default WebSEAL error pages suggesting you re-try using HTTPS instead.

Well, for those of you looking to suppress that error and automatically redirect the browser to an encrypted channel instead, all you need to do is modify the custom error page for WebSEAL and enter some simple javascript that will redirect http to https.

Each webseal instance ships with it's own set of custom error pages, which are typically located in /opt/pdweb//lib/errors/C. The page in question that you'll want to back up and then edit is 38cf0434.html. Replace the head and body with the following:
<html><head><title>Error 403.4</title>

<meta name="robots" content="noindex">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></head>


<script language="JavaScript">
var href = self.location.href;
var originalURL = href.substring(7,href.length);
self.location = 'https://' + originalURL;


This is pretty standard javascript that redirects requests to use https without modifying any other part of the original URL. Give it a try or post something in the comments if you've got something even cooler than this.


Tomcat 4.1.40 Stable Released

SpringSource, err..I mean, the Apache Tomcat team has released what could very well be the last version of tomcat in the 4.1 release tree. Tomcat 4.1.40 was released, addressing two important and three minor security threats as well as some additional bug fixes.

Downloads are available at a mirror nearest you!