Can not allowing space, equal sign, and quote inputs prevent php/SQL injection?

Question

I was just wondering that if you limit the user to only be able to input letters and numbers, would that fully protect you against injection?

depends on where you limit them. If you strip down the input in the processing script to just [0-9a-zA-Z] then I am unaware of any injection they could pull off. If you are using js to restrict the input field then that is useless and easily circumvented. Not sure about how multibyte characters could change that screnario though. Why not just use prepared statements? — Kai Qing, Apr 15 '14 at 18:29
why not use prepared statements or proper escaping instead of some limitations that *might* or *mitght not* work? — dognose, Apr 15 '14 at 18:30
Read this question: http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php — Ozan Kurt, Apr 15 '14 at 18:30

score 4 · Accepted Answer · edited Mar 17 '17 at 13:14

That depends on how you define letters and numbers. There are certain Unicode characters that can result in SQL injection. This is sometimes called SQL Smuggling.

There are cases of SQL Injections leveraging the implicit conversion of Unicode homoglyphs from Unicode character string types (NCHAR, NVARCHAR) to character string types (CHAR, VARCHAR). A character such as ʼ (U+02BC) in NVARCHAR may slip through the escaping routine and get translated to ' (U+0027) in VARCHAR, which may result in an SQL Injection when such a string is used to build an SQL statement dynamically.

However, your validation is pretty strict (only characters from the Basic Latin Unicode block and Unicode whitespace characters) and I can’t think of any case where this would fail.

https://security.stackexchange.com/a/54958

Having said that, prepared statements / parameterized queries offer the best protection against SQL injection. If the allowable character set is expanded through a requirements change years down the road, the person doing the change may be unaware of the security implications of allowing additional characters.

It is possible to group Unicode characters by their [character properties](http://en.wikipedia.org/wiki/Unicode_character_property). The mentioned character U+02BC has the property *Lm* (modifier letter). — Gumbo, Apr 15 '14 at 19:13

score 0 · Answer 2 · answered Apr 15 '14 at 18:30

0

For MySQL you can escape your string using mysql_real_escape_string() or so. Actually, if there is only something contains letters(A-Z) and digits (0-9) then it is okay. But the point is to have the right filter for each variable you are receiving from user.

answered Apr 15 '14 at 18:30

Paul Denisevich

2,329
14
19

This is tagged `sql`, not `mysql`. – Eric J. Apr 15 '14 at 18:30
1

tagged sql by a user with 3 reputation asking a question like this. Chances are he meant mysql – Kai Qing Apr 15 '14 at 18:31
@EricJ. it's taggede like that, but OP is talking about MySQL with a chance of about 90% :-) – dognose Apr 15 '14 at 18:31
Now that the answer reads MySQL rather than SQL, less of an issue :-) – Eric J. Apr 15 '14 at 18:32
@eric - right but mysql_ functions are deprecated so there's still reason to pick on this answer – Kai Qing Apr 15 '14 at 18:33

score 0 · Answer 3 · answered Apr 15 '14 at 19:00

It makes no sense.
It is useless.

Even if it worked it would be useless and wrong.

Dynamical SQL building should be never connected to whatever user input and its validation. There are rules of safe SQL creation already. That works for ANY data, not only artificially limited subset.

In a sanely designed application data storage layer should be separated from user input processing. And should be able to process any data, regardless of its source or developer's whims.

Can not allowing space, equal sign, and quote inputs prevent php/SQL injection?

3 Answers3