Skip to main content

Lack of isolation methods

Need​

Implementation of isolation methods for running applications

Context​

  • Usage of Scala for building scalable and functional applications
  • Usage of play.api.mvc for handling HTTP requests and building web applications in Play Framework
  • Usage of global execution context for Scala concurrent programming
  • Usage of scala.concurrent.Future for asynchronous programming in Scala

Description​

Non compliant code​

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

class Application extends Controller {
  def index = Action.async {
    Future {
      // Some complex computation
      val result = someComplexComputation()
      Ok(result)
    }
  }

  def someComplexComputation(): String = {
    // Some complex computation code
    "Result"
  }
}

The above code represents a simple Play framework application in Scala. It has an index action which performs some complex computation asynchronously and returns the result. The computation is done in the someComplexComputation method.

The vulnerability here is the lack of isolation methods for running applications. In this case, the someComplexComputation method runs in the same execution context as the rest of the application. This means that if the someComplexComputation method encounters an error or exception, it could potentially crash the entire application or cause other unexpected behaviour.

Additionally, since there is no isolation, the someComplexComputation method has full access to all the application's resources and data. This could lead to serious security issues if the method is exploited by an attacker.

Ideally, the someComplexComputation method should be isolated in its own execution context or even in its own microservice, so that any errors or exceptions it encounters do not affect the rest of the application. It would also limit the method's access to the application's resources and data, improving security.

Steps​

  • Implement isolation methods to run applications in separate threads or processes.
  • Use thread pools or executor services to manage the execution of concurrent tasks.
  • Consider using actors or other concurrency models to achieve better isolation and control over application execution.
  • Ensure proper error handling and fault tolerance mechanisms are in place to handle failures in isolated tasks.
  • Regularly review and update the isolation methods to adapt to changing requirements and best practices.

Compliant code​

import akka.actor.ActorSystem
import play.api.mvc._
import scala.concurrent.{ExecutionContext, Future}

class Application @Inject()(actorSystem: ActorSystem) extends Controller {
  implicit val myExecutionContext: ExecutionContext = actorSystem.dispatchers.lookup("my-context")

  def index = Action.async {
    Future {
      // Some complex computation
      val result = someComplexComputation()
      Ok(result)
    }(myExecutionContext)
  }

  def someComplexComputation(): String = {
    // Some complex computation code
    "Result"
  }
}

The updated code now uses the Akka Actor System to manage the execution of concurrent tasks. The Actor System is a higher-level abstraction over threads and provides better isolation and control over application execution.

The ActorSystem is injected into the Application class. An ExecutionContext is created from a custom dispatcher defined in the Actor System. This ExecutionContext is used to run the Future that performs the complex computation. This ensures that the computation is run in a separate thread, providing isolation from the main application thread.

The custom dispatcher (named "my-context" in this example) should be defined in the application's configuration file. This allows for fine-tuning of the dispatcher's performance characteristics, such as the number of threads, queue size, etc.

This approach provides better isolation for running applications and allows for more control over their execution. It also provides a foundation for implementing further error handling and fault tolerance mechanisms.

References​

Last updated on