Magenta: MySQLi

Hi,

ich möchte nun MySQLi & Prepared Statements verwenden, um meine Scripts sicher zu gestalten. Vorher frage ich aber lieber noch mal nach, ob das was ich gelesen und verstanden habe so stimm:

  • Bin ich mit Prepared Statements & MySQL wirklich 100% sicher gegen SQL Injection anstatt wie bisher mit mysql_real_escape_string() ?

  • Ist da wirklcih ein Geschwindigkeitszuwachs bei MySQLi & Prepared Statements?

  • Was muss ich bei MySQLi noch beachten?

  • Was muss ich außer SQL Injectino noch bei meinen Scripts beachten?

Danke!

  1. Hi!

    • Bin ich mit Prepared Statements & MySQL wirklich 100% sicher gegen SQL Injection anstatt wie bisher mit mysql_real_escape_string() ?

    Nein. Du bist bei beiden Systemen nicht sicher, wenn du sie falsch verwendest. Prepared Statements verhindern noch nicht, dass in SQL-Statement-Teilen, in denen du keine Platzhalter anwenden kannst (ORDER BY und LIMIT beispielsweise) Lücken einbaust, wenn du dort variable Werte verwenden willst. Andererseites gibt es keinen sicherheitstechnischen Unterschied, wenn man mysql(i)_real_escape_string() richtig anwendet.

    Wenn du das Prinzip "in Code eingebettete Daten" verstanden hast, dann solltest du feststellen, dass genau das bei Prepared Statements nicht passiert und damit zumindest über die Platzhalter keine SQL-Injection stattfinden kann. Der Ablauf ist wie folgt: Der SQL-Statement-Text, bestehend nur aus Code und Platzhaltern (und oben genannte variable Dinge außer Acht lassend), geht in einem ersten Schritt (Prepare) zum Server. Die Daten werden nun den Platzhaltern zugewiesen und gehen in einem zweiten Schritt (Execute) an den Server. Bei diesem Execute werden sie nicht in Code eingebettet, sondern sauber einzeln verpackt, weswegen sie auch nicht als Code missinterpretiert werden können, was sonst beim fehlerhaften Einbetten der Fall sein kann. Dass der Execute-Schritt und die weitere interne Verarbeitung im Server sicher ist, darauf musst du dich verlassen. Beeinflussen kannst du das sowieso nicht (nur durch Ersetzen einer fehlerhaften Server-Version durch eine korrigierte).

    • Ist da wirklcih ein Geschwindigkeitszuwachs bei MySQLi & Prepared Statements?

    Bei welchen Vorgängen konkret? Beim Suchen der Daten nicht. Wenn das Statement an sich Mist ist, ändern P.S. nichts daran. Wenn du hingegen ein einmal präpariertes Statement mehrfach nutzen kannst, ergibt es da schonmal einen Geschwindigkeitsvorteil, weil das ständige Parsen entfällt. Hast du hingegen pro Script-Instanz nur ein Execute zum Prepare, dann kann das Ganze sogar länger dauern, weil du nun zwei Übertragungen zum Server hast, Prepare _und_ Execute statt _einem_ vollständigen SQL-Statement. (Wenn dann noch das Netzwerk langsam ist ...) Insgesamt sind die Zeitdifferenzen an und für sich jedoch gering. Mit anderen Methoden kann man meist deutlich mehr rausholen (zum Beispiel Index). Bei konkreten Problemen gilt wie immer: Ist-Zustand messen, dann ändern, wieder messen und so Erfolg oder Nichterfolg der Änderung erkennen.

    • Was muss ich bei MySQLi noch beachten?

    Wenn du bisher nur die mysql-Extension verwendet hast, musst du beachten, dass einige Funktionen anders arbeiten, vor allem, was die Bereitstellung der Ergebnismenge anbelangt. Da muss man bei mysqli mitunter explizit eine Hintergrundübertragung der Ergebnismenge anstoßen (store_result), damit Funktionen wie num_rows richtige Ergebnisse liefern. Das steht aber alles im PHP-Handbuch bei den betroffenen Funktionen dabei.

    • Was muss ich außer SQL Injectino noch bei meinen Scripts beachten?

    Kontextwechsel treten nicht nur bei SQL-Statements auf sondern an allen Stellen, an denen Daten in Code eingebettet werden.

    Lo!