问题
So if some parts of the code are prone to sql injection, at least the user can't write anything to the database if he happens to be using the front end which does not have universal write access to everything?
回答1:
Yes, I would say it's good practice to have users connect using accounts that only allow the least privileges they need to use the site. If your web users should only be reading data from the database then I would definitely create an account that only has read access and have them hit the DB through that.
The more important thing would be to secure your web application. You can still be victim of a devastating SQL Injection attack even if a user does not write to your database (think stolen credit card numbers or passwords).
回答2:
The approach is generally to have different roles, not really users per se. As far as SQL injection attacks, I would concentrate on fixing the problem outright instead of mitigating it through this approach you propose.
回答3:
Yes, however there are a lot of design techniques which can help control your database interface and surface area.
One must assume that the code will generally use the same login for all its operations in a given session (reads and writes). However, if a user is not a writing user, the login used for his session should certainly not have any write rights.
One good way to reduce your surface area exposed to SQL injection is not to have that account be able to update any tables directly in the first place.
With write access through stored procs, for example, the only injection which can happen is executing those procedures with appropriate parameters.
回答4:
Yes. In addition to Abe and Cade Roux's good answers, it can help security auditors prioritize and make forensics easier after an attack.
It allows you to concentrate your security audits on code that uses more privileges -- you can spend more time auditing code that needs write privileges than code that needs read privileges, and even more time on code that requires drop table privileges.
One other nice property of separation of roles is that it makes forensics easier. If you have separation of roles and can identify the attack in the DB logs, you can narrow down which code could have been exploited -- only that code that uses the role associated with the attack in the logs.
回答5:
Most of the time this is overkill, but most of the time you should use parameterised queries which are not prone to SQL injection anyway.
Consider using stored procedures, and a user account that only can call procedures, not run queries directly.
If you need to use direct queries, and can't use parameters for some reason, then yes, you should have a user account that only can read from the database when that is possible.
回答6:
It seems that your idea of SQL injections coming from that silly comic of Bobby Tables.
But in reality, just a reading from the database can be more disastrous than writing.
Also, I have a strong feeling that NOBODY of good fellas who said "it's good practice" used it in the real life. Say, a frontend (in the real, not imaginary life) have to have write access as well.
You're barking wrong tree.
If you have some parts of the code prone to sql injection - CORRECT THESE PARTS. That's the only sane solution.
来源：https://stackoverflow.com/questions/8392890/is-it-a-good-security-practice-to-have-separated-read-and-write-users-for-a-data