I found an SQLi in a buddies work site. He reported it to his superiors and they allowed me to run additional tests and also patch the site. After reviewing the site, The vulnerable code was a $_GET. I simply added intval() to check the variable if it was an integer. I reran sqlmap, w3af, and a few other scanners. The holes seemed to have been patched. Was this the proper patch? If not, how do I properly secure a $_GET in PHP?


1 Answer 1


It doesn't matter if its $_GET, $_POST, $_REQUEST, $_FILE or even $_SERVER. Its all user input and a there for a potential source of an attack. What matters is how the user input is being used. In the case of SQL Injection, casting it to an int, such as intval() works well. However, you should be using parameterized queries with a library like sqli, adodb, or pdo.

But sql injection is just one issue on the owasp top 10 and just one issue out of the thousands of vulnerability types tracked by the CWE system. There is no magic wand to stop every vulnerability.

  • 5
    +1 for skipping random filtering methods and going straight for the real solution: parameterized queries.
    – Polynomial
    Aug 2, 2012 at 14:16
  • Parametrized query is not a real solution in all cases, you need to assume that the attacker will eventually gain the remote shell and will be able to execute queries anyway. SQL impersonation is a real solution with parametrized queries. Aug 2, 2012 at 16:00
  • @Andrew Smith defense in depth is one thing, but I think you lost me here. Maybe you should post a question on SQL impersonation as an open debate with security.se.
    – rook
    Aug 2, 2012 at 19:26
  • @Andrew Smith its not easy to get a shell from sql injection. Under MySQL you can't stack queries, and you don't have MS-SQL's xp_cmdshell(). MySQL's into outfile can lead to a shell in some cases, but the mysql user account needs file_priv.
    – rook
    Aug 2, 2012 at 21:02
  • 1
    Parameterized queries are one way to thwart a compromise - however SQL queries are only one place where a logic tier might write data (logs, html, other databases, files....). The problem is that bound parameters are specific to databases - and only via specific APIs. I'm not suggesting that all data should be encoded in a transport / storage neutral format - rather that explicit escaping of output appropriate to the destination is a generic solution to injection vulnerabilities. As an architectural approach it provides a consistent pattern to implementing code.
    – symcbean
    Aug 3, 2012 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .