If my database user is read only, why do I need to worry about sql injection?

Question

Can they (malicious users) describe tables and get vital information? What about if I lock down the user to specific tables? I'm not saying I want sql injection, but I wonder about old code we have that is susceptible but the db user is locked down. Thank you.

EDIT: I understand what you are saying but if I have no response.write for the other data, how can they see it. The bringing to crawl and dos make sense, so do the others but how would they actually see the data?

Answer 1

'); SELECT * FROM Users

Yes, you should lock them down to only the data (tables/views) they should actually be able to see, especially if it's publicly facing.

Answer 2

Someone could inject SQL to cause an authorization check to return the equivalent of true instead of false to get access to things that should be off-limits.

Or they could inject a join of a catalog table to itself 20 or 30 times to bring database performance to a crawl.

Or they could call a stored procedure that runs as a different database user that does modify data.

Answer 3

Only if you don't mind arbitrary users reading the entire database. For example, here's a simple, injectable login sequence:

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text'

if(RowCount > 0) {
     // Logged in
}

I just have to log in with any username and password ' or 1 = 1 to log in as that user.

Answer 4

Be very careful. I am assuming that you have removed drop table, alter table, create table, and truncate table, right?

Basically, with good SQL Injection, you should be able to change anything that is dependent on the database. This could be authorization, permissions, access to external systems, ...

Do you ever write data to disk that was retrieved from the database? In that case, they could upload an executable like perl and a perl file and then execute them to gain better access to your box.

You can also determine what the data is by leveraging a situation where a specific return value is expected. I.e. if the SQL returns true, execution continues, if not, execution stops. Then, you can use a binary search in your SQL. select count(*) where user_password > 'H'; If the count is > 0 it continues. Now, you can find the exact plain text password without requiring it to ever be printed on the screen.

Also, if your application is not hardened against SQL errors, there might be a case where they can inject an error in the SQL or in the SQL of the result and have the result display on the screen during the error handler. The first SQL statement collects a nice list of usernames and passwords. The second statement tries to leverage them in a SQL condition for which they are not appropriate. If the SQL statement is displayed in this error condition, ...

Jacob

Answer 5

Yes, continue to worry about SQL injection. Malicious SQL statements are not just about writes.

Imagine as well if there were Linked Servers or the query was written to access cross-db resources. i.e.

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary;