sql-injection urls, is length of a parameter a security issue?

I'm getting a lot of hits that involve sql injection attempts that involve increasingly long parameters. I am limiting the parameters in php to cast them as positive ints or zero, but I'm not certain that there isn't some kind of trick involving really long parameters that could cause me problems (buffer overflow problems?).

I know that the suhosin patch in php has some kind of patching of excessively long parameters, though I don't have that in place currently. What should I do to protect myself against cases like this (from my logs)?

ProductId=47&ItemId=-1025+UNION+SELECT+0x6d6567613164756d706572,0x6d6567613264756d706572,0x6d6567613364756d706572,0x6d6567613464756d706572,0x6d6567613564756d706572,0x6d6567613664756d706572,0x6d6567613764756d706572,0x6d6567613864756d706572,0x6d6567613964756d706572,0x6d65676131064756d706572,0x6d65676131164756d706572,0x6d开发者_运维问答65676131264756d706572,0x6d65676131364756d706572,0x6d65676131464756d706572,0x6d65676131564756d706572,0x6d65676131664756d706572,0x6d65676131764756d706572,0x6d65676131864756d706572,0x6d65676131964756d706572,0x6d65676132064756d706572,0x6d65676132164756--

---

You may use intval() to validate the user input. It will return the input as an integer or a 0 if parsing fails. The latter would be the case in your example.

$filteredItemId = intval($_GET['itemId']);

if($filteredItemId <= 0) { /* invalid id given */ } else { /* do stuff */ }

---

Use prepared statements. The parameters are escaped before send to the database and could not do any damage.

UPDATE

The same mechanism could be applied to the rest of user supplied content too. Use htmlspecialchars() to escape all data, you get from the user. This should also be safe to XSS attacks (in most cases)

---

Well always check all input parameters. Also for length. If you don't trust it, block the whole IP. I had 100+ attacks like this today, but due to an extensive table with "bad words" I survived. If string ontains any bad word->block whole IP.