Skip to main content

Authentication mechanism absence or evasion - Response tampering

Need​

Implementation of a secure and robust authentication mechanism

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;

shelf.Response handleRequest(shelf.Request request) {
  var otp = request.headers['otp'];
  
  // Assume that verifyOTP is a function that checks if the OTP is valid
  if (verifyOTP(otp)) {
    return shelf.Response.ok('Success');
  } else {
    return shelf.Response.forbidden('Invalid OTP');
  }
}

The handleRequest function is a middleware function in the server that handles incoming HTTP requests. It reads the OTP (One-Time Password) from the request headers and verifies it. If the OTP is valid, it sends a response with a success message, otherwise, it sends a forbidden response.

The vulnerability here is that the function doesn't authenticate the response. This means an attacker can intercept the response and modify it to include the success message, bypassing the OTP validation. This is a type of Response Tampering attack.

The attacker doesn't need to know the valid OTP. They just need to intercept the response and change the message to 'Success'. The server will then unblock the user, thinking the OTP was valid.

This vulnerability can lead to unauthorized access and potential data breaches. It's a significant security risk and needs to be fixed.

Steps​

  • Implement a secure server-side session management system. The server should generate a unique session ID for each user after they have been authenticated.
  • Store the OTP in the server-side session. This way, the OTP is never exposed to the client-side and cannot be tampered with.
  • When the client sends the OTP, the server should compare it with the OTP stored in the session. If they match, the server should send a success message. If they don't match, the server should send an error message.
  • Use HTTPS to ensure that the communication between the client and the server is encrypted. This will prevent attackers from intercepting and tampering with the messages.
  • Implement a mechanism to invalidate the OTP after a certain period of time or after it has been used. This will prevent replay attacks.

Compliant code​

import 'package:shelf/shelf.dart' as shelf;
import 'package:shelf/shelf_io.dart' as io;
import 'package:shelf_session/shelf_session.dart';

// Assume that verifyOTP is a function that checks if the OTP is valid
bool verifyOTP(String otp, String sessionOtp) {
  return otp == sessionOtp;
}

void main() {
  var sessionMiddleware = sessionMiddlewareMemory();

  var handler = const shelf.Pipeline()
      .addMiddleware(sessionMiddleware)
      .addHandler(_handleRequest);

  io.serve(handler, 'localhost', 8080);
}

shelf.Response _handleRequest(shelf.Request request) {
  var session = getSession(request);
  var otp = request.headers['otp'];
  var sessionOtp = session['otp'];

  if (verifyOTP(otp, sessionOtp)) {
    session.destroy();
    return shelf.Response.ok('Success');
  } else {
    return shelf.Response.forbidden('Invalid OTP');
  }
}

The updated code now uses the shelf_session package to manage server-side sessions. This package provides middleware for managing sessions using different storage backends. In this case, we're using the in-memory storage backend, which is suitable for development and testing but not for production.

The server generates a unique session ID for each user after they have been authenticated. The OTP is stored in the server-side session, so it's never exposed to the client-side and cannot be tampered with.

When the client sends the OTP, the server retrieves the OTP from the session and compares it with the OTP sent by the client. If they match, the server sends a success message and destroys the session, invalidating the OTP. If they don't match, the server sends an error message.

The communication between the client and the server should be done over HTTPS to ensure that it's encrypted. This will prevent attackers from intercepting and tampering with the messages.

This solution also implements a mechanism to invalidate the OTP after it has been used, preventing replay attacks.

References​

Last updated on