Technical information leak - Credentials - Scala

Technical information leak - Credentials - Scala

Need

Protection of sensitive credentials from being exposed

Context

  • Usage of Scala for functional and object-oriented programming in the JVM environment
  • Usage of play.api.mvc for handling HTTP requests and responses in Play Framework
  • Usage of play.api.mvc.ControllerComponents for handling HTTP requests and responses in Play Framework
  • Usage of play.api.mvc.BaseController for creating base controllers in Play Framework
  • Usage of play.api.mvc.Request for handling HTTP requests in Play Framework
  • Usage of play.api.mvc.AnyContent for handling any type of content in Play Framework
  • Usage of play.api.mvc.Action for handling HTTP requests in Play Framework
  • Usage of play.api.mvc.Request for handling HTTP requests in Play Framework
  • Usage of play.api.mvc.AnyContent for handling any type of content in Play Framework
  • Usage of play.twirl.api.HtmlFormat for generating HTML templates in Play Framework

Description

Non compliant code

        import play.api.mvc._

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

  def index() = Action { implicit request: Request[AnyContent] =>
    Ok(views.html.index("Your new application is ready."))
  }

  def login() = Action { implicit request: Request[AnyContent] =>
    val botChatDirectLineSecretKey = "YOUR_DIRECT_LINE_SECRET_KEY"
    Ok(views.html.login(botChatDirectLineSecretKey))
  }
}
        
        

In the above Scala code, the HomeController class has a login method that is responsible for handling login requests. When this method is invoked, it returns a response that includes the BotChat Direct Line Secret Key in plain text.

The botChatDirectLineSecretKey is directly embedded into the HTML response of the login page. The secret key is used to authenticate the bot chat service. However, this key is included in the response in plain text, which can be easily read by anyone who has access to the network traffic or the client-side code.

This is a significant security vulnerability as it exposes sensitive technical information that can be used by an attacker to gain unauthorized access to the bot chat service. This information leakage can lead to a variety of attacks, including but not limited to, impersonation, unauthorized data access, and denial-of-service attacks.

To prevent this information leakage, the secret key should never be included in the client-side code or any network traffic. Instead, it should be securely stored on the server side and used only when necessary to authenticate the bot chat service.

Steps

  • Remove the direct line secret key from the code
  • Store the direct line secret key securely, such as in a configuration file or environment variable
  • Retrieve the direct line secret key from the secure storage when needed
  • Ensure that the secure storage is only accessible to authorized users or processes

Compliant code

        import play.api.mvc._
import play.api.Configuration

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

  def index() = Action { implicit request: Request[AnyContent] =>
    Ok(views.html.index("Your new application is ready."))
  }

  def login() = Action { implicit request: Request[AnyContent] =>
    val botChatDirectLineSecretKey = config.get[String]("botChat.directLineSecretKey")
    Ok(views.html.login(botChatDirectLineSecretKey))
  }
}
        
        

The original code had a vulnerability where the BotChat Direct Line Secret Key was hardcoded into the source code. This is a security risk as it exposes sensitive information that could be exploited by malicious users.

The revised code fixes this vulnerability by removing the hardcoded secret key and instead retrieving it from a secure configuration file using Play's Configuration API. The secret key is stored in the configuration file under the key "botChat.directLineSecretKey".

This approach has several advantages:

1. The secret key is no longer exposed in the source code, reducing the risk of it being leaked. 2. The secret key can be changed without needing to modify and redeploy the application code. 3. Different secret keys can be used in different environments (e.g., development, testing, production) by simply changing the configuration file for each environment.

To further enhance security, the configuration file should be properly secured to prevent unauthorized access. This can be achieved by setting appropriate file permissions and using encryption if necessary.

References