SQLite query restrictions

641 Views Asked by At

I am building a little interface where I would like users to be able to write out their entire sql statement and then see the data that is returned. However, I don't want a user to be able to do anything funny ie delete from user_table;. Actually, the only thing I would like users to be able to do is to run select statements. I know there aren't specific users for SQLite, so I am thinking what I am going to have to do, is have a set of rules that reject certain queries. Maybe a regex string or something (regex scares me a little bit). Any ideas on how to accomplish this?

def input_is_safe(input):
    input = input.lower()
    if "select" not in input:
        return False
    #more stuff
    return True
3

There are 3 best solutions below

3
On BEST ANSWER

I can suggest a different approach to your problem. You can restrict the access to your database as read-only. That way even when the users try to execute delete/update queries they will not be able to damage your data.

Here is the answer for Python on how to open a read-only connection:

db = sqlite3.connect('file:/path/to/database?mode=ro', uri=True)
0
On
  1. Open the database as read only, to prevent any changes.
  2. Many statements, such as PRAGMA or ATTACH, can be dangerous. Use an authorizer callback (C docs) to allow only SELECTs.
  3. Queries can run for a long time, or generate a large amount of data. Use a progress handler to abort queries that run for too long.
2
On

Python's sqlite3 execute() method will only execute a single SQL statement, so if you ensure that all statements start with the SELECT keyword, you are reasonably protected from dumb stuff like SELECT 1; DROP TABLE USERS. But you should check sqlite's SQL syntax to ensure there is no way to embed a data definition or data modification statement as a subquery.

My personal opinion is that if "regex scares you a little bit", you might as well just put your computer in a box and mail it off to <stereotypical country of hackers>. Letting untrusted users write SQL code is playing with fire, and you need to know what you're doing or you'll get fried.