Datensatz kann in mySQL nicht abgespeichert werden

Zitat von timtim

wie ich z.B. vom User sowohl die abzufragenden Felder + dynamische wehre Bedingungen in ein Prepaid Statement setze

Perfekt: hab das gerade geposted.

Prepared Statements (PDO) copy|paste Beispiele.

Zitat von timtim

der overhead von PreparedStatements zu Verschwendung von Ressourcen führt

Glaub mit - da draußen ist das das geringste Problem.

Sicherheit > "speed".

Zitat von timtim

wirkt auf mich auch eher als wolle man sich nicht mit der sache beschäftigen.

Ich hab mich lange damit beschäftigt.

Das Problem ist, dass man das nicht so einfach runterschreiben kann.

Es würde einfach so lang werden, dass es keiner liest.

Aber es gibt vieles im Netz dazu. Was ich hier versucht ist, den Leuten klar zu machen, dass es "da was gibt" - Problem und Lösung.

Generell: auf SQL-Injections hinweisen. Alle Daten sind böse.

Im Detai: in Richtung Prepared Statements lenken, damit die Leute sich damit beschäftigen.

Zitat von timtim

Und ebenfalls verschleiert es für Anfänger die eigentliche Problematik: die Wichtigkeit der Validierung der eingaben

Du prüftst, ob die email zu lang ist.

Du prüfst, ob der nickname legal, nicht leer, und nicht schon vergeben ist.

...

Aber Du kannst nicht alle Injections der Welt kennen.

Das, also das Thema Sicherheit, überlassen wir dem MySQL Server (bei richtiger Bediehnung).

Dein Beispiel ist mir schon bewusst, aber da sind wieder injections möglich, weil das Prepare das nicht abfängt, deswegen brauchst du ja eine WhiteList und da kommt das escapen bzw. anderweitige validieren ins spiel, was du ja machst. *_real_escape_string wäre zum prüfen ebenfalls möglicht.

Zitat

Glaub mit - da draußen ist das das geringste Problem.

Sicherheit > "speed".

Ich weiß nicht wo dein da draußen ist, aber mein "da draußen" läuft über skalierbare Cloud Anwendungen, wir nutzen dort andere Technologien, und kein MySQL, und ja die Sicherheit ist wichtiger, aber die kommt an anderer stelle. Prepared Statements blockieren dir da ggf. andere Ressourcen und dann kommen Kosten hinzu. Das Prepared Statements auch kein QueryCaching erlauben ist ein anderes Thema. Hier nur der bezug auf deine Aussage Sicherheit > "speed" Ja, aber nicht über PreparedStatements weil der Sicherheitsaspekt zu den Prepared Statements kleiner ist als der Overhead.

Zitat

Aber Du kannst nicht alle Injections der Welt kennen.

Das, also das Thema Sicherheit, überlassen wir dem MySQL Server (bei richtiger Bediehnung).

Prepared Statements schützen nur vor first-order injections nicht second-order und wir überlassen lieber nicht dem SQL-Server die Sicherheit, wir überlassen ihm hier das richtige aufbereiten der Nutzdaten, wie auch dein beispiel zeigt.

Zitat

Ich hab mich lange damit beschäftigt.

Lange muss nicht richtig heißen. Pauschal aussagen bekommen pauschal antworten.

*Edit:

Ich hab das beispiel noch weiter angeschaut, du erstellt und änderst da auch nichts an der DB / Tabellen, was ebenfalls eine Anforderung war.

Grüße

Timo

Zitat von timtim

Dein Beispiel ist mir schon bewusst, aber da sind wieder injections möglich, weil das Prepare das nicht abfängt, deswegen brauchst du ja eine WhiteList und da kommt das escapen bzw. anderweitige validieren ins spiel, was du ja machst. *_real_escape_string wäre zum prüfen ebenfalls möglicht.

Könnte man sich streiten. Ich vertraue da einer whitelist (viel) mehr.

Zitat von timtim

mein "da draußen" läuft über skalierbare Cloud Anwendungen,

Naja, das wird dann wohl doch ein bissl zu viel für das Forum, oder?

Zitat von timtim

Hier nur der bezug auf deine Aussage Sicherheit > "speed" Ja, aber nicht über PreparedStatements weil der Sicherheitsaspekt zu den Prepared Statements kleiner ist als der Overhead.

Für Anfänger, die hier im Forum lernen? Ach komm.

Das bischen overhead ... wenn überhaupt.

Ich hab das nicht getestet, aber die real escape Funktion nutzt das db handle,

also wird die auch beim MySQL Server anfragen. Und das per call (value).

Zitat von timtim

Prepared Statements schützen nur vor first-order injections nicht second-order

Bin mir fast ganz sicher, das die Aussage falsch ist.

Wenn ich second order injection richtig verstanden habe, dann kann*1 beim Verwenden der Daten aus der db

in einer Query die (2nd order) injection möglich werden.

*1 Aber dann eben nicht. Denn da nutzten wir doch auch wieder Prepared Statements.

Wer sowas schreibt ... WHERE foo = {$row['foo']} ... gehört ... belehrt

Und genau das is es btw, was ich immer sage: alle Daten sind böse. Selbst die in der eigenen db.

Und daher gilt doch, was ich am Anfang sagte: die Daten gehen so wie sie sind in die db.

Zitat von timtim

Lange muss nicht richtig heißen. Pauschal aussagen bekommen pauschal antworten.

Hehe, you got me there. Naja, Wochen, Momante. Weiß nicht mehr.

Aber ich bin keiner, der code kopiert. Ich will (so weit möglich) wissen wie und warum etwas funktioniert.

Das ist zu einer Grundsatzdiskussion geworden, die glaube ich keinem etwas bringt.

Es ging im Grunde nur darum, dass die Aussage, man sollte escape_string Funktionen niemals ( O-Ton: nie mehr ) nutzen, einfach falsch ist.

Keiner stellt in Frage, dass PreparedStatements i.d.R. die sinnvollere Wahl sind und man dann auf extra escaping verzichten kann, deshalb ist das escaping aber nicht perse überflüssig. Aber genau das wurde den "Anfängern", die hier im Forum lernen von Dir suggeriert.

Um mehr ging es nicht.

Zitat von cottton

Aber ich bin keiner, der code kopiert. Ich will (so weit möglich) wissen wie und warum etwas funktioniert.

Im Grunde schätze ich Dich auch so ein und denke auch, dass Du ausreichend Erfahrungen hast. Umso mehr hat es mich halt gewundert, wie Du reagierst, wenn man versucht darauf hinzuweisen, dass eine Aussage nicht ganz richtig ist.

Das nur zur Klarstellung, mehr habe ich zu dem Thema jetzt nicht mehr zu sagen.

Wollte dann auch nur kurz nee meinung sagen.

In den letzten 2 Jahren wurde mir ständig gesagt escapen nicht vergessen.

Muß auch dazu sagen das Pdo nicht mein fall ist und Prepared Statements auch nicht.

Deswegen kenne ich es nicht anders und versuche da auch immer drauf zu achten das escapen.

Da im Anfangsbeitrag kein Pdo oder Prepared Statements angewendet wurde habe ich natürlich gesagt das escapen sein muß.

Beim nächsten mal werde ich Neulinge drauf hinweißen es mit Prepared Statements , PDO zu versuchen da es damit aufjedefall sicherer ist.

Nach meinen Beitrag #2 und die Antwort das ich falsch liege traute ich mich gar nix mehr zu schreiben ( habe es ja anders gelernt ).

Normalerweiße ist das so , wenn ich was falsches sage ,schreibt sofort einer was dazu.

Da aber m.scatello nix zu meinen Beitrag gesagt hat ( er sagt sofort was wenn ich falsch liege ) und dann aber von cottton was gesagt wurde wahr ich sprachlos.

Vieleicht sollte man solche Antworten das ( ich falsch liege ) dann anders Formulieren weil falsch scheint meine ausage ja nicht gewesen zu sein.

Da ihr beide , plus Arne Drews meiner Meinung nach die Php ,Sql Profis in diesen Forum seid , wäre es gut zu wissen was man beim nächsten schreiben und machen soll.

Wenn ich im anderen Forum sage lass das escapen weg kriege ich ein a.... tritt.

Werde aber aufjedenfall Prepared Statements empfehlen, da seid ihr euch ja einig das es aufjedenfall besser ist und einfacher für Neulinge.

Mfg Basti und bleibt alle Gesund

Zitat von Arne Drews

Das ist zu einer Grundsatzdiskussion geworden, die glaube ich keinem etwas bringt.

Richtig, ich hab mich hinreisen lassen

Nur kurz noch den Nachtrag zur Second Order

Grüße und frohes entwickeln,

Timo

Zitat von basti1012

Vieleicht sollte man solche Antworten das ( ich falsch liege ) dann anders Formulieren weil falsch scheint meine ausage ja nicht gewesen zu sein.

Ja, ich geb zu, dass war wohl too much von mir, sorry.

Werde das in dem Post editieren|markieren|notieren.

timtim