I had trouble getting the form API to work though I am considering re doing all my forms with it. I have some custom html/php forms however I directly insert into the DB using pg_query. I am looking into replacing that with pg_query_params to escape. I was wondering whether the php filter module, if I set it up, would prevent users from doing harm via sql injection? Iwould guess not but thought I would check.
Just looking for suggestions.
No, it very much will not!
SQL injection prevention is something that needs to happen in the PHP code itself; the PHP filter won't alter your PHP, so it can't add protection to your code.
I'd be very surprised if there's anything out there that can auto-magically take an arbitrary PHP script and save it from SQL injection. In fact, if you ever see anything that claims to do that I'd go so far as to say "avoid it" it's lying.
Shows what I know :)
As per the comments, ModSecurity is an option if you want to control this at the web server level.
It will not, in any way shape or form protect you from injection. Quite the contrary, using the PHP filter is generally a horrible security problem, because it enables arbitrary code to be executed.
Do not use the PHP module, at all.
Greggles mentions the Paranoia module in his answer, which is awesome, consider using it. However, if you have enough control over your server, you could take it one step further, by disabling the eval function all together.
In your php.ini: disable_functions = eval
disable_functions=eval. However, what you say is true, the permissions system will limit use of the filter, but that doesn't necessarily protect you from the opened pandoras box that the php filter is.
Commented
Jul 31, 2013 at 8:23
The title of the question is about using "PHP Filter" as a way to make queries safe. As others have mentioned:
But the body of the question gets into two more questions. Using pg_query functions directly and how to avoid SQL injection. You also should not be using pg_query directly but instead use the Drupal database API.
You can find more about this topic at Drupal Database API and the Writing Secure Code for more tips about how and why to use the Drupal database API for portability, security and scalability.
There are other modules and services that behave as an Intrusion Detection System or provide other means to avoid malicious attacks.
The only reliable way to prevent SQL injection is to carefully use only parameterized queries ("prepared statements") and avoid string interpolation in queries. In PHP that means pg_query_params or appropriate PDO module use.
Even then, a multi-layered defense is certainly nice. I try to prevent obvious SQL injection attacks from appearing in identifiers where there's no reason for them to be permitted. If you try to set your username to something including '); I'll just reject the request. Sure, I can safely insert that string and if the check wasn't there the attack would still do nothing, but it means I don't have potential attack code in my DB where it could be read out and interpolated into another SQL command elsewhere, perhaps by code that thinks that "this value came from the database so it must be safe".
This might save you if someone wrote a buggy PL/PgSQL function that doesn't properly use format(...) or quote_ident / quote_literal. The data passes straight through your app fine, then successfully executes the attack via the buggy PL/PgSQL function. Similar issues can arise from a badly written automation script, reporting tool, or all sorts of things.
So: even with data from your own DB, treat it as if it could be user-modifiable if it was ever user modifiable at any stage in its life-cycle. In fact, treat everything as user-modifiable and untrustworthy unless you have an extremely good reason not to.
So, IMO, much like you'll tend to reject obvious XSS attempts even though you know your code will safely handle them if not rejected, you should reject obvious SQL injection attempts even if your code will survive them fine.
Also, note that pg_query_params isn't magic SQL injection protection. If you write:
pg_query_params("SELECT blah FROM $tablename WHERE somecol = \$1", array($uservalue))
and $tablename can be defined by the user, you're still just as stuffed.
