Skip to main content

Business information leak - Credentials

Need​

Protection of business credentials and prevention of unauthorized access to sensitive information

Context​

  • Usage of Scala for building scalable and high-performance applications
  • Usage of play.api.mvc for handling HTTP requests and building web applications in Play Framework
  • Usage of global execution context for concurrent programming in Scala

Description​

Non compliant code​

import play.api.mvc._
import scala.concurrent.ExecutionContext.Implicits.global

class HomeController @Inject()(val controllerComponents: ControllerComponents) extends BaseController {

  def login = Action.async { implicit request: Request[AnyContent] =>
    val username = request.body.asFormUrlEncoded.get("username").head
    val password = request.body.asFormUrlEncoded.get("password").head

    Account.authenticate(username, password) match {
      case Some(user) => Ok("Logged in successfully").withSession("username" -> user.username)
      case None => Unauthorized("Invalid credentials")
    }
  }
}

The above code is a basic login function in a Scala backend application using the Play framework. The function login extracts the username and password from the request body and then authenticates these credentials with the Account.authenticate function. If the authentication is successful, it starts a new session with the username stored in it.

This code is vulnerable to business information leak - credentials. The vulnerability lies in the way the application handles user sessions. The application stores the username directly in the session after successful authentication. If an attacker is able to intercept the session data, they can impersonate the user by using the leaked username.

Furthermore, the password is being sent in plaintext within the request body. If the connection is not secured (e.g., no HTTPS), an attacker could potentially intercept the network traffic and retrieve the plaintext password.

This vulnerability could be exploited to gain unauthorized access to sensitive data or internal systems, compromise customer and employee data, financial records, intellectual property, and other sensitive information.

Steps​

  • Avoid storing sensitive information, such as credentials, in plain text.
  • Implement secure authentication mechanisms, such as using strong password hashing algorithms.
  • Use secure communication protocols, such as HTTPS, to protect the transmission of sensitive data.
  • Implement proper input validation and sanitization to prevent injection attacks.
  • Implement rate limiting and account lockout mechanisms to prevent brute-force attacks.
  • Regularly update and patch the application and its dependencies to address any known security vulnerabilities.
  • Implement proper access controls to ensure that only authorized users can access sensitive data or perform privileged actions.
  • Implement logging and monitoring mechanisms to detect and respond to any suspicious activities or unauthorized access attempts.

Compliant code​

import play.api.mvc._
import play.api.libs.crypto.CookieSigner
import scala.concurrent.ExecutionContext.Implicits.global
import org.mindrot.jbcrypt.BCrypt

class HomeController @Inject()(val controllerComponents: ControllerComponents, cookieSigner: CookieSigner) extends BaseController {

  def login = Action.async { implicit request: Request[AnyContent] =>
    val username = request.body.asFormUrlEncoded.get("username").head
    val password = request.body.asFormUrlEncoded.get("password").head

    Account.authenticate(username, BCrypt.hashpw(password, BCrypt.gensalt())) match {
      case Some(user) => Ok("Logged in successfully").withSession("username" -> cookieSigner.sign(user.username))
      case None => Unauthorized("Invalid credentials")
    }
  }
}

The updated code includes several security improvements to address the identified vulnerability:

  1. Password Hashing: The password provided by the user is hashed using the BCrypt algorithm before it is used to authenticate the user. This ensures that the actual password is never stored or transmitted in plain text, reducing the risk of it being intercepted or leaked.

  2. Secure Session Handling: The username stored in the session is now signed using a CookieSigner. This ensures that the username cannot be tampered with once it is stored in the session, providing an additional layer of security.

Please note that this code assumes that the Account.authenticate method has been updated to compare the hashed password with the hashed password stored in the database, rather than the plain text password.

In addition to these code changes, it is recommended to implement secure communication protocols (such as HTTPS), input validation and sanitization, rate limiting, account lockout mechanisms, regular updates and patches, proper access controls, and logging and monitoring mechanisms as part of a comprehensive approach to secure the application.

References​

Last updated on