0

I am using FluentPDO to handle my database queries. Upon looking at it's code, it doesn't seem to use any form of escaping. I understand PDO solves a lot of security issues by itself, but it's not immune to them.

As I understand, it is immune to SQL injection as long as we use the prepared statements syntax featured at it's homepage:

$query = $fpdo->from('article')
        ->where('published_at > ?', $date) // HERE!!
        ->orderBy('published_at DESC')
        ->limit(5);

How about escaping variables to prevent second order SQL injection? Would simply using addslashes() suffice? Would it be redundant? How should I handle security with this library?

Thanks!

fgarci03
  • 330
  • 7
  • 15
  • If the library use prepared statement and binding the parameters. That should be ok. – frz3993 Jan 09 '16 at 18:02
  • Don’t differentiate between where the data comes from; just pass it as parameter and you’re fine. – Gumbo Jan 09 '16 at 18:51
  • I'm sorry @Gumbo, would you please explain this further? – fgarci03 Jan 09 '16 at 22:53
  • 1
    @fgarci03 Some argue so called ‘second order SQL injection’ is a special case as the data comes from a ‘trusted source’ or whatever flimsy argument they have. However, this would only be a special case if you’d handle data from the database differently than from any other source in the first place. But any SQL injection is just SQL injection, regardless of the source of the data. And SQL Injection is not a matter of trust but of improper data handling. So just worry where the data came from but just pass it as a parameter to your database to ensure it gets handled as intended, i. e., as data. – Gumbo Jan 10 '16 at 00:58
  • I get it now. And yes I am handling all the data the same way, no matter where it comes from! Thank you – fgarci03 Jan 10 '16 at 14:09

2 Answers2

0

FluentPDO passes all parameters through the "execute" method of PDO, for example:

$connection = new PDO(...);
$pdo = connection->prepare($sql);
$pdo->execute($params);

That's why FluentPDO already prepares Queries to avoid SQL Injection.

Fernando Rotermund
  • 1
  • 1
-1

About sanitizing, read more.

Some nice quotes:

Do not try to prevent SQL injection by sanitizing input data.

Instead, do not allow data to be used in creating your SQL code. Use Prepared Statements (i.e. using parameters in a template query) that uses bound variables. It is the only way to be guaranteed against SQL injection.

or (read more about validating filters)

PHP has the new nice filter_input functions now, that for instance liberate you from finding 'the ultimate e-mail regex' now that there is a built-in FILTER_VALIDATE_EMAIL type

Community
  • 1
  • 1
Grzegorz Gajda
  • 2,424
  • 2
  • 15
  • 23
  • Note that validation (as indicated by using `FILTER_VALIDATE_EMAIL`) does not make proper data handling (e. g., parameterization as utilized by prepared statements) obsolete. See [Does FILTER_VALIDATE_EMAIL make a string safe for insertion in database?](http://stackoverflow.com/q/4154685/53114) and [Is FILTER_VALIDATE_EMAIL sufficient to stop shell injection?](http://stackoverflow.com/a/30816794/53114) for detailed samples. – Gumbo Jan 09 '16 at 21:30