Menu
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,0x6d65676131264756d706572,0x6d65676131364756d706572,0x6d65676131464756d706572,0x6d65676131564756d706572,0x6d65676131664756d706572,0x6d65676131764756d706572,0x6d65676131864756d706572,0x6d65676131964756d706572,0x6d65676132064756d706572,0x6d65676132164756--
823
How to Prevent an SQL Injection. The only sure way to prevent SQL Injection attacks is input validation and parametrized queries including prepared statements. The application code should never use the input directly. The developer must sanitize all input, not only web form inputs such as login forms.
You should always use parameterized statements where available, they are your number one protection against SQL injection. You can see more examples of parameterized statements in various languages in the code samples below.
Detection methods range from checking server logs to monitoring database errors. Most network intrusion detection systems (IDS) and network perimeter firewalls are not configured to review HTTP traffic for malicious SQL fragments, making it possible for an attacker to bypass network security boundaries.
Input validation. A common source of SQL injection is maliciously crafted external input. As such, it's always a good practice to only accept approved input—an approach known as input validation. To protect against it, there are two variants of input validation: avoid list validation and preferlist validation.
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)
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
