Skip to main content

Security controls bypass or absence - Data creation

Need​

Enforcement of proper security controls for data creation

Context​

  • Usage of Scala for building scalable and high-performance applications
  • Usage of play.api.mvc for handling HTTP requests and responses in Play Framework
  • Usage of play.api.libs.json for JSON parsing and manipulation in Play Framework
  • Usage of global ExecutionContext for managing concurrent execution in Scala

Description​

Non compliant code​

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

case class Beneficiary(name: String, age: Int)
implicit val beneficiaryFormat = Json.format[Beneficiary]

class PolicyController extends Controller {
  def createPolicy = Action.async(parse.json) { request =>
    val beneficiaries = request.body.validate[Seq[Beneficiary]].get
    val policy = Policy(beneficiaries)
    policyRepository.create(policy).map { _ =>
      Ok(Json.toJson(policy))
    }
  }
}

In the provided Scala code, the createPolicy method in the PolicyController class is responsible for creating a new policy. This method accepts a JSON request, validates it as a sequence of Beneficiary objects, and then creates a new Policy with these beneficiaries.

The vulnerability lies in the fact that there is no control or restriction on the number of beneficiaries that can be associated with a policy. The validate method simply converts the incoming JSON data into a sequence of Beneficiary objects without checking the number of beneficiaries. As a result, an attacker could potentially bypass the intended restriction of having only four beneficiaries per policy by sending a request with more than four beneficiaries. This could lead to the creation of policies with an excessive number of beneficiaries, affecting the integrity of the data sent.

This absence of proper input validation and control mechanisms can lead to potential security issues such as data integrity violation and potential misuse of the system's resources.

Steps​

  • Implement server-side validation to limit the number of beneficiaries that can be created.
  • Add a check in the createPolicy method to ensure that the number of beneficiaries does not exceed the allowed limit.
  • Return an appropriate error response if the number of beneficiaries exceeds the limit.
  • Update the client-side code to handle the error response and display an error message to the user.

Compliant code​

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

case class Beneficiary(name: String, age: Int)
implicit val beneficiaryFormat = Json.format[Beneficiary]

class PolicyController extends Controller {
  val MAX_BENEFICIARIES = 4

  def createPolicy = Action.async(parse.json) { request =>
    val beneficiaries = request.body.validate[Seq[Beneficiary]].get
    if (beneficiaries.length > MAX_BENEFICIARIES) {
      Future.successful(BadRequest("Exceeded maximum number of beneficiaries"))
    } else {
      val policy = Policy(beneficiaries)
      policyRepository.create(policy).map { _ =>
        Ok(Json.toJson(policy))
      }
    }
  }
}

The updated code includes a server-side validation to limit the number of beneficiaries that can be created.

In the PolicyController class, a constant MAX_BENEFICIARIES is defined to specify the maximum number of beneficiaries allowed.

In the createPolicy method, after parsing the beneficiaries from the request body, a check is added to ensure that the number of beneficiaries does not exceed MAX_BENEFICIARIES. If the number of beneficiaries exceeds the limit, a BadRequest response is returned with an error message "Exceeded maximum number of beneficiaries".

If the number of beneficiaries is within the limit, the policy is created as before and a successful response is returned.

This change ensures that the server enforces the restriction on the number of beneficiaries, preventing the bypass of this restriction and maintaining the integrity of the data sent.

The client-side code should be updated to handle the BadRequest response and display the error message to the user.

References​

Last updated on