Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox
But browser support is only half the solution, don’t forget to implement the server-side, too. Clickjacking, unlike more well-known (and understood) web application vulnerabilities, has been given scant amount of attention despite its risks and its usage. Earlier this year, for example, it was used as an attack on Twitter, but never really discussed as being a clickjacking attack. Maybe because aside from rewriting applications to prevent CSRF (adding nonces and validation of the same to every page) or adding framekillers there just haven’t been many other options to prevent the attack technique from being utilized against users. Too, it is one of the more convoluted attack methods out there so it would be silly to expect non-technical media to understand it let alone explain how it works to their readers. There is, however, a solution on the horizon. IE8 has introduced an opt-in measure that allows developers – or whomever might be in charge of network-side scripting implementations – to prevent clickjacking on vulnerable pages using a custom HTTP header to prevent them from being “framed” inappropriately: X-FRAME-OPTIONS. The behavior is described in the aforementioned article as: If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin. But that’s only IE8, right? Well, natively, yes. But a development version of NoScript has been released that supports the X-FRAME-OPTIONS header and will provide the same protections as are natively achieved in IE8. The problem is that this is only half the equation: the X-FRAME-OPTIONS header needs to exist before the browser can act on it and the preventive measure for clickjacking completed. As noted in the Register, “some critics have contended the protection will be ineffective because it will require millions of websites to update their pages with proprietary code.” That’s not entirely true as there is another option that will provide support for X-FRAME-OPTIONS without updating pages/applications/sites with proprietary code: network-side scripting. The “proprietary” nature of custom HTTP headers is also debatable, as support for Firefox was provided quickly via NoScript and if the technique is successful will likely be adopted by other browser creators. HOW-TO ADD X-FRAME-OPTIONS TO YOUR APPLICATION – WITH or WITHOUT CODE CHANGES Step 1: Add the custom HTTP header “X-FRAME-OPTIONS” with a value of “DENY” or “SAMEORIGIN” before returning a response to the client Really, that’s it. The browser takes care of the rest for you. OWASP has a great article on how to implement a ClickjackFilter for JavaEE and there are sure to be many more blogs and articles popping up describing how one can implement such functionality in their language-of-choice. Even without such direct “how-to” articles and code samples, it is merely a matter of adding a new custom HTTP header – examples of which ought to be easy enough to find. Similarly a solution can be implemented using network-side scripting that requires no modification to applications. In fact, this can be accomplished via iRules in just one line of code: when HTTP_RESPONSE { HTTP::header insert "X-FRAME-OPTIONS" “(DENY || SAMEORIGIN)”} I believe the mod_rewrite network-side script would be as simple, but as I am not an expert in mod_rewrite I will hope someone who is will leave an appropriate example as a comment or write up a blog/article and leave a pointer to it. A good reason to utilize the agility of network-side scripting solutions in this case is that it is not necessary to modify each application requiring protection, which takes time to implement, test, and deploy. An even better reason is that a single network-side script can protect all applications, regardless of language and deployment platform, without a lengthy development and deployment cycle. Regardless of how you add the header, it would be a wise idea to add it as a standard part of your secure-code deployment requirements (you do have those, don’t you?) because it doesn’t hurt anything for the custom HTTP header to exist and visitors using X-FRAME-OPTIONS enabled browsers/solutions will be a lot safer than without it. Stop brute force listing of HTTP OPTIONS with network-side scripting Jedi Mind Tricks: HTTP Request Smuggling I am in your HTTP headers, attacking your application Understanding network-side scripting 9 ways to use network-side scripting to architect faster, scalable, more secure applications
20 Lines or Less #22
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head. Wow! It's been a while since I was able to pull the cycles away from other things to get to the 20LoL. Many apologies to any of you out there that have missed it. Things here have been amazingly busy (in a good way) and I just haven't made the time. There are so many cool iRules to cover, I'll have plenty of fodder in weeks to come, so hopefully things will be more regular. This week we'll cover three cool, short iRules, as always, but this week we have a special request for the 20LoL that I'll be including just for DevCentral's own Joe Pruitt. IE8 Compatibility http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&tpage=1&view=topic&postid=56407#56534 Here's a cool iRule that Joe requested get tossed into the mix for the 20LoL, and I'm more than happy to oblige. This cool rule inspects an incoming user's request to see if they're using IE8. If so, it inserts the necessary headers to force them into IE7 compatibility mode. This can be handy for now since not everything works perfectly with IE8 just yet. when HTTP_REQUEST { # Check if User-Agent header is IE 8 if { [HTTP::header User-Agent] contains "MSIE 8" } { set IE8Resp 1 } else { set IE8Resp 0 } } when HTTP_RESPONSE { if { $IE8Resp } { log "[IP::client_addr]:[TCP::client_port] inserting header" HTTP::header insert "X-UA-Compatible" "IE=EmulateIE7" } } Redirecting from Java Strings http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=56263&view=topic This request in the forums was to expand the scope of an originally straight-forward HTTP redirect rule to do a little bit more inspection, and route people to different places based on the results. It's great to see people not only using but modifying and expanding their iRules as time goes on. Good stuff. when HTTP_REQUEST { if { [HTTP::path] equals "/" }{ if { not ([string tolower [HTTP::query]] starts_with "user=soviet") }{ if { [HTTP::header "User-Agent"] contains "soviet" }{ HTTP::redirect "http://soviet.com/" } } } } Display log messages to your browser http://devcentral.f5.com/s/wiki/default.aspx/iRules/webLog_-_Display_log_messages_to_Web_Browser.html The original version of this iRule comes straight from the iRules CodeShare in the Wiki, linked to above. It's a cool idea of being able to display the messages your request is generating from the server directly to a browser, rather than forcing a developer or admin to repeatedly view the log file for updates while testing / coding. This would be used with some controls in place and in moderation of course, but still a very cool idea. It took a little tinkering to get it under 20 lines, but the functionality should be the same, and we all know I love "squeezing" code. ;) when HTTP_REQUEST { append ::webLogMsg "HTTP URI: [HTTP::uri]" } when HTTP_RESPONSE { if {([IP::client_addr] equals "x.x.x.x") && ([info exists ::webLogMsg]) } { if {[HTTP::header "Content-Length"] > 2000} { HTTP::collect 2000 } else { HTTP::collect [HTTP::header "Content-Length"] } } } when HTTP_RESPONSE_DATA { regexp -indices {(?i) ]*>} [HTTP::payload] BodyLocation HTTP::payload replace [lindex $BodyLocation 1] 1 [concat {> } \ "Client Port: [TCP::client_port] $::webLogMsg" { }] unset ::webLogMsg HTTP::release } Thanks for reading the 20LoL this week. Hopefully you'll be back for more awesome iRules examples in less than 21 lines. #Colin Listening to: Tool - ÆNIMA - Forty Six and 2A Billion More Laughs: The JavaScript hack that acts like an XML attack
Don is off in Lowell working on a project with our ARX folks so I was working late last night (finishing my daily read of the Internet) and ended up reading Scott Hanselman's discussion of threads versus processes in Chrome and IE8. It was a great read, if you like that kind of thing (I do), and it does a great job of digging into some of the RAMifications (pun intended) of the new programmatic models for both browsers. But this isn't about processes or threads, it's about an interesting comment that caught my eye: This will make IE8 Beta 2 unresponsive .. t = document.getElementById("test"); while(true) { t.innerHTML += "a"; } What really grabbed my attention is that this little snippet of code is so eerily similar to the XML "Billion Laughs" exploit, in which an entity is expanded recursively for, well, forever and essentially causes a DoS attack on whatever system (browser, server) was attempting to parse the document. What makes scripts like this scary is that many forums and blogs that are less vehement about disallowing HTML and script can be easily exploited by a code snippet like this, which could cause the browser of all users viewing the infected post to essentially "lock up". This is one of the reasons why IE8 and Chrome moved to a more segregated tabbed model, with each tab basically its own process rather than a thread - to prevent corruption in one from affecting others. But given the comment this doesn't seem to be the case with IE8 (there's no indication Chrome was tested with this code, so whether it handles the situation or not is still to be discovered). This is likely because it's not a corruption, it's valid JavaScript. It just happens to be consuming large quantities of memory very quickly and not giving the other processes in other tabs in IE8 a chance to execute. The reason the JavaScript version was so intriguing was that it's nearly impossible to stop. The XML version can be easily detected and prevented by an XML firewall and most modern XML parsers can be configured to stop parsing and thus prevent the document from wreaking havoc on a system. But this JavaScript version is much more difficult to detect and thus prevent because it's code and thus not confined to a specific format with specific syntactical attributes. I can think of about 20 different versions of this script - all valid and all of them different enough to make pattern matching or regular expressions useless for detection. And I'm no evil genius, so you can bet there are many more. The best option for addressing this problem? Disable scripts. The conundrum is that disabling scripts can cause many, many sites to become unusable because they are taking advantage of AJAX functionality, which requires...yup, scripts. You can certainly enable scripts only on specific sites you trust (which is likely what most security folks would suggest should be default behavior anyway) but that's a PITA and the very users we're trying to protect aren't likely to take the time to do this - or even understand why it's necessary. With the increasing dependence upon scripting to provide functionality for RIAs (Rich Interactive Applications) we're going to have to figure out how to address this problem, and address it soon. Eliminating scripting is not an option, and a default deny policy (essentially whitelisting) is unrealistic. Perhaps it's time for signed scripts to make a comeback.The third greatest (useful) hack in the history of the Web
Developers have an almost supernatural ability to workaround restrictions, even though some of the restrictions on building applications delivered via the web have been akin to a kryptonite. Like Superman fighting through the debilitating effects of the imaginary mineral, they've gotten around those restrictions by coming up with ways to implement functionality and improve the behavior of browsers and thus web applications anyway. The first greatest hack was giving HTTP state. The second? Cookie-based persistence. The third? The CNAME trick. THE PROBLEM The reason the "CNAME trick" came about was a limitation on browser connections to a single host imposed by browsers, but particularly version of Internet Explorer previous to IE8. With only 2 connections per host name allowed and many times that number of objects on a page, the ability of IE in particular but really all browsers to quickly retrieve all those objects and render them was also hampered. This resulted in the appearance that the application performed poorly, when in reality it wasn't the application but the inherent delivery mechanisms that were slow due to limitations beyond the user's, the network admin's, and the developer's control. Users, of course, don't care about any of this. All they know is that the application they are using is slow and they want it fast. And when some of those users are corporate business users, the developers are going to hear about it because the help desk is going to call them when they get barraged with complaints from users. This is the real reason developers develop nearly supernatural powers of hacking; they'll do anything to stop users from complaining. THE HACK Developers all over (including ours inside F5, working on building our application acceleration solution, WebAccelerator) figured that if the browser was going to limit the number of connections to a single host that the answer was simply to trick the browser into thinking it was talking to more than one host. Turns out doing this is rather trivial: simply add multiple CNAMEs for the same host to DNS, and then reference those as the host for some of the objects in the page. So www.example.com becomes www1, www2, www3, and so on. This required changes to the application so that the additional host names were referenced, unless you made use of a proxy-based solution like WebAccelerator and BIG-IP Local Traffic Manager capable of rewriting outbound host names and virtualizing them to appear to the outside world as if they were a single host. THE NEW PROBLEMS This improved application performance, but at the cost of increasing the number of simultaneous connections to the server. This was "bad" in the sense that a web server, even well tuned, can only support X simultaneous connections at a time, and if each user was consuming Y connections per page, the number of concurrent users that could be supported on a single server was decreased by this hack. This made servers less efficient and required additional servers to ensure availability and scale. Along comes AJAX, and the popularity of the "CNAME trick" rose rapidly. This is because AJAX became a way to provide near real-time updates to web browsers on a per-component basis. The result of this is a rich, interactive application that ends up maintaining a connection to the server on a nearly continual basis. So not only is a single application using more connections - and thus server resources - to load a page, it is also consuming more resources and connections throughout its execution. Some web servers aren't good about dealing with virtual hosts. Rather than pretend that a single instance is all the virtual hosts, it will spawn more and more children instances, each one consuming resources until there are so many instances running that each one can handle fewer concurrent users than the parent. The CNAME trick is also difficult to scale. Every time a new CNAME is added, it must be referenced within the application, which often means modifying applications. A costly proposition in terms of time and effort. If the CNAME trick is used as a reactive measure to address poor application performance, the entire application must be modified to reference the new host names. THE SOLUTIONS There are several solutions to the problems created by the CNAME trick, but they all take advantage of the same core principle: a proxy-based mediator. The proxy's job is to mediate for the client and aggregate connection requests to the server and make them more efficient, either by reusing connections to servers or by load-balancing them more efficiently, or by rewriting requests. The advantage of implementing a proxy-based solution proactively is that applications don't necessarily need to be modified if the solution can rewrite host names in outbound responses. Basically, if the proxy is smart enough, it can change the host names in the page before it reaches the browser, and then aggregate and optimize them as the requests for each object come back in, essentially taking advantage of layer 7 switching to route all the requests to the appropriate web server. The problem of additional connections can't be solved without a proxy of some kind. How efficient a web server is at handling the additional connections can be changed with tuning and optimization, but the additional connections and resulting consequences are going to hit that web server regardless without a mediator to deal with them. THE FUTURE This is a great hack, there is no doubt about it. It's one of the best ways to "workaround" the problems with browser limitations. Now that IE8 is increasing the connection limit from 2 to 6, the CNAME hack will be less necessary to combat the perception of poor application performance. But the problem of inefficiency and resource consumption on servers will not go away; in fact, it's likely to get worse as IE8 is adopted over the next year. The increase in connections initiated from browsers will continue to strain the application infrastructure and, in fact, will get worse primarily because not everyone implemented the "CNAME trick" and thus not everyone's infrastructure felt the strain of those increased connections. With IE8 everyone will feel the impact of additional connections upon their application infrastructure - whether they're a small to medium business, a large enterprise, or a service provider.
