Is SQL injection possible with int data type?

Question

Currently I'm not using prepare or bind statement in my php code but I'm taking only int data for my search query so I just want to know where SQL injection is even possible with this query?

$enroll = mysqli_real_escape_string($conn, intval($_POST['enroll']));

$result = mysqli_query($conn, "SELECT * FROM Student_Data WHERE enroll=$enroll LIMIT 1");

I use intval() to take Int only input.

Thank you for the information.

you escaped it. but you really don't need to if you use parameterized queries. — Daniel A. White, Aug 28 '22 at 17:55
Does this answer your question? [Is "mysqli\_real\_escape\_string" enough to avoid SQL injection or other SQL attacks?](https://stackoverflow.com/questions/32391315/is-mysqli-real-escape-string-enough-to-avoid-sql-injection-or-other-sql-attack) — rickdenhaan, Aug 28 '22 at 17:57
Have a look at this question. It is the same as yours. :) https://softwareengineering.stackexchange.com/a/305299 — Uwe, Aug 28 '22 at 17:59
@rickdenhaan no it does not answer my question I'm only taking integer input from user as you can see I converted user input into integer using **intval** so still sql is possible or not? — premium drycleaners, Aug 28 '22 at 17:59
The question I linked to links to a details explanation of some *very obscure* edge-cases where SQL injection *may* be possible if you use `mysqli_real_escape_string()`. But your specific code example is not one of those edge-cases. Using `intval()`, it is not possible to inject custom SQL code into your query. *Maybe* there could be a DoS opportunity if you're running 64-bit PHP and 32-bit MySQL where PHP could send an integer value to MySQL that is larger than MySQL can handle in its 32 bits. But I haven't encountered 32-bit MySQL in quite a while. — rickdenhaan, Aug 28 '22 at 18:07
The standard way is to use prepared statement which can help you avoid SQL injection. If your intension is to do that, why on earth are you trying not to use it? — Muneer, Aug 28 '22 at 18:12
I will never understand why people invest effort into finding workarounds instead of simply following the recommended and proven patterns. Use the combination of "prepared statements" and "parameter binding" which works for _all_ cases. Not just for this one. — arkascha, Aug 28 '22 at 18:15
Why do things sloppily and check if they're safe in spefiic circumstances? Just do it right in the first place, it's the same simple code every time, why avoid it? If I found out about this approach during an interview, I'd straight up refuse to hire that candidate. — MatBailie, Aug 28 '22 at 18:23
@arkascha, Keep in mind we see a self-selecting sample of such questions. It's possible that a majority of programmers know how to use bound parameters, but we still see a lot of examples of outdated coding methods on sites like Stack Overflow because overall the number of junior developers grows every year. — Bill Karwin, Aug 28 '22 at 19:39
@BillKarwin I fail to see your point. While it certainly is true that people just starting to program do not have the experience I doubt that is the issue here. Look at the comments above: the OP reacts to the hints by wiping them aside ... — arkascha, Aug 28 '22 at 19:50

score 0 · Answer 1 · answered Aug 28 '22 at 18:15

In general, No It is not possible. But if your intension is to protect from SQL injection, why you should not use the better way which is proven? Overall, nothing can be guaranteed tomorrow. So better choice is to use the best practice what is available today.

score 0 · Answer 2 · answered Aug 28 '22 at 18:18

Firstly, escaping is always context-dependent. The context mysqli_real_escape_string is designed for is inside a single-quoted string in an SQL query. If you are using the string in any other context, do not use that function. For instance, this is not secure:

$input = "a + ' + b";
$sql = "Select * From whatever Where something=" . mysqli_real_escape_string($conn, $input);

The result is this:

Select * From whatever Where something=a + '' + b

So you've gone from a syntax error to a valid, and user-controlled, query.

For that reason, applying both intval and mysqli_real_escape_string never makes sense: if you're using the value in an integer context, it's simply the wrong function, and a symptom of the dangerous mentality that "more escaping is better".

Secondly, understand what the functions you're using actually do: intval converts any PHP value, if it can, to an integer; then the . operator will always convert its operands to strings. So $anything . intval($input) is always converting $input first to an integer, and then to a string.

So, certainly we can predict exactly what characters are possible to end up in the query - digits 0 to 9, and the - sign. It's just about possible that some obscure bug in the database or driver could misinterpret those in such a way as to have unintended consequences, but it's pretty unlikely.

Thirdly, if you have the choice, just use parameters and the whole thing becomes irrelevant.

Remember that, since you no longer have the context it works with, you should not also use mysqli_real_escape_string.

Is SQL injection possible with int data type?

2 Answers2