Skip to main content

Business information leak - Source Code

Need

Protection of sensitive business information in source code

Context

  • Usage of Scala 2.12 for developing scalable and high-performance applications
  • Usage of javax.inject for dependency injection in Java applications
  • Usage of Play Framework for building web applications
  • Usage of play.api.mvc for handling HTTP requests and responses in Play Framework

Description

Non compliant code

package controllers

import javax.inject._
import play.api._
import play.api.mvc._

@Singleton
class HomeController @Inject()(cc: ControllerComponents) extends AbstractController(cc) {

def index() = Action { implicit request: Request[AnyContent] =>
Ok("Welcome to the Home Page!")
}

def getEmployeeInfo(id: Int) = Action {
val employee = EmployeeDAO.get(id)
Ok(employee.toString)
}

def getCustomerInfo(id: Int) = Action {
val customer = CustomerDAO.get(id)
Ok(customer.toString)
}
}

object EmployeeDAO {
def get(id: Int): Employee = {
// Fetches employee data from the database
}
}

object CustomerDAO {
def get(id: Int): Customer = {
// Fetches customer data from the database
}
}

In the above Scala code, the getEmployeeInfo and getCustomerInfo methods in the HomeController class are fetching sensitive information from the database and directly sending it as a response to the client. This exposes business information and can lead to a potential data leak if an attacker is able to access these endpoints.

The EmployeeDAO.get and CustomerDAO.get methods are used to fetch data from the database. However, they are not checking if the user making the request is authorized to view the requested data, which is a significant security flaw.

Furthermore, the toString methods of Employee and Customer objects may be revealing sensitive information. Depending on how these classes are implemented, they might be exposing more data than necessary (e.g., Social Security numbers, credit card information, etc.).

This code is vulnerable as it does not follow the principle of least privilege, where a user should only have access to the information and resources necessary for their legitimate purpose. It also violates the privacy by design principle, which states that systems should be designed to protect user data by default.

Steps

  • Remove the direct printing of sensitive information in the response
  • Implement proper access control and authentication mechanisms
  • Encrypt sensitive information in the database
  • Implement data anonymization techniques if necessary
  • Apply input validation and sanitization to prevent unauthorized access
  • Implement logging and monitoring to detect and respond to potential leaks
  • Regularly review and update security measures to address new vulnerabilities

Compliant code

package controllers

import javax.inject._
import play.api._
import play.api.mvc._
import play.api.libs.json._

@Singleton
class HomeController @Inject()(cc: ControllerComponents) extends AbstractController(cc) {

def index() = Action { implicit request: Request[AnyContent] =>
Ok("Welcome to the Home Page!")
}

def getEmployeeInfo(id: Int) = Action {
val employee = EmployeeDAO.get(id)
Ok(Json.toJson(employee))
}

def getCustomerInfo(id: Int) = Action {
val customer = CustomerDAO.get(id)
Ok(Json.toJson(customer))
}
}

object EmployeeDAO {
def get(id: Int): Option[Employee] = {
// Fetches employee data from the database
// Returns None if the employee does not exist
}
}

object CustomerDAO {
def get(id: Int): Option[Customer] = {
// Fetches customer data from the database
// Returns None if the customer does not exist
}
}

The updated code includes several changes to address the identified vulnerability:

  1. Removal of Direct Printing of Sensitive Information: Instead of directly printing the employee and customer information, the updated code uses Play's built-in JSON library to convert the data to a JSON format. This allows for better control over what data is included in the response.

  2. Proper Access Control and Authentication Mechanisms: The updated code assumes that proper access control and authentication mechanisms are implemented elsewhere in the application. These mechanisms should ensure that only authorized users can access the getEmployeeInfo and getCustomerInfo endpoints.

  3. Encryption of Sensitive Information: The updated code assumes that sensitive information is encrypted in the database. This means that even if an attacker gains access to the database, they will not be able to read the sensitive information.

  4. Data Anonymization: If necessary, data anonymization techniques can be implemented to further protect sensitive information. This could involve replacing direct identifiers with pseudonyms or other non-identifying data.

  5. Input Validation and Sanitization: The updated code assumes that input validation and sanitization are implemented elsewhere in the application. These measures can help prevent unauthorized access by ensuring that only valid input is accepted.

  6. Logging and Monitoring: The updated code assumes that logging and monitoring are implemented elsewhere in the application. These measures can help detect and respond to potential leaks by tracking who accesses what data and when.

  7. Regular Review and Update of Security Measures: The updated code assumes that security measures are regularly reviewed and updated to address new vulnerabilities. This is a crucial part of maintaining a secure application.

References