Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 10 down vote favorite
2

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?

share|improve this question
See also: stackoverflow.com/questions/60174/… – Mahn Sep 20 '12 at 22:22

1 Answer

up vote 19 down vote accepted

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.

share|improve this answer
5  
+1 for skipping random filtering methods and going straight for the real solution: parameterized queries. – Polynomial Aug 2 '12 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. – Andrew Smith Aug 2 '12 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 '12 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 '12 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 '12 at 8:55
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.