Potential danger of using unprepared SQL queries when user input is not processed?

Question

Everyone knows or needs to know that parameterized queries help protect against SQL injection. All the training materials and documentation that I saw revolved around using prepared SQL queries to handle form input. But what about when there is no input of any form? That is, the subsequent request after the user logs in, for example $stmt = "SELECT theme_preference FROM users WHERE user_id = '1234'"; $query = mysqli_query($conn, $stmt); $stmt = "SELECT theme_preference FROM users WHERE user_id = '1234'"; $query = mysqli_query($conn, $stmt);

Is there any possible way an attacker could use this? (Say I'm using PHP).

Answer 1

The question is not whether the source of the data recorded in the SQL query is an http form. It is not even if it is from the current request.

The question is, trust the data source . And that can be a tricky question.

You obviously do not trust what comes from the current request. You also do not trust what might have arisen from an earlier query, for example, for example fields in a database that have been modified by query data. But you may or may not trust other fields in your database. For example, you have IT staff or database administrators. Do you trust them not to inject any XSS or SQLi secondary attack into the database field in order to steal the user's credit card information that is stored in the verified table, so they cannot just log in and discard it without noticing? If they entered javascript or smart SQLi at the right place in a table that is not checked, they can steal credit card information using a vulnerable application, then change it and delete all the tracks.

In addition, the application can have different data sources, other systems can, for example, upload files (for example, XML) to the API, the data from them will be processed, some of them eventually end up in the user interface or are used in SQL queries. If you trust these sources, you can refuse to implement protection against SQLi or XSS. But why do you need it when it's easy? Several levels of protection are always better than walking on thin ice.

In short, the question is trust. If you absolutely trust the data source (for example, because it is static, hard-coded, or for some other reason), it's fine to use it directly in queries. But in the case of SQL injection, using it correctly (i.e. in parameters) is so simple that you just have to do it.

Also consider future changes. You write it in an SQL string without parameters, because now you know that it is safe. Months pass, someone adds a new function, changes your request, adds a few more parameters, one of them. But the template was already there, it will probably just copy-paste and go with the template - and your application will be vulnerable.

My final point is static security scanners, those that look at your source code. Pretty much all of them will indicate your code for SQLi if the variable is included in the query string without using parameters. This, of course, can be false positive, but I doubt that you want to work with these conclusions when you can avoid them in the first place.

Therefore, sometimes this applies not only to technical operational ability, but also to other aspects.