Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 2 down vote favorite

I have read somewhere that it is better to have two different MySQL logins in order to prevent hacking. What I mean is having one MySQL login for read access (SELECT permission) and another login for write access (INSERT, UPDATE, CREATE, and DELETE permission). Is it beneficial to have it setup like this and would it work with something like a PHP script?

share|improve this question

2 Answers

up vote 4 down vote accepted

Developers make bugs. One (sadly) rather common bug type in Web applications with PHP and SQL is SQL injections. A consequence of such a bug is that hostile outsiders can inject some arbitrary SQL code to be evaluated by the database.

If you have two accounts to access the database and one of them only has read permissions, then any SQL injection bug in requests made by that specific read-only account will only grant read-only access to the attacker.

That's like the inner doors in a submarine. These doors are designed to resist pressure and will be closed in case of emergency. That way, if the hull is pierced, then water will only flood part of the submarine, which will then sink slower, and the chances of survival for the crew will be greatly improved. Using separate read and write accounts for MySQL is the same kind of protection. You'd still prefer not to get hit by a torpedo at all, though; i.e. it is best if you do not allow SQL injections to happen, by using SQL properly (with prepared statements).

share|improve this answer
Stored procedures could be used to further improve security by allowing only the stored procedure to be executed, with user not having any other permissions (not even SELECT). Stored procedure must be defined as executing as a user that only has SELECT permission. You can also do this for write requests. I've heard many banks use this, but I don't know for sure. – Matrix Mar 9 at 19:46
It should be added here that MySQL has many, many more permissions than just read and write. The FILE permission is a particularly important one for a compromised account to not have and is rarely useful for a web application to have. Stick to the bare minimum of permissions your app actually needs. – Ladadadada Mar 9 at 20:45
up vote 0 down vote

Difficult to follow, but have you considered something similar to MAC model

The model is based upon, user or groups permissions are decided on clearance level and data classification levels.

For e.g if the subject clearance level dominates the data-classification level (to a certain tuple in db) he would be denied entry. Rows are returned ONLY if there is a successful match of classification level and matching clearness level.

What it means that a successful sql injection would give attacker only access to a sub-set of data or depending upon how the attack is executed in cases would return him absolute no results (privilege failure). You effectively cancel the attack surface through this technique.

share|improve this answer
1  
I have problems in understanding how MAC can cancel the attack surface. If a user is authenticating to the application and the application is talking to the database on the user's behalf, it means the app has to have the clearance level to access the DB. The problem with SQL injection is the attacker comes through the same application as any other user. Attacker is indistinguishable from any normal user. It is only the input that is different. – void_in Mar 9 at 21:11
@void_in i understand its a tough concept to implement (programing wise) something DoD would use infact they do to secure their environment. What I'm proposing is perhaps a new way of using MAC in web-apps. MAC is about users not applications , thus the problem. One way to get around this that application has access to db for logical reason but its the user who have the access to data in db? The logical has to applied on user-context. – Saladin Mar 9 at 21:14
but the user context only comes into play once the user is login. SQLi most of the time occurs to bypass authentication (although there are other reasons as well). When input is supplied by the attacker, you can't establish the user context there because you don't know who the user is. Once you supply that input to the backend db for user authentication, if the application is vulnerable, it is already too late then. May be I am missing something? – void_in Mar 9 at 21:47
So when unauthenticated data reaches the DB, we expect (DBMS) to react/respond according to MAC principles who is going to do the decision making part. The ACLs for user-privileges rest in the system(in protected mem), its get intercepted and see any useful attributes thats get attached with apps request,(in mac case its clearance and classification data) both would return empty as it never happened as you mentioned<. In such case, the MAC system would drop this request outside its boundary. Make sense. – Saladin Mar 9 at 22:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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