Stefan: PDO Prepared Statements nutzen

Hi,

soll man Prepared Statements in PDO als Sicherheitsfeature nutzen oder lieber nicht?

Zitat:

Achtung:

Allerdings sollte man jetzt nicht immer Prepared Statements nutzen. Ein ‘normales’ $pdo->query(“MySQL Query) ist ca. drei mal so schnell wie ein Prepared Statement mit PDO. Prepared Statements sollten nur dann verwendet werden, wenn ein und dasselbe Query immer und immer wieder mit verschiedenen Parametern ausgeführt wird.

Quelle: http://kushellig.de/prepared-statements-php-data-objects-pdo/

Mir geht es nicht daraum, den Autor zu bewerten, mir geht es nur darum, meine eigene Vorgehensweise zu verifizieren oder neu zu überdenken.

Danke, Stefan

  1. Hallo,

    soll man Prepared Statements in PDO als Sicherheitsfeature nutzen oder lieber nicht?

    Was ist die Alternative? Du kannst dir auch deine eigene API bauen, die beliebige Werte sicher in SQL-Queries einbaut. – Will man das tun? Nein. – Ist das äquivalent sicher? Nur mit viel Aufwand und Testing. – Ist das performanter? Wage ich zu bezweifeln. Dazu müsstest du es auch in C implementieren. Dabei kann sicherheitstechnisch nur noch mehr schiefgehen.

    Die »Alternative« zu PDO Prepared Statements sind eher objektrelationale Mapper. Die sind natürlich noch langsamer, weil mehr Code ausgeführt wird und es sich um eine Abstraktion handelt. Dafür hast du mit SQL in den meisten Fällen nichts mehr am Hut, kannst also keine Fehler beim Erzeugen von SQL-Queries machen.

    Ein ‘normales’ $pdo->query(“MySQL Query) ist ca. drei mal so schnell wie ein Prepared Statement mit PDO.

    Ich bezweifle, dass das korrekt ist. Selbst wenn: Premature optimization is the root of all evil. Teste die Performance in deiner konkreten Anwendung und optimiere die größten Blöcke. Ich bezweifle, dass Prepared Statements einen großen Anteil oder sogar das Bottleneck sind. Wenn sie sich wirklich als langsam erweisen, dann kannst du nach gleichwertigen Alternativen suchen.

    Letztlich ist Sicherheit wichtiger als Performance, daher würde ich im Zweifelsfall ein robustes, sicheres, zuverlässiges, minimal langsameres System bevorzugen.

    Viele Grüße
    Mathias

    1. Letztlich ist Sicherheit wichtiger als Performance, daher würde ich im Zweifelsfall ein robustes, sicheres, zuverlässiges, minimal langsameres System bevorzugen.

      Danke für Deine Erklärung.

      Deinem Hauptargument ist natürlich wenig entgegen zu setzen.

      Mir ging es eher darum, SQL-Injections abzufangen, daher frage ich mal:

      Welchen sicherheitstechnisch relevanten Vorteil bieten denn Prepared Statements noch?

      Oder fange ich SQL-Injections in PHP nicht sicher ab, wenn ich den variablen Input kontextgerecht behandele?

      Stefan

      1. Hallo,

        Oder fange ich SQL-Injections in PHP nicht sicher ab, wenn ich den variablen Input kontextgerecht behandele?

        Sagen wir einmal so: Es ist *möglich*, dass dein händisches Erzeugen von SQL-Queries mit variablem Input genauso sicher ist.

        Das Problem ist vielmehr: Du musst den Input händisch escapen. Dabei werden erfahrungsgemäß Fehler auftreten. Dabei wirst du Angriffsvektoren übersehen. Am sichersten ist daher der Code, den du gar nicht erst schreibst. Am sichersten ist der Code, der SQL-Queries konzeptionell unmöglich macht. Der das Erzeugen von SQL wegabstrahiert. Der das Escaping in einem zentralen, gesonderten Modul erledigt, das Open Source ist, unabhängig geprüft, performant implementiert. Das ist, mit Verlaub, nicht dein und nicht mein Code. Das ist eher Code in PDO und ferner objektrelationale Mappern.

        Grüße
        Mathias