[php pdo]prepared zonder bindparam of exec(quote($sql))

[MekZi]

Ik maak met behulp van pdo verbinding met een mysql server. Nu voerde ik mijn sql uit met pdo::exec($sql). Nu wil ik echter mij zelf tegen sql injection beveiligen. Prepared statements zijn automatisch tegen sql injection beveiligd (en ja ik weet dat dat nog steeds niet 100% is, maar in ieder geval genoeg voor de meeste gevallen).

Nou heb ik op het moment dit in een class staan:

PHP:

    public function exec($sql) {
        $prepared = $this->connection->prepare($sql);
        if($prepared === false) {
            throw new exception(__CLASS__.'::'.__FUNCTION__.': exec is mislukt (false)!');
        } else {
            return $prepared->execute();
        }
    }

Zoals je ziet gebruik ik geen bindparam. Zou ik hier dan toch gewoon $this->connection->exec(quote($sql)); moeten gebruiken? Ik twijfel hierover voornamelijk omdat op php.net word aangeraden de prepared statements te gebruiken (en omdat het sneller is, maar waarschijnlijk is dat dus alleen wanneer je bindparam gebruikt?).

Graag advies dus

[RobIII]

MekZi schreef op zondag 20 mei 2012 @ 00:09:
Zou ik hier dan toch gewoon $this->connection->exec(quote($sql)); moeten gebruiken?

quote: http://nl.php.net/manual/en/pdo.quote.php

If you are using this function to build SQL statements, you are strongly recommended to use PDO::prepare() to prepare SQL statements with bound parameters instead of using PDO::quote() to interpolate user input into an SQL statement. Prepared statements with bound parameters are not only more portable, more convenient, immune to SQL injection, but are often much faster to execute than interpolated queries, as both the server and client side can cache a compiled form of the query.

En dan twijfel je nog omdat...

MekZi schreef op zondag 20 mei 2012 @ 00:09:
omdat het sneller is

Dat is één van de redenen die ze aandragen ja.

[ Voor 10% gewijzigd door RobIII op 20-05-2012 01:58 ]

[cariolive23]

MekZi schreef op zondag 20 mei 2012 @ 00:09:Prepared statements zijn automatisch tegen sql injection beveiligd

Zodra de database het queryplan heeft aangemaakt, kan deze niet meer wijzigen. Het parsen van SQL is al een gepasseerd station, de database wacht nu alleen nog op de input voor de parameters. En daarmee is SQL injection onmogelijk geworden. Het enige wat nu nog "mis" kan gaan, is dat er andere waardes voor de parameters worden ingevoerd, maar dat is géén SQL injection, het is geen SQL wat wordt geïnjecteerd.

(en ja ik weet dat dat nog steeds niet 100% is, maar in ieder geval genoeg voor de meeste gevallen).

Geef eens een voorbeeld van een prepared statement die volgens jou dan niet bestand is tegen SQL injection.

Volgens mij bestaat er overigens niet zo iets als "veilig in de meeste gevallen". Jouw code is bestand tegen SQL injection óf is _niet_ bestand tegen SQL injection. Daar zit niks tussenin.

[RobIII]

cariolive23 schreef op zondag 20 mei 2012 @ 12:49:
Geef eens een voorbeeld van een prepared statement die volgens jou dan niet bestand is tegen SQL injection.

Zal niet voor 't eerst zijn dat ik zoiets zie:

PHP:

$query = 'select * 
          from foo
          where bar = :bar
            and baz in (' . implode(',', $_POST['foobar']) . ');';
...

Daarmee haal je 't complete concept prepared statements natuurlijk onderuit maar er zijn nou eenmaal zaken die je (nog) niet (goed) met prepared statements kunt oplossen helaas.

[ Voor 3% gewijzigd door RobIII op 20-05-2012 13:02 ]

[cariolive23]

RobIII schreef op zondag 20 mei 2012 @ 13:01:
[...]

Zal niet voor 't eerst zijn dat ik zoiets zie:

PHP:

$query = 'select * 
          from foo
          where bar = :bar
            and baz in (' . implode(',', $_POST['foobar']) . ');';
...

Daarmee haal je 't complete concept prepared statements natuurlijk onderuit maar er zijn nou eenmaal zaken die je (nog) niet (goed) met prepared statements kunt oplossen helaas.

Zo lust ik er nog een paar... Dit is een voorbeeld van het prepareren van een gehackt stuk SQL, dit is het perfecte voorbeeld van hoe het _niet_ moet, dit is gewoon fout. Parameters horen niet in de SQL te staan, die stuur je pas later. Ook wanneer het een IN() constructie betreft. Dat is het idee van een prepared statement.

Helaas zijn er teveel mensen die niet snappen hoe het werkt, dan kun je dit soort blunders krijgen. Maar dat heeft niets met prepared statements te maken, maar alles met onkunde.

Ps. Met MySQL is het redelijk ruk om met IN() en prepared statements te werken, gaat volgens mij niet. Maar dat kan ik mis hebben. In PostgreSQL gebruik je ANY en een array, werkt uitstekend.

[RobIII]

cariolive23 schreef op zondag 20 mei 2012 @ 22:39:
Ps. Met MySQL is het redelijk ruk om met IN() en prepared statements te werken, gaat volgens mij niet.

En dat is precies de reden waarom ik 't aanhaal en waarom ik 't nog wel eens tegen kom. Een ook precies waarom ik aangeef dat 't natuurlijk 't nut van prepared statements nogal onderuit haalt.

cariolive23 schreef op zondag 20 mei 2012 @ 22:39:
In PostgreSQL gebruik je ANY en een array, werkt uitstekend.

Deze kras in de plaat begint vervelend te worden.

[ Voor 8% gewijzigd door RobIII op 20-05-2012 22:45 ]