I have a client which has very large amount of code on its production server, now we are securing this server. They have SQL vulnerability is there code, so we are adding these commands in the beginning of the code. Will this solve the issue even if temporarily.
$_POST = array_map('mysql_real_escape_string', $_POST);
$_GET = array_map('mysql_real_escape_string', $_GET);
$_REQUEST = array_map('mysql_real_escape_string', $_REQUEST);
There's no way for us to tell if that solves the issue, because we don't see how you the application code is using the $_GET
, $_POST
and $_REQUEST
variables. It might actually break other uses of the request variables to force them all to have escaping.
case
statement or as an associative array key, etc.Basically, you're trying to do the same thing that magic quotes used to do, but magic quotes was deprecated because it's a bad idea to have a one-size-fits-all solution for security. It's just based on too many assumptions that turn out not to be true.
The proper solution (if you must stick with ext/mysql for now) is to apply filtering or escaping to request variables as you use them in SQL.
Of course it's best to upgrade to ext/mysqli or PDO, and use query parameters. But I realize this is a lot more work to adapt a large codebase to a new API, and you're looking for what you can do short-term.
You might also look at mod_security, which can help you filter out suspicious patterns of request variables without changing any PHP code at all. But it's also a lot of work to design mod_security rules that will work for your app without blocking legitimate requests.