So I'm about to create a simple site where users can input their own SQL queries, which I will be running on the server side.
I'm aware of SQL injection attacks and assume this could be fairly risky thing to do.
But (if there is any) what would be a safe way to allow this feature?
e.g. I can think of the following rules I can enforce.
Allow users to only "SELECT" - never allow UPDATE, DELETE (or anything else).
Allow users to only access certain tables (if I know them).
Are there any other security measures I should take?
As well as security issues, performance might be a problem as pointed out by ElectricLlama. You might want to look into getting the query's execution plan in advance, and refusing to run if it looks like the query would be too expensive:
How do I obtain a Query Execution Plan?
Further to the above make sure the user is added to the db_datareader groups and that will make them read only. I guess you will be using a single user to perform that database actions.
You still cause a database failure if the user accidentally does a couple of cross joins:
SELECT *
FROM Table1,Table2,Table3
WHERE Table1.Field1=Table2.Field2
-- Oops I forgot to enter the Table3 Join condition
-- so now I get a cross join which will cause havoc
-- If the table is of appreciative size
But anyway it's still risky! Someone will find a security hole!
Related
I have a Java application that does a POST with the sql query that is typed in the UI and is executed using JDBC. Since the query is user defined, I'm unable to find a way to prevent the SQL injection issue. For instance if this is the query the user issues :
select * from test_table where id=123
a POST is done with this string to the servlet and this is executed as a query. Is there anyway to get around this since there is no restriction on what user can send in?
Thanks
Technically if the user is allowed to write the entire query, it's not an injection attack risk, it's simply an attack risk
Run the query using a database user that has permission only to carry out the types of operations you deem acceptable on the tables you're willing to give access to.
For example, only permit SELECT on tableX, tableY and tableZ. No DML, no DDL and no selecting from any other table
If your dbms of choice doesn't allow fine grained control in this way then instead execute a regular batch script that creates another database containing only a few tables. Permit your users to query this new db. If it does get wrecked it will soon be dropped and replaced by a working one with updated data, by the script. This is also beneficial if placed on another server, it stops your live system from being innocently DOSed by a user executing a duff query that takes up all resource on the server
SQL injection would be passing select * from test_table where id=123 in place of a parameter.
Not sure exactly what information you are letting the application use, but I would suggest granting access only to a specific schema. That would provide a consistent security model.
As others have suggested, this is not SQL injection - I call this a "designed in" SQL injection. How you deal with it depends on the use case:
Design a separate interface that does not require the full SQL statement
As Caius suggested, if you can limit the privs in the DB account to only do what the user can do, that would limit the damage
If this is an administrative interface, you may want to limit the usage of this interface to "trusted" users. If you go that route, you want to be very careful to document that users with this privilege have full access to the database, and provide an auditing mechanism to make sure that that list of users is well known.
It is not realistically possible to limit the SQL statement through validation - its a powerful language, especially in the context of modern databases.
See also this related question
Is there anyway to get around this since there is no restriction on what user can send in?
I'm not sure what you mean by "get around." Is it not the design of this application to allow users to run any query?
If you want to prevent them from running unauthorized queries, then you'll have to implement some Java code in the servlet to check the query and decide whether it's one they're authorized to run.
Some people do this by whitelisting a specific set of known queries. Just match the user's input query against the whitelist.
If they can run a given query with a variety of different constant values, then replace constant values with a ? in both the whitelisted form and in a copy of the user's input SQL query.
If they can run a variety of different queries, like with optional clauses and stuff, so that it's impossible to make a whitelist of finite length, then you'll have to implement a SQL parser in your Java servlet and some kind of business rule engine to decide if their query is authorized before you run it against the real database.
At this point, it seems easier to change the application front-end so that users are not allowed to submit arbitrary SQL queries!
I want to allow SELECT queries to my database, but do not want to allow updates (or drops!).
Is it sufficient to ensure the query starts with SELECT and does not contain a semicolon?
I am using jdbc to execute the query, currently against MySQL, but hope not to limit it to that.
Edit:
I appreciate the caution of using a user who cannot update, but want to know if that is necessary, rather than just superstitious.
A better way to go about this is to create a new account and allow the account certain commands.
You must not execute code submitted by users. Allowing users to submit code is a great way to open yourself up to a denial of service attack, at the very least. For example, an attacker could easily submit a query with a huge Cartesian product guaranteed to bring down your server.
You can safely allow users to specify values, but not code. Then combine the values they enter into your SQL queries by using prepared statements with parameters.
Allowing users to submit SQL queries is as dangerous as shellexec($_GET["cmd"]);
I'm exposing a more or less public API that allows the user to query datasets from a database. Since the user will need to filter out specific datasets I'm tempted to accept the WHERE-part of the SELECT statement as an API parameter. Thus the user could perform queries as complex as she'd like without worrying about a cluttered API interface.
I'm aware of the fact that I would have to catch SQL-injection attempts.
Do you think that this would circumvent the purpose of an API wrapping a database too much or would you consider this a sane approach?
In general, I'd recommend against letting them embed actual sql in their requests
You can allow them to submit where conditions in their request pretty easily:
<where>
<condition "field"="name" "operator"="equal" "value"="Fred"/>
</where>
or something similar.
The value of doing this is muli-fold:
You parse each condition and make sure they're correct before running them
You can create 'fake' fields, such as "full_name" that may not exist.
You can limit the columns they can put conditions on
You can isolate the users from actual changes in your underlying database.
I think the last point is actually most important. The day will come when you'll need to make changes to the underlying schema of the database. Eventually, it will happen. At that point you'll appreciate having some 'translation' layer between what the users send in and the queries. It will allow you to isolate the users from actual changes in the underlying database.
The API should present an 'abstracted' version of the actual tables themselves that meet the users needs and isolate them from changes to the actual underlying database.
I would recommend limitting your users account by modifying the permissions to only allow the user to SELECT from tables. Don't allow updating, inserting, or deleting recordsets. Lock down the user as much as possibile, possibly at a table level.
If the WHERE clause is limited to only a few columns and the comparator is limited to >, = or < then perhaps you could just have the user pass in some extra parameters to represent columns and comparators. You then build the WHERE safely on your server side.
If this is too messy then by all means let them pass a full WHERE clause - it's not too hard to sanitise and if you combine that with running the query under a locked-down account (SELECT only), then any potential damage is limited.
Personally I would not want to allow users to be able to pass in SQL directly to my database, the risks are too great.
If you fail to catch all injection attempts you risk either data theft, someone just destroying your database or hijacking it for some other use that you really dont want.
It seems that one could stop all threat of Sql injection once and for all by simply rejecting all queries that don't use named parameters. Any way to configure Sql server to do that? Or else any way to enforce that at the application level by inspecting each query without writing an entire SQL parser? Thanks.
Remove the grants for a role to be able to SELECT/UPDATE/INSERT/DELETE against the table(s) involved
Grant EXECUTE on the role for stored procedures/functions/etc
Associate the role to database user(s) you want to secure
It won't stop an account that also has the ability to GRANT access, but it will stop the users associated to the role (assuming no other grants on a per user basis) from being able to execute queries outside of the stored procedure/functions/etc that exist.
There are only a couple ways to do this. OMG Ponies has the best answer: don't allow direct sql statements against your database and instead leverage the tools and security sql server can provide.
An alternative way would be to add an additional tier which all queries would have to go through. In short you'd pass all queries (SOA architecture) to a new app which would evaluate the query for passing on to sql server. I've seen exactly one company do this in reaction to sql injection issues their site had.
Of course, this is a horrible way of doing things because SQL injection is only one potential problem.
Beyond SQL Injection, you also have issues of what happens when the site itself is cracked. Once you can write a new page to a web server it becomes trivial to pass any query you want to the associated database server. This would easily bypass any code level thing you could put in place. And it would allow the attacker to just write select * from ... or truncate table ... Heck, an internal person could potentially just directly connect to the sql server using the sites credentials and run any query they wanted.
The point is, if you leverage the security built into sql server to prevent direct table access then you can control through stored procedures the full range of actions availble to anyone attempting to connect to the server.
And how do you want to check for that? Queries sometimes have constant values that would just as easy be added to the query. For instance, I have a database that is prepared to be multi lingual, but not all code is, so my query looks like this:
SELECT NAME FROM SOMETABLE WHERE ID = :ID AND LANGUAGEID = 1
The ID is a parameter, but the language id isn't. Should this query be blocked?
You ask to block queries that don't use named parameters. That can be easily enforced. Just block any query that doesn't specify any parameters. You can do this in your application layer. But it will be hard to block queries like the one above, where one value is a parameter and the other one isn't. You'll need to parse that query to detect it, and it will be hard too.
I don't think sql server has any built in features to do this.
I want to create an SQL sandbox that will allow users to execute arbitrary SELECT queries at a PostGIS database. Essentially, I want to allow users access to psql to play with.
Obviously this is a security disaster if write access is allowed. How can I create a system such that querying data is allowed, but there is no reasonable possibility of a user:
Compromising the data in the database
Gaining broader access to the server
Crippling the system with a query like SELECT * from long_table, long_table, long_table, long_table, long_table, long_table, long_table that will take a life-time to execute
Please be as specific as possible in your answer.
Problems #1 and #2 are handled via explicit GRANTs and REVOKEs of permissions as others have noted.
As for #3,
ALTER ROLE <rolename> SET statement_timeout = '60000'
has always worked well for me. This terminates any query that executes for longer than 1 minute (60000 ms). We discovered this after having a couple of user-written queries in phpPgAdmin cause problems...
Well you just really need to CREATE a ROLE and then GRANT read only access explicitly to the things you want to allow. Anything you don't grant, they can't do (as long as they're not a superuser).
If you've granted readonly access and they're not a superuser, they shouldn't be able to gain access to the underlying system. That is not to say you shouldn't install postgres as an unprivileged user, you should - simply that it shouldn't be necessary to accomplish what you listed.
Ok, you edited your post to include issuing crazy queries. I don't believe postgres currently has a way to limit query resources per user.
You can install postgres as an unprivileged user, and run it that way. This way you take advantage of the existing system permissions to restrict what people can do with the database, including isolating their access to just their own database. See instructions at the bottom of this page:
http://www.postgresql.org/docs/current/interactive/tutorial-start.html
If you automate some part of this, say give people a 'setup postgres' command to run, voila.
For #3 could you write some code that monitors query activity and kill those queries you deem CRAZY based on some criteria using the system views in postgre?
#3 can't be prevented when the user can execute his own piece of SQL. You need a (small) application that executes predefined SQL. Not even VIEW's can help you here, everybody can join a couple of views to cripple your system.