WebSphere Portlet CSRF Protection

TL;DR

No, WebSphere portlet actions aren’t always protected against Cross-Site Request Forgery (CSRF) attacks by default. You need to explicitly enable and configure CSRF protection for each portlet. This guide shows you how.

Understanding the Problem

CSRF allows an attacker to trick a user into performing unwanted actions on a web application they’re currently logged into. WebSphere Application Server provides mechanisms to protect against this, but it’s not automatic for all portlet types or actions.

Solution: Enabling CSRF Protection

1. Check Portlet Type: Determine the type of portlet you’re working with. JSPs and portlets using Struts are handled differently.
   • JSP-based Portlets: These require manual implementation of tokens.
   • Struts-based Portlets: WebSphere can often handle CSRF protection automatically if configured correctly.
2. Configure the web.xml file (for all portlet types): Add a filter to intercept requests and validate CSRF tokens.

   <filter>
     <filter-name>CSRFFilter
     <filter-class>com.ibm.ws.security.web.CSRFFilter
     <init-param>
      <param-name>enabled
      <param-value>true</param-value>
     </init-param>
    </filter>
   
   <filter-mapping>
     <filter-name>CSRFFilter
     <url-pattern>/*</url-pattern>
    </filter-mapping>
   

   This filter intercepts all requests. Adjust the <url-pattern> if you only want to protect specific portlets.

3. Struts Configuration (if applicable): If using Struts, ensure the CSRF interceptor is enabled in your struts.xml file.

   <interceptor name="csrfInterceptor" class="org.apache.struts2.interceptor.CSRFInterceptor" />
   
   <action ... >
     <interceptor-ref name="defaultStack"/>
     <interceptor-ref name="csrfInterceptor"/>
    </action>
   

   Add the csrfInterceptor to your action definitions. The defaultStack usually includes basic interceptors, so adding CSRF on top is common.

4. JSP-based Portlet Implementation (if applicable): You’ll need to manually generate and validate a unique token for each user session.
   • Token Generation: Create a random token when the portlet renders. Store this token in the user’s session.
   • Token Inclusion: Include the token as a hidden field in your forms.

     <input type="hidden" name="csrf_token" value="${sessionScope.csrf_token}" />
     

   • Token Validation: On form submission, compare the submitted token with the one stored in the session. If they don’t match, reject the request.

     Example (simplified Java code):

     String csrf_token = request.getParameter("csrf_token");
     if (!csrf_token.equals(session.getAttribute("csrf_token"))) {
       // Handle CSRF attack - reject the request!
     }
     

5. Testing: Thoroughly test your portlet actions to confirm CSRF protection is working.
   • Attempt to submit a form from a different website (e.g., using a crafted HTML page). The request should be rejected.
   • Verify that legitimate requests are processed correctly.

Important Considerations

• Session Management: Ensure your session management is secure to prevent session hijacking, which could bypass CSRF protection.
• GET Requests: CSRF attacks primarily target GET requests. Avoid using GET requests for actions that modify data. Use POST instead.
• Double Submit Cookie Pattern: Consider implementing the double-submit cookie pattern as an alternative or supplement to token-based protection, especially if you have compatibility constraints.