Monday, June 16, 2014

Clickjacking and Java EE: Some Practical Solutions

©Technology Personalized

Introduction

What is Clickjacking?

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to other another page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

What does this mean for Java EE developers?
 
We don't operate inside of a vacuum. HTML/JS technologies are the backbone of most EE applications. This makes them subject to this kind of attack just like any other HTML/JS technologies. In fact, we often abstract away a lot of the underlying HTML/JS from the developer, this can make us more susceptible to this kind of attack unless we are cognizant and diligent in applying defenses.

Fortunately, there are a number of simple things that developers can do to add additional layers of security to their applications in an unobtrusive way. Those methods include adding X-Frame-Options, and frame busting.

X-Frame-Options

The first solution is to add a header to our pages to offer a browser a "suggestion" on how to handle pages that contain frames. The options include DENY, SAMEORIGIN, and ALLOWFROM. The latter is a new addition and may not be supported. The DENY option advises the browser not to allow any content to be displayed if it comes inside a frame. The SAMEORIGIN option advises the browser to only display framed content, if the content is coming from the same origin as the original request. The ALLOWFROM option takes a parameter (URI) that advises that content from a given URI can be framed. As previously noted, this may not be supported on all browsers. You will need to examine your target browser for compliance. Make no assumptions about your users though. They will use a browser of convenience. The implementation of adding the header is simple. The OWASP has come-up with a simple filter to handle the X-Frame-Options.

Frame Busting

The second solution is simple too. It involves using CSS/JS to do something called "frame busting". There are a number of examples on the web. I would recommend that you examine them carefully. I have found that the code I use is simple, elegant, and does not leave a lot of room for attack vectors. This does not imply that it is invulnerable, but does provide a good defense.

In the frame busting method I use, the CSS sets the style attribute body{display:none !important;} on the <body /> tag of the page as soon as the page is loaded. This is followed by a JS function that checks to see if the page is inside a <frame />, if it is then it attempts to set the body as the top location. Thus it breaks the frame. If it is successful, it removes the body{display:none !important;}styling. Otherwise, the <body /> of page will not display. Simple.

Examples

I have created a NetBeans Maven project on Bitbucketclickjacking-examples

The examples include comments and instructions to see the various issues, and possible solutions. Examples include HTML, JSF, and JSP pages. These examples were developed on GlassFish and tested on Apache Tomcat. The code for frame busting is included below for reference using JSF.

Frame Busting Code



References

Thursday, June 12, 2014

JSF 2.2 Tip of the Day: Hidden Field Validation

Hidden Mines

Introduction

How often do you have validators on your hidden fields? I recently performed a security audit of an application that did not have validators associated with the hidden fields on the page. I suspect that the out of sight, out of mind mentality prevailed. Admittedly, I have often short circuited some development and put hidden fields in a JSF page without a validator. My expectation is that the data in the field would be used to provide information that may be needed by the application. However, if these fields have setters... and the results are stored in a database... I think you get the picture.

Methodology

I decided to create a more complex than really necessary example to show how to validate a <h:inputHidden /> field. In the example, you can enter names into an <h:inputText /> which will use JavaScript to update the hidden field. The validation will be activated on form submission. Additionally, a value change listener will update the planet name, and update the planet to the new planet. The validation will prevent putting in planets that don't exist in the enum for current Planets. You can confirm this by entering a bogus name, or poor Pluto that was kicked out of the planetary club.

Code

The code for this example was developed using NetBeans 8.0 IDE on GlassFish 4+ and Apache Tomcat 8+ using JSF 2.2 (Mojarra).

The code for the project can be downloaded from Bitbuckethidden-field-validation


Planets.java



PlanetValidator.java



IndexBean.java



index.xhtml


Popular Posts