1

I'm coming at this from a somewhat beginners viewpoint so if this is an obvious question it's because I didn't know the right terms to search for. Are there DBMS's that provide an alternative interface (say an API) to the usual query language text prompt, that's less flexible and less powerful for simple operations? Ideally any task that involved user input would be handled with a combination of simple queries via this API and logic in the programming language. SQL or another query language would be reserved for either human users or particular nearly-static queries that did not incorporate user input.

Architecturally the lack of a text stream would probably remove simple network transparency, requiring a local "server" acting as dispatch to the real server on the network.

As I said I'm currently a beginner at any of this, but this seems such an obvious design decision that I suspect it either already exists (maybe everywhere), or it is actually impossible in practice. It would be nice to know why.

Added later: To clarify the intent is to access the database without using reflection somewhere. Ideally all possible locations of reflection of user input would be ruled out including any use of the system shell. SQL is just the starting point, but under this logic Shellshock is considered the same type of vulnerability as SQL injection.

davolfman
  • 167
  • 4
  • See also [bobby-tables.com](http://bobby-tables.com/) – Dan Pichelman Feb 16 '15 at 20:31
  • What value do you think this would add? Why should DBMSs support this, and why should DBMS customers want it? –  Feb 16 '15 at 20:37
  • Sure, you would completely avoid SQL injection if the interface to the database wasn't via SQL. That's something of a tautology. – GrandmasterB Feb 16 '15 at 20:59
  • The value in this would be not subjecting user input to a form of reflection in the first place. Also the above topic on parametrized queries in stored procedures seemed to establish that it was not a viable solution, it merely moved the problem into the stored queries. This topic is asking if there's an actual solution that works. – davolfman Feb 18 '15 at 19:46

2 Answers2

3

Although you could avoid "SQL injection" attacks by not using a relational database or not using SQL to query one, they are really part of a broader range of untrusted user input attacks that need to be protected against. Even if you had a NoSQL key / value pair store you could still be vulnerable to an attacker deleting all the data in your store.

The lesson behind the warning against SQL injection attacks is really to not execute user input directly but to sanitise it in some way.

Encaitar
  • 3,053
  • 19
  • 26
  • My thought is that the big problem here is not a lack of cleansed inputs but the way we are using a form of reflection on a string at least partially created from user input. If we get rid of reflection in our interface with outside tools then our strings remain strings and never become executable. I'm thinking this is sorta a structural fix while cleansing inputs is a more direct approach. Also I worry that there's room to screw up and have someone worm their way past my input cleansing. – davolfman Feb 18 '15 at 19:40
  • The way I've seen it done is to use stored procedures and features of the query language / database to fire off requests that automatically have their parameters cleansed. I think, like encryption, this is another area of security that you should leave to the pros and just use their libraries. – Encaitar Feb 18 '15 at 21:27
0

I'm not 100% sure what you are asking, but I'm taking it you are wondering whether you always have to program SQL strings to query a database? If so, that depends on the language you are working with, using C# you can write LINQ statements (Language integrated query) https://msdn.microsoft.com/en-us/library/bb386976%28v=vs.110%29.aspx.

So you can write code like

 var queryLondonCustomers = from cust in customers
                       where cust.City == "London" 
                       select cust;

Keep in mind that this will still be translated to SQL for the database, it's just a layer on top of SQL for the programmer.

Dylan Meeus
  • 685
  • 1
  • 5
  • 18
  • While not perfect (because it translates to SQL instead of running natively) this would be a good answer for this kind of problem, assuming LINQ cleanses it's own inputs before sending to SQL. – davolfman Feb 18 '15 at 19:35