Nick Coblentz

Friday, January 23, 2009

OWASP's XSS Prevention Cheat Sheet

The Open Web Application Security Project (OWASP) has recently released a XSS (Cross Site Scripting) Prevention Cheat Sheet. This cheat sheet helps developers identify how and when to output encode or escape untrusted user data when including it within a page. I am particularly excited about this resource because it not only discusses the case in which HTML encoding is necessary, but also helps layout rules or conditions for using JavaScript, CSS, Attribute, and other encoding schemes.

It is important for developers to understand that the appropriate encoding scheme must be applied based on the context in which untrusted user data is being included within the page.

As a side note, RSnake's XSS cheat sheet, used by security staff to identify cross-site scripting attacks, has been around for a while. These two cheat sheets seem to compliment each other well.

Friday, December 19, 2008

Page-Level Access Controls in Struts 2 - Part 2

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 RolesInterceptor

In Part 2 of the page-level access controls article, a RolesInterceptor has been added to the struts.xml file. The "roleActions" parameter, passed to the interceptor, contains a list of actions allowed for each role. The "*" role indicates that any role can access the action.

Struts.xml

(Click the image above to view the XML)

Similar to the AuthenticationInterceptor, the RolesInterceptor verifies all users are allowed access to a particular page or validates that the user's "role" session variable matches one of the roles allowed for the action requested.

RolesInterceptor

(Click the image above to view the code)

In the ProcessSimpleLogin action, the "role" session variable has been added to include the name of the role that the user belongs to.

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:

Thursday, November 20, 2008

Page-Level Access Controls in Struts 2 - Part 1

Background

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