In a php/mysql based system I work on, they recently found several SQL injection vulnerabilities. Those come from 3rd party plugins, and I must assume there are more to be discovered.

My major concern is elevation of privileges, as almost all data except user data and credentials come from external systems and are overwritten every few minutes.

With the understanding that this would tackle elevation scenarios only, and that there are many other strategies that should also be followed, please provide feedback if this mitigation strategy would work:

  1. Create a passphrase in a config file, let's call it "admin-salt".
  2. Normal users log-in by providing a password, that is then hashed with a db-stored per-user-random salt and compared to the hash in the db. Admin users on the other hand log in by providing a password, that is hashed both with the random user-salt and the aforementioned admin-salt.

Therefore, to create a new admin user, elevate a user or change an admin users password, the database.users.passwordhash field must be filled with knowledge of the secret admin-salt. This happens programatticly if the user is created or elevated via backend and by an authenticated admin, while an sql injection leaves an admin user with an incorrect password hash.

Additional question: In case that's a viable approach and I didn't miss something obvious, why is it not more common practice?

  • Are you sure that generating an admin's hash is really the only way to compromise your system? How are admins distinguishable from other users? If there's a numeric column like "user_capabilities" that can be changed, that could be changed by the attacker. You should also make sure it isn't possible to read and write files on your server via SQL, for example (LOAD_FILE, OUTFILE, etc.)
    – reed
    Jul 13, 2020 at 12:27
  • @reed: Thank you for your feedback. I know there are many other vectors that need to be taken care of, and while our servers are quite tight, I was curious how to mitigate appspace vulnerabilities from within the app. (The mysql server has no access to the applications file system, so at least that vector is closed.) Jul 13, 2020 at 13:01

1 Answer 1


Yes sounds reasonable. Especially to put salt and pepper in different parts of database and code.

But do not forget:

If the attacker has access to the web server, he can read out all described things using the code and, if necessary, adjust them to his needs. He can determine the algorithms used and use the found hashes to create a customized dictionary attack using a wordlist and the algorithms on the server.

If SQLi already exists and database and code are on the same system, this can mean:

  • That the code is read out
  • Executable code can be uploaded and executed to gain access to the server

A good example of this offers https://www.youtube.com/watch?v=oI_ZhFCS3AQ

So probably you want to double-check that the 3rd party sqli's found are not accessable from outside.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .