Skip to main content

Insecure session management - CSRF Fixation

Need

Secure session management and protection against CSRF Fixation

Context

  • Usage of Java 8 for developing applications with enhanced features and performance
  • Usage of javax.servlet-api for building Java web applications with Servlets

Description

Non compliant code

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class TransactionController {

public void processTransaction(HttpServletRequest request, HttpServletResponse response) {
String publicKey = request.getHeader("Authorization");
String transactionId = request.getParameter("transactionId");
HttpSession session = request.getSession();
session.setAttribute("publicKey", publicKey);
session.setAttribute("transactionId", transactionId);

// Process the transaction
// ...
}
}

The above Java servlet code is susceptible to CSRF Fixation. The servlet is responsible for processing transactions, and it does so by retrieving the public key from the Authorization header and the transaction ID from the request parameters. It then stores these values in the session.

The vulnerability lies in the fact that the public key is always the same for payment links. This means that an attacker can trick a victim into clicking a malicious link or button that initiates a transaction with the attacker's public key. When the victim completes the transaction, the funds will go to the attacker instead of the intended recipient.

Furthermore, the session attributes "publicKey" and "transactionId" are set without any validation or verification. This means that an attacker can set these attributes to any values they want, which can lead to unauthorized transactions.

The attacker can also create a button with the content of a request and trick a user running a transaction to receive the app push notification and complete the request. This is a form of social engineering attack where the attacker manipulates the user into performing actions they didn't intend to.

Steps

  • Implement a secure session management mechanism
  • Use a unique and unpredictable session identifier for each user session
  • Do not rely on public headers or parameters for session management
  • Generate a new session identifier upon successful authentication
  • Invalidate the session and generate a new session identifier upon logout or session timeout
  • Implement CSRF protection mechanisms, such as using anti-CSRF tokens
  • Verify the origin of the request to prevent CSRF attacks

Compliant code

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class TransactionController {

public void processTransaction(HttpServletRequest request, HttpServletResponse response) {
HttpSession session = request.getSession(true);

// Invalidate the current session if exists
if (session != null) {
session.invalidate();
}

// Create a new session for the user
session = request.getSession(true);

// Generate a new session identifier upon successful authentication
String newSessionId = session.getId();

// Set the new session ID
session.setAttribute("sessionId", newSessionId);

// Generate a unique and unpredictable CSRF token for this session
String csrfToken = generateCSRFToken();
session.setAttribute("csrfToken", csrfToken);

// Process the transaction
// ...
}

private String generateCSRFToken() {
// Implement a secure method to generate a unique and unpredictable CSRF token
// ...
}
}

The fixed code implements a secure session management mechanism. It does not rely on public headers or parameters for session management. Instead, it generates a new session identifier upon successful authentication.

The request.getSession(true) method is used to create a new session for the user. If a session already exists, it is invalidated using session.invalidate(), and a new session is created.

A unique and unpredictable CSRF token is generated for each session using the generateCSRFToken() method. This CSRF token should be included in every state-changing request (e.g., a transaction) to verify the origin of the request and prevent CSRF attacks.

The new session ID and CSRF token are stored in the session attributes, which are only accessible to the server. This ensures that even if an attacker manages to steal a user's session cookie, they will not be able to forge a valid request without the CSRF token.

Remember to validate the CSRF token on the server side before processing any state-changing request. If the token is not present or does not match the one stored in the session, the request should be rejected.

References