How to prevent Sql-Injection on User-Generated Sql Queries

Question

I have a project (private, ASP.net website, password protected with https) where one of the requirements is that the user be able to enter Sql queries that will directly query t

Answer 1

The question is, do you trust your users? If your users have had to log into the system, you are using HTTPS & taken precautions against XSS attacks then SQL Injection is a smaller issue. Running the queries under a restricted account ought to be enough if you trust the legitimate users. For years I've been running MyLittleAdmin on the web and have yet to have a problem.

If you run under a properly restricted SQL Account select convert(varchar(50),0x64726F70207461626C652061) won't get very far and you can defend against resource hogging queries by setting a short timeout on your database requests. People could still do incorrect updates, but then that just comes back to do you trust your users?

You are always taking a managed risk attaching any database to the web, but then that's what backups are for.

Answer 2

If they don't have to perform really advanced queries you could provide a ui that only allows certain choices, like a drop down list with "update,delete,select" then the next ddl would automatically populate with a list of available tables etc.. similar to query builder in sql management studio.

Then in your server side code you would convert these groups of ui elements into sql statements and use a parametrized query to stop malicious content

Answer 3

what about this stuff, just imagine the select is an EXEC

select convert(varchar(50),0x64726F70207461626C652061)

Answer 4

Plenty of answers saying that it's a bad idea but somethimes that's what the requirements insist on. There is one gotcha that I haven't spotted mentioned in the "If you have to do it anyway" suggestions though: Make sure that any update statements include a WHERE clause. It's all too easy to run

UPDATE ImportantTable
SET VitalColumn = NULL

and miss out the important

WHERE UserID = @USER_NAME

If an update is required across the whole table then it's easy enough to add

WHERE 1 = 1

Requiring the where clause doesn't stop a malicious user from doing bad things but it should reduce accidental whole table changes.

Answer 5

here is another example

the hacker doesn't need to know the real table name, he/she can run undocumented procs like this

sp_msforeachtable 'print ''?''' 

just instead of print it will be drop

Answer 6

Event seemingly secure technology like Dynamic LINQ, is not safe from code injection issues and you are talking about providing low-level access.

No matter how hard you sanitize queries and tune permissions, it probably will still be possible to freeze your DB by sending over some CPU-intensive query.

So one of the "protection options" is to show up a message box telling that all queries accessing restricted objects or causing bad side-effects will be logged against user's account and reported to the admins immediately.

Another option - just try to look for a better alternative (i.e. if you really need to process & update data, why not expose API to do this safely?)