Skip to main content

Insecure object reference - Session management

Need​

Secure session management

Context​

  • Usage of Dart for building cross-platform mobile, web, and desktop applications
  • Usage of Shelf for managing and organizing data in a Node.js application

Description​

Non compliant code​

import 'package:shelf/shelf.dart' as shelf;

Map<String, String> activeSessions = {};

shelf.Response handleRequest(shelf.Request request) {
  var email = request.headers['email'];
  var action = request.headers['action'];

  if(action == 'close') {
    activeSessions.remove(email);
    return shelf.Response.ok('Session closed for $email');
  } else {
    return shelf.Response.ok('Invalid action');
  }
}

The above code is a simple representation of how an insecure object reference vulnerability could be introduced in a Dart backend application using the Shelf framework.

The handleRequest function is designed to handle incoming HTTP requests. It extracts an 'email' and 'action' from the request headers. If the 'action' is 'close', it removes the active session for the user with the provided email.

The vulnerability lies in the fact that the function does not check if the request is coming from the user whose session is to be closed. As a result, if an attacker knows the email of another user, they can send a request with that user's email and the action 'close' to close the other user's active session.

This is an insecure direct object reference (IDOR) vulnerability because direct references to internal objects (in this case, active user sessions) are exposed to users without proper authorization checks. In this case, the 'email' header is a direct reference to the user session object.

Steps​

  • Authenticate the user before allowing them to perform any action. This can be done by checking if the session associated with the user is active.
  • Implement a mechanism to verify if the user has the necessary permissions to perform the action. In this case, the user should only be able to close their own session.
  • Instead of using the email as a parameter to close the session, use the session ID. This ID should be unique and hard to guess.
  • Store the session ID in a secure way, such as in a secure HTTP cookie, and ensure it is sent over a secure connection to prevent interception.
  • Implement a mechanism to invalidate the session ID after the user logs out or after a certain period of inactivity.

Compliant code​

import 'package:shelf/shelf.dart' as shelf;

Map<String, String> activeSessions = {};

shelf.Response handleRequest(shelf.Request request) {
  var sessionId = request.headers['sessionId'];
  var action = request.headers['action'];

  if(activeSessions.containsKey(sessionId)) {
    if(action == 'close') {
      activeSessions.remove(sessionId);
      return shelf.Response.ok('Session closed');
    } else {
      return shelf.Response.ok('Invalid action');
    }
  } else {
    return shelf.Response.forbidden('Invalid session');
  }
}

The updated code now uses a session ID instead of an email to manage sessions. This session ID should be unique and hard to guess, which makes it more secure than using an email address.

The handleRequest function now checks if the session ID exists in the activeSessions map before performing any action. This is a form of authentication, as it verifies that the session is active.

If the session ID exists and the action is 'close', the session is removed from the activeSessions map and a response is returned indicating that the session has been closed. If the action is not 'close', a response is returned indicating that the action is invalid.

If the session ID does not exist in the activeSessions map, a response is returned indicating that the session is invalid. This is a form of authorization, as it prevents users from performing actions on sessions that do not belong to them.

This code should be used in conjunction with secure methods of storing and transmitting the session ID, such as secure HTTP cookies and secure connections, to further enhance security. Additionally, a mechanism should be implemented to invalidate the session ID after the user logs out or after a certain period of inactivity.

References​

Last updated on