I would like to clarify protection practices for handling database secrets with database connected web application, using Docker containers. The aim is to determine how to protect secrets even if an attacker attains a shell in the context of the application.

My assumptions are:

  • the web application server runs under the context of a webapp user, having the least level of privilege required to serve content.
  • the webapp user needs access to database secrets to authenticate and establish a connection to the database. These could contained within environment variables or mounted in the container filesystem.
  • if the web application is compromised (e.g. remote code execution bug resulting in a shell), the database secrets are accessible in the context of the webapp user.

As some user has to be able to read the secret, is there a pattern where the webapp user can serve pages but does not have access to the web application secrets? For example, a separate webapp_secrets user with read access to the secrets, responsible only for requests requiring database connection / querying.

What is a secure paradigm for preventing disclosure of database secrets if the web application is compromised?

  • 1
    Rather than a separate webapp_secrets user to access the secret needed to authenticate with the database, I suggest you create a new user in the database itself, and limit what that user has access to. You could write prepared statements to do sensitive things like check if a user provided hash+username matches a DB entry, etc. – Daisetsu Oct 29 '18 at 2:20
  • Thanks @Daisetsu, I was not considering authorisation measures to limit damage to the database itself. However, the main concern is the disclosure of any database credentials from the application environment in the event a shell is gained. – user1330734 Oct 30 '18 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.