Nick Coblentz: November 2008

Thursday, November 20, 2008

Page-Level Access Controls in Struts 2 - Part 1

Background

Applications should ensure users are properly authenticated and have sufficient permissions to access pages before content is displayed. Page-level access controls are one security control that enforces this behavior.

Part 1 and 2 of this article describes one of many ways to implement a Struts 2 AuthenticationInterceptor and a RolesInterceptor to verify users have authenticated successfully and belong to an approved role before allowing access to pages. The key features targeted by both interceptors include a default deny policy and a centralized location for defining access control rules.

Struts 2 AuthenticationInterceptor

In the struts.xml file below, the AuthenticationInterceptor is defined and included in the defaultSecurityStackWithAuthentication. The "excludeActions" parameter provided to the interceptor lists the actions that do not require users to be authenticated. In this case, the "Login" and "ProcessSimpleLogin" actions do not require authentication, however the "Internal" page does require authentication.

Struts.xml

(Click the image above to view the XML)

When the AuthenticationInterceptor is called, the interceptor verifies the requested action is in the exclude list or the user has the "authenticated" session variable set to "True."

AuthenticationInterceptor

(Click the image above to view the code)

Finally, to allow users access to authenticated pages, the ProcessSimpleLogin action verifies the submitted credentials and then sets the "authenticated" session variable to "True."

ProcessSimpleLogin

(Click the image above to view the code)

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Monday, November 10, 2008

CSRF Prevention in Struts 2

Background

Cross-site request forgery, one of the OWASP Top 10 vulnerabilities for 2007, is an attack in which a malicious user causes a victim's browser to make a request without the user's consent. This attack is generally propagated by a third party site.

The example below shows how a CSRF attack might affect a web application that allows customers to request rental movies to be mailed to their house.

A customer logs into her movie rental web site and selects some movies to add to her queue. Next, instead of logging out of the application, she types in the address for her favorite news site, reads a few online comics, and does some research on used cars.

Unfortunately, before the customer began her research, an attacker had discovered a persistent cross-site scripting vulnerability on one of the used car sites. The attacker had also exploited this vulnerability to include a simple image tag containing a URL similar to the one below:

<img src="http://www.fakemovierentalsite.com/addMovieToQueueBeginning?movieId=12345" />

When this image tag loaded in the customer's browser, a request was sent to the movie rental application to add an embarrassing movie to the beginning of the customer's queue.

One strategy to address CSRF attacks is to require and validate one-time values included in requests to sensitive functionality. For more information, please view the OWASP explanation found here.

Struts 2 tokenSessionInterceptor

The tokenSessionInterceptor, provided by struts 2, allows developers to add CSRF protection quite easily. In the example below, the tokenSessionInterceptor was added to the interceptor stack. A parameter has been passed to the interceptor to ensure it will not be triggered on each request.

In the ProcessSimpleLogin action, the tokenSessionInterceptor is referenced again. In this case, a parameter is passed to the interceptor to ensure it verifies a valid token has been sent for this action only.

(Click the image above to view the XML)

In order to include the proper token within the page, the <s:token /> tag is included as shown below.

(Click the image above to view the code)

This strategy ensures the ProcessSimpleLogin action executes only if a one-time token has been associated with the user's session, the request includes this token, and the token has been used only one time.

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Sunday, November 2, 2008

Custom Error Pages in Struts 2

Background

When attackers target a particular application, they typically spend some time gathering information about the application's components, framework, and architecture. One way attackers may gather this type of information is through error messages.

Error messages often disclose SQL queries, code fragments, file names, or other sensitive information. An example is shown below.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 xx.xx.xx.xx 10/18/08 17:49:20 clientid=&id= http://www.google.com/search?q=

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '='.

SQL = "SELECT * FROM logins WHERE clientid ="

Data Source = "AFE2003"

The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (40:2) to (40:47) in the template file E:\inetpub\i\somesite\showinv\Application.cfm.

The disclosure of this information can be avoided using custom error pages. Applications, frameworks, or servers can be configured to redirect users to a custom error page that does not disclose stack traces, debugging information, or verbose error messages.

Struts 2 Custom Error Pages

Struts 2 includes an Exception Interceptor in its default stack. Developers can utilize this interceptor to catch errors and redirect users to a page containing a generic error message. One example is shown below.

Custom Error Page