3

Suppose I have a very simple PHP application that acts as a front-end for an SQL database. The user enters their query into a box, and the app shows the query results in a table.

To prevent a user from modifying the table, the SQL user only has permissions for read-only queries, i.e. if a user tries to enter something like DELETE * FROM persons or DROP TABLE persons into the textbox, they get an error.

Is it still considered "bad form" if this web app is vulnerable to SQL injection, given that the intended use of the app is for the user to be able to execute their own (read-only) SQL queries on the database?

1
1

Is it bad if the app is vulnerable to SQL injection if it does not cause any harm - yes. Is it critical - probably not. Should it be fixed - yes.

Basically you are having a multilayered defense: the first layer is to make sure to not allow SQL injection while the second is to make sure (using database permission) that a successful injection does not cause harm. The idea behind a multilayered defense is that any of the layers might not be perfect but combined they provide a better defense than alone. Just hoping that the second layer will catch any problems expects that this defense layer is perfect - which it often isn't.

1

It is always a bad thing. Because it means the code is sloppy, even if the vulnerability is not directly exploitable but you never know, an experienced hacker could find a flaw that you just cannot see at the moment. Or even a smarter user who thinks outside the box could find something that you missed. So you should not assume that is harmless.

In fact you could have posted the vulnerable code in question, that would have made the discussion even more interesting.

The fact remains that the application is poorly coded and buggy. It if is buggy then it is not reliable: there are probably many logic and programming flaws in it, and you could imagine that it sometimes behaves incorrectly or returns wrong data.

You are not giving any details about that front-end but I am wondering what's the point of it. Isn't there a commercial or open source front-end application on the market, that you could use instead ? Then you wouldn't have to worry about this problem, the only thing you should do is set the respective users rights in the database and tighten access.

It's not the front-end that should enforce access rights on the database. Security has to take place at the source. In fact the front-end can probably be bypassed. Since postgresql is mentioned in the tags, there are quite a few GUI tools for it, not to mention command line utilities. What prevents people from using one of those tools to connect to your database ?

0

Is it still considered "bad form" if this web app is vulnerable to SQL injection, given that the intended use of the app is for the user to be able to execute their own (read-only) SQL queries on the database?

By definition there is no Sql injection involved here.
As far as I can tell, your php code just passes the user sql query as is, straight to the database. The value of the form's "box" is not used as a parameter or an input for another sql query.

That said, your main concern would be the rights that are granted to the user of the application, you might think to add validation on the form like rejecting "Update" and "Insert", but this would be superfluous as the database can handle this control and returns the right exception.

2
  • "The user enters his query into a box" looks like an injection to me.
    – Theophany
    Apr 21 '20 at 21:08
  • @Theophany the "query" is passed right away to database, it is not injected in the code where a predefined query does exist.
    – elsadek
    Apr 21 '20 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.