For example, You are attacking an application that employs two different servers: an application server and a database server. You have discovered a vulnerability that allows you to execute arbitrary operating system commands on the application server. How can you exploit this vulnerability to retrieve sensitive application data held within the database?

My opinion is, if I can execute arbitrary OS commands then I will try to find the database credentials from the config file and then I will log in. (Indirectly answer is NO).

  • Since the application server has obviously some way to get data from to the database server (otherwise the application could not get its data) you only need to find out how exactly this access is done and the use it yourself. This might be "... find the database credentials from the config file and then I will log in..." as you suggested or it might be done differently, depending on how the database connectivity is exactly done by the application server. Aug 22, 2018 at 5:29
  • @SteffenUllrich I am not sure if above comment is bordering on “helping one break the security of a system”. Aug 22, 2018 at 10:08
  • Theoretically yes. But the difficulties varied. Plain script web apps, standard CRM platform is easier to dig out database password. Additional layer like docker will add a bit of difficulty to look around, etc.
    – mootmoot
    Aug 22, 2018 at 10:18
  • @KrishnaPandey: I essentially only confirmed what the user already suspected and said that there might be other ways to - without going into any kind of details (which would be target specific and thus unknown anyway). I don't think that this has enough detail to really help breaking the security. Aug 22, 2018 at 10:48
  • @SteffenUllrich Thanks, this draws the line for me in helping moderate the questions. Aug 22, 2018 at 11:02

1 Answer 1


In short : Possibly

On the one hand yes, this is a very real risk. With many ordinary application installations and database deployments, this vulnerability will indeed let you access the data.

On the other hand, no, an attacker can be blocked even at this stage. There are a number of techniques to mitigate this risk. For example:

  1. Limited Privilege on OS. The arbitrary commands the attacker is executing on the application server must be executed with a particular user's credentials; if the user account has been configured in accordance with the Principle of Least Privilege, the user account may not have the authority to execute those arbitrary commands. Ideally, the user account will have permission to run the application but do absolutely nothing else.
    Note: SELinux is a powerful technique for further limiting access to OS resources.

  2. Limited Access to DB. Even if an attacker discovers the database credentials, they may not be much use. The database may be configured so these credentials are only valid for that application; so they cannot be used to connect to the database via any other tool. Or, the database may be configured so these credentials are only valid from this one client address; so all the attacker's db connections have to be tunneled through the database server, instead of from the attacker's own system.

  3. There are no stored DB credentials. An application may be designed so that the user enters their credentials at login, for example, and these are used to access the DB. In this situation an attacker on the application server could not connect to the DB, no matter how much OS-level control they have.

  4. DB credentials are stored elsewhere. An application may be configured so that it fetches the DB credentials from a separate service at runtime; this separate service may not allow connections except from the application itself.

Further note : these techniques are not exclusive, so combining them may be a powerful way of limiting an attacker's access. However, each one of these techniques require sophisticated non-default configuration, and a naive deployment is likely to miss out every single one.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.