Is it possible to breach prepared statement and stored procedures with unsafe sql query string

Question

Recently when I was looking through some code which looks more or less like this:

 $query = "call someProcedure(?,?,{$unsafeString})";

Then there is some code where the list of arguments is prepared and after that, there is generated prepared statement from string query

Given that unsafeString is coming from user, it is not being validated or escaped and it is interpolated in query string. I was wondering, can this be a serious threat and how it can be exploited?

I tried to add second statement at the end, but seems like prepared statements allow me to execute only first query and I also tried to use select statement to get some values from dB, but seems like some stored procedure does not allow to do that.

So I was wondering, can I state that this is safe? or there is some possibilities to exploit it?

Answer 1

Unless you are doing some dynamic SQL inside someProcedure or not using mysqli_multi_query() you should be safe at this point but since you are not escaping or validating user input, and if $unsafeString is stored in a database, an attacker can use this at a later time and it would be difficult to spot. Therefore I would change to prepared statements everywhere in your code so you handle all the data, even one stored in the database safely.

EDIT:

CLARIFICATION

Depending on how you handle data in you application, and since there is obliviously a place in the code where you don't use prepared statements it would be safe to assume there are other places where you might not use it either. If for example you handle data previously stored with a call to

$query = "call someProcedure(?,?,{$unsafeString})";

there is a possibility you are handling that string in an unsafe manner where code injected into the data could be executed. For example, concatenating the data with a SELECT statement. This kind of vulnerability is difficult to spot since you might assume data already stored in the database is safe.

Also, by not escaping or validating the input, you are opening yourself to a XSS attack depending, of course on how you handle that data later or.

Answer 2

There is not enough information provided. We would have to see the stored procedure on the backend to know if this is vulnerable or not. I will tell you it's definitely a red flag though.

Answer 3

If the data input isn't validated or scaped, it could be vulnerable to SQL Injection, because a Stored Procedure could have dynamic queries without validated or scaped data, even if you are using Stored Procedures you should use prepared statement. The risk is less using Stored Procedure, because deducing the internal logic is more complicated; Inserts, Updates, selects could be part of a Stored Procedure, on the other hand if there isn't a SQL Injection vulnerability, you could break the logic of Stored Procedure trying to find a SQL Injection and it could lead to unexpected results, then I think an unvalidated and unescaped argument involves a risk and it should be mitigated.