Is directly executing SQL bad app design? - sql

Question

I'm developing an iOS application that's a manager/viewer for another project. The idea is the app will be able to process the data stored in a database into a number of visualizations-- the overall effect being similar to cacti. I'm making the visualizations fully user-configurable: the user defines what she wants to see and adds restrictions.
She might specify, for instance, to graph a metric over the last three weeks with user accounts that are currently active and aren't based in the United States.
My problem is that the only design I can think of is more or less passing direct SQL from the iOS app to the backend server to be executed against the database. I know it's bad practice and everything should be written in terms of stored procedures. But how else do I maintain enough flexiblity to keep fully user-defined queries?
While the application does compose the SQL, direct SQL is never visible or injectable by the user. That's all abstracted away in UIDateTimeChoosers, UIPickerViews, and the like.

Answer 1

Is all of the data in the database available to all of the users, or do you only permit each user to access a subset of the data? If the latter, simply restricting the database login to read-only access isn't enough to secure your data.
As a trivial example, a user could compromise your interface in order to submit the query SELECT password, salt FROM users WHERE login = 'admin', hijack the response to get at the raw data, and brute force your admin password. As the popularity of an app grows, the pool of malicious users grows more than linearly, until eventually their collective intelligence exceeds that of your team; you shouldn't put yourself in a situation where success will be your downfall.
You could take the SQL query sent by the client application and try to parse it server-side in order to apply appropriate restrictions on the query, to fence the user in, so to speak. But getting there would require you to write a mini SQL parser in your server code, and who wants to do all that work? It's much easier to write code that can write SQL than it is to write code that can read it.
My team solved a similar problem for a reporting interface in a rather complex web application, and our approach went something like this:
Since you already intend to use a graphical interface to build the query, it would be fairly easy to turn the raw data from the interface elements into a data structure that represents the user's input (and in turn, the query). For example, a user might specify, using your interface, the condition that they want the results to be confined to those collected on May 5, 2010 by everyone but John. (Suppose that John's UserID is 3.) Using a variant of the JSON format my team used, you would simply rip that data from the UI into something like:
{ "ConditionType": "AND",
"Clauses": [
{ "Operator": "Equals",
"Operands": [
{ "Column": "CollectedDate" },
{ "Value": "2010-05-05" }
]
},
{ "Operator": "NotEquals",
"Operands": [
{ "Column": "CollectedByUserID" },
{ "Value": 3 }
]
}
]
}
On the client side, creating this kind of data structure is pretty much isomorphic to the task of creating an SQL query, and is perhaps somewhat easier, since you don't have to worry about SQL syntax.
There are subtleties here that I'm glossing over. This only represents the WHERE part of the query, and would have to live in a larger object ({ "Select": ..., "From": ..., "Where": ..., "OrderBy": ... }). More complicated scenarios are possible, as well. For example, if you require the user to be able to specify multiple tables and how they JOIN together, you have to be more specific when specifying a column as a operand in a WHERE clause. But again, all of this is work you would have to do anyway to build the query directly.
The server would then deserialize this structure. (It's worth pointing out that the column names provided by the user shouldn't be taken dirty – we mapped them onto a list of allowed columns in our application; if the column wasn't on the list, deserialization failed and the user got an error message.) With a simple object structure to work with, making changes to the query is almost trivial. The server application can modify the list of WHERE clauses to apply appropriate data access restrictions. For example, you might say (in pseudo-code) Query.WhereClauses.Add(new WhereClause(Operator: 'Equals', Operands: { 'User.UserID', LoggedInUser.UserID } )).
The server code then passes the object into a relatively simple query builder that walks the object and splits back an SQL query string. This is easier than it sounds, but make sure that all of the user-provided parameters are passed in cleanly. Don't sanitize – use parameterized queries.
This approach ultimately worked out really nicely for us, for a few reasons:
It allowed us to break up the complexity of composing a query from a graphical interface.
It ensured that user-generated queries were never executed dirty.
It enabled us to add arbitrary clauses to queries for various kinds of access restrictions.
It was extensible enough that we were able to do nifty things like allowing users to search on custom fields.
On the surface, it may seem like a complex solution, but my team found that the benefits were many and the implementation was clean and maintainable.

Answer 2

EDIT: I have come to dislike my answer here. I agree with some of the commenters below, and I would like to recommend that you build "Query" objects on the client and pass those to a web service which constructs the SQL statement using prepared statements. This is safe from SQL injection because you are using prepared statements, and you can control the security of what is being constructed in the web service which you control.
End of Edit
There is nothing wrong with executing SQL passed from the client. Especially in query building situations.
For example, you can add as many where clauses by joining them with "AND". However, what you should not do is allow a user to specify what the SQL is. You should instead provide an interface that allows your users to build the queries. There are a couple reasons this is advantageous:
Better user experience (who wants to write SQL other than developers?)
Safer from injection. There is just no way you could possibly filter out all dangerous SQL strings.
Other than that, it's absolutely fine to execute dynamic SQL instead of using a stored procedure. Your view that everything should be written in terms of stored procedures seems misguided to me. Sure, stored procedures are nice in a lot of ways, but there are also many downsides to using them.
In fact, overuse of stored procs sometimes leads to performance problems since developers reuse the same stored procedure in multiple places even when they don't need all the data it returns.
One thing you might want to look into though is building the SQL on the server side and passing over some kind of internal representation of the built query. If you have some kind of web service which is exposed and allows your client to run whatever SQL it wants to run, then you have a security concern. This would also help in versioning. If you modify the database, you can modify the web service with it and not worry about people using old clients building invalid SQL.

Answer 3

I see this fully user-configurable visualizations more like building blocks.
I wouldn't pass direct sql queries to the back-end. I would make the user send parameters (wich view to use, filters in the where clause, so on). But letting the user inject sql it's a potential nightmare (both for security and maintenance)

Answer 4

If you want to let users send over actual sql, try filtering words like "drop and truncate." If you have to allow deletes, you can enforce that they use a primary key.

Answer 5

There is nothing wrong about an application sending SQL commands to a database, as long as you are aware of injection issues. So don't do this in you're code:
(Pseudocode)
String sqlCommand = "SELECT something FROM YOURTABLE WHERE A='" + aTextInputFieldInYourGui + "'";
cmd.execute(sqlCommand);
Why not? See what happens if the user enters this line into aTextInputFieldInYourGui
' GO DELETE * FROM YOURTABLE GO SELECT '
(assuming your DB is MS SQL Server here, for other RDBMS slightly different syntax)
Use prepared statements and Parameterbinding instead
(Pseudocode)
String sqlCommand = "SELECT something FROM YOURTABLE WHERE A=?";
cmd.prepare(sqlCommand);
cmd.bindParam(1, aTextInputFieldInYourGui);
cmd.execute();
Regards