Skip to main content

Insecure object reference - Session management

Need​

Secure session management

Context​

  • Usage of Java for building robust and scalable applications
  • Usage of javax.servlet for building Java web applications with Servlet technology
  • Usage of javax.servlet.http for handling HTTP requests and responses in Java Servlets

Description​

Non compliant code​

import javax.servlet.*;
import javax.servlet.http.*;

public class CloseSessionServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        String email = request.getParameter("email");
        HttpSession session = SessionManager.getSession(email);
        if (session != null) {
            session.invalidate();
        }
    }
}

The above code represents a Servlet that handles a POST request to close a session. The Servlet retrieves the email parameter from the request, gets the corresponding session, and if the session exists, invalidates it.

The vulnerability lies in the fact that the Servlet does not verify whether the user requesting the session invalidation is the same user that the session belongs to. This means that if a malicious user knows the email of another user, they can send a POST request to this Servlet with the other user's email, and the Servlet will close the other user's session. This is an insecure direct object reference (IDOR) vulnerability, a type of access control vulnerability where an application exposes a reference to an internal implementation object, such as a file, directory, or database key, allowing attackers to manipulate these references to access unauthorized data.

In this case, the internal object is the session, and the reference is the email. By directly referencing the email, the application allows attackers to close sessions of other users. This can lead to denial of service, where legitimate users are unable to use the application because their sessions are constantly being closed by attackers.

Steps​

  • Implement proper authentication and authorization mechanisms to ensure that only authorized users can access the CloseSessionServlet.
  • Do not rely solely on the email parameter to identify the session to be closed. Instead, use a unique session identifier that is securely generated and associated with each user's session.
  • Ensure that the session identifier is not exposed or guessable by an attacker.
  • Implement proper access control checks to ensure that a user can only close their own session and not the sessions of other users.
  • Consider implementing additional security measures such as session expiration timeouts and session revocation mechanisms.

Compliant code​

import javax.servlet.*;
import javax.servlet.http.*;

public class CloseSessionServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        HttpSession currentSession = request.getSession(false);
        if (currentSession != null) {
            String currentEmail = (String) currentSession.getAttribute("email");
            String email = request.getParameter("email");
            if (currentEmail != null && currentEmail.equals(email)) {
                currentSession.invalidate();
            } else {
                response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Unauthorized request");
            }
        } else {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "No active session");
        }
    }
}

The updated code now includes proper authentication and authorization mechanisms to ensure that only authorized users can access the CloseSessionServlet.

The doPost method first retrieves the current session associated with the request. If there is no current session, it sends an HTTP 401 Unauthorized error response.

If there is a current session, it retrieves the email associated with the current session and compares it with the email parameter from the request. If they match, it means that the user is trying to close their own session, so the session is invalidated. If they don't match, it means that the user is trying to close someone else's session, which is not allowed, so it sends an HTTP 401 Unauthorized error response.

This way, we ensure that a user can only close their own session and not the sessions of other users. We also ensure that the session identifier is not exposed or guessable by an attacker.

Additional security measures such as session expiration timeouts and session revocation mechanisms should also be considered for further enhancing the security of the application.

References​

Last updated on