0

I have to write a base file for a larger program which will get functionality by include-files provided by other programmers. As I know neither the content nor the accuracy of the included code I have to ensure it will contain no target for MySQL injection. So in the beginning (right after setting the $server_conn) I ponder to add the following code:

$unsetvars = array_keys(get_defined_vars());
for ($i=0; $i<sizeOf($unsetvars); $i++)
{
  if (substr($unsetvars[$i],0,1) != '_' && $unsetvars[$i] != 'server_conn')
  {
    unset($$unsetvars[$i]);
  }
  elseif ($unsetvars[$i] == '_GET' || $unsetvars[$i] == '_POST' || $unsetvars[$i] == '_REQUEST')
  {
    $subarray = array_keys(${$unsetvars[$i]});
    for ($j=0; $j<count($subarray); $j++)
    {
      ${$unsetvars[$i]}[$j] = get_magic_quotes_gpc() ? stripslashes(${$unsetvars[$i]}[$j]) : ${$unsetvars[$i]}[$j];
      ${$unsetvars[$i]}[$j] = mysqli_real_escape_string($server_conn,${$unsetvars[$i]}[$j]);
    }
  }
}
unset($unsetvars,$subarray,$i,$j);

But I still am insecure in several points:

1) Beside of $_GET, $_POST and $_REQUEST I have in mind to deal with $_FILES. Can you think of other Predefined Variables which might be an attack vector?

2) With the confinement of 1) will that reasonably avoid SQL injection from Website calls? (I know there might be still open attack vectors when programmers would be using external sources - but I don't think I will be able to control that)

3) Is there a way to inject variables to PHP beside of Predefined Variables? Otherwise the if-clause of the code above seems unnecessary?

4) Is this generally a useful approach and/or are there better ways to solve the problem? (I know in some cases the programmers won't get exactly the variables they expect, but that would be acceptable if SQL injection would be prevented)

In the end I have a meta question about the usage of stackoverflow: I found a related question "PHP SQL Injection Prevention [duplicate]" which in my opinion has not been answered properly (because the questioner stated "i have to submit the project in the next two days" - Considering my approach turns out to be usable for my problem it might also answer the related question: Would I post the approach as answer there too? Would I do so even though the related question is quite old (from 2011)?

Community
  • 1
  • 1
Wooz
  • 306
  • 1
  • 2
  • 13
  • 1
    I think you either need to trust your programmers or not. If you are executing code from completely untrusted sources, there is nothing you can do to prevent them from providing vulnerable code, and not limited SQL injection. You `mysqli_real_escape_string`, then they `stripslashes` and you're back to square one. – Mike May 09 '15 at 19:46
  • With the stripslashes you made a point... so it would be hard to get total security. Do you think the above code will at least increase security or do you think it totally obsolete then? – Wooz May 09 '15 at 19:56
  • 1
    If you're so worried about the code quality of other developers, then you really need to be reviewing their code manually or with some automated tools, or potentially both. There is no silver bullet for this and as Mike already said, you either trust them or not. Sounds like you're getting over-zealous to me though. – Jonnix May 09 '15 at 19:59
  • @Wooz It seems like security by obscurity to me. Also, what happens if, for example, the coder wants to echo `$_POST['somevar']` or save it to a file, etc. They're going to have all these backslashes all over the place and therefore have to perform stripslashes. Even if they don't have malicious intent, they may use one of those stripped variables in an SQL query. And if they *do* have malicious intent, there is little to nothing you can do about it. – Mike May 09 '15 at 20:02
  • Paste some vulnerable code you are hypothetically dealing with. – Ruslanas Balčiūnas May 09 '15 at 20:14
  • I can't paste paste some vulnerable code here because I do not know what it will be. – Wooz May 09 '15 at 20:57
  • Unfortunally there is no manpower to check the provided code. The programmers are not likely to be malicious by purpose, but it was a strong wish to centrally avoid SQL injection by their possible inadvertency (even on the cost of some inconveniance by changed strings which might not be even used in MySQL statements). But after the argument with stripslashes I will either turn down the pre-avoiding idea or will have to become even more ruthless and remove/replace all escaped characters. - Hmm, sounds as if my question is getting more and more pathological.... – Wooz May 09 '15 at 20:57
  • Can you nevertheless tell me whether there is a way to directly inject variables to PHP beside of Predefined Variables (Question 3) ? – Wooz May 09 '15 at 21:15
  • All of the user-supplied variables (and a few others) are listed here: http://php.net/manual/en/reserved.variables.php however if the code does not *use* those variables it would have no effect on your program's execution. However why not just instruct your coders to use parameterized queries. Tell them that the requirement is that anything that is not hard-coded *must* be a bound parameter. No variable, no matter its origin, should ever be put directly into a query. That way they can do what they want with their variables and you don't need to worry about trying to pre-escape them. – Mike May 09 '15 at 22:14
  • "...should ever be put directly into a query." Yes, that's how it should be. But there is always the fear of the one little request where that was overlooked. So I still like the idea of a pre code disposing (almost) all your worries about injection, but I have to figure out if the price of sometimes truncated variables is worth to pay. At least the if-clause with unsetting the non reserved variables seems superflous for sure, considering your last comment that users can directly effect program variables only by reserved variables. Thanks to all of you for your help and patience. – Wooz May 10 '15 at 00:35

0 Answers0