nicht angemeldet
Hi!
Ich wollte ja keine 100 Beispiele. Ein einziges, in etwa wie ...
Gibts im PHP-Handbuch zu den entsprechenden Funktionen. Ich spare mir das. Vielleicht verlinke ich noch die Beispielseite direkt.
... und dazu ein Satz wie "Egal welchen Wert $bla annimmt, ist SQL Injection unmöglich, ohne dass manuelles Quoting nötig ist."
Ist drin.
Keine Kritik an Dir, sondern an PHP: Quoting-Funktionen einzeln für jede einzelne DB und jedes einzelne Interface ist Krampf.
Das liegt an den einzeln hinzugefügten Extensions für die verschiedenen DBMS. Es gibt ja PDO, das eine einigermaßen einheitliche Oberfläche bereitstellt.
Ich vermisse die Aussage, dass bei Prepared Statements das Quoting-Problem wegfällt und damit das Risiko der SQL-Injection wegfällt.
[...] Das Problem beim Kontextwechsel ist nicht primär der Sicherheitsaspekt. Deswegen reite ich auch nicht zu sehr auf dieser "Dramatik" rum.Ich denke, Du solltest darauf herumreiten. SQL Injections kommen genau durch verpaßte Kontext-Wechsel zustande, genau wie Code Injections und Shell Injections.
Wenn der Sicherheitsaspekt zu sehr im Vordergrund steht, denkt jeder nur an Sicherheitsaspekte. "Hier kommen meine Daten aus einer sicheren Quelle, da maskiere ich jetzt mal nichts" - solche Denkweise will ich durch das allgemeine und nicht nur sicherheitsspezifische Sensibilisieren erreichen.
Erheblich wird der Mehraufwand unter mysqli, wenn das Statement auch noch erst zur Laufzeit zusammengebaut werden soll.
Irgendetwas verstehe ich hier nicht. Wo ist der Mehraufwand? sprintf und prepare unterscheiden sich nur im Platzhalter-Zeichen, quoting jedes einzelnen Parameters entfällt, do() wird durch execute() ersetzt.
Es ist unter mysqli nicht vorgesehen, ein Array von Werten zu binden, nur einzelne Variablen. Wenn man eine unbestimmte Anzahl Werte hat, muss man das sehr umständlich programmieren. Da kommt man wesentliche einfacher mit dem Selbst-Quoten und -Maskieren.
Du kannst execute() mit dem selben Handle mehrfach aufrufen. (Jedenfalls kann DBI das.)
Das Handle wird spätestens am Requestende entsorgt.
Nö, beim expliziten Aufruf von finish() oder implizit wenn $sth aus dem Scope läuft.
Am Requestende ist unter PHP auch der Scope zu Ende. Punkt. Da ist nichts mit Wiederverwendbarkeit von Ressourcen.
Der normale Query-Cache jedenfalls vergleicht die SQL-Statements erst nach der Platzhalter-Ersetzung. Alles andere wäre ja auch nicht sinnvoll, weil das Ergebnis ja von diesen Werten abhängig ist.
Das ist MySQL, da funktioniert vieles etwas anders als bei anderen (ich bin versucht, "richtgen" zu schreiben) RBDMS.
Der Query-Cache speichert die Ergebnismenge. Die ist abhängig von den übergebenen WHERE-Parametern. Das ist in jedem DBMS so.
Wer für das Thema erst einmal sensibilisiert ist, wird sich die entsprechenden Funktionen in anderen Systemen raussuchen können, finde ich.
OK. Vielleicht ergänzt Du dann den Titel um "in PHP" bzw. "mit PHP"?
Der Artikel ist ja nun auch unter PHP angesiedelt.
Da ich nicht mit allen DBMS-Schnittstellen Erfahrung habe, möchte ich dazu auch nichts sagen. Manche sind auch zu exotisch. Der Artikel sollte auch nicht zu voll werden.
Ist nun doch "zu voll" geworden ...
Genau das ist der Unterschied zwischen PHPs Datenbank-Anbindung und DBI. Mit DBI muß ich keine Erfahrungen mit unterschiedlichen Datenbanken haben. So lange ich keine DB-spezifischen SQL-Erweiterungen benutze, ist DBI-basierender Code komplett von der DB und der DB-Schnittstelle unabhängig, die einzige notwendige Änderung für die Migration auf eine andere DB ist der Connect-String, der ohnehin meistens in einer Konfigurationsdatei steht.
Wenn du dabei nur den Perl-Code im Auge hast, so mag das stimmen. SQL-Dialekte und Features sind aber zu unterschiedlich, um nur mit einem Connectionstring-Ändern komplett auf ein anderes DBMS umstellen zu können. Wenn man mehr als 0815-Abfragen gegen das DBMS sendet, bleibt das ein unrealistisches Wunschdenken.
Lo!
Auge