Zitat von Alf2016
Beitrag anzeigen
Ankündigung
Einklappen
Keine Ankündigung bisher.
Dätensätze aus Mysqltabelle ausgeben liefert keine Ergebnisse obwohl die Tags stimmen
Einklappen
Neue Werbung 2019
Einklappen
X
-
Zuletzt geändert von hellbringer; 23.01.2019, 22:02.
-
Zitat von hellbringer Beitrag anzeigen
Gar nicht. Bei Prepared Statements könnten Werte, aber keine Namen als Parameter übergeben werden. Möchte man Namen dynamisch in die Abfrage einfügen, muss man sich selber um die Verarbeitung kümmern. Ein vernünftiger Programmierer würde auch nicht auf die Idee kommen hier Benutzereingaben einzusetzen. Wenn Namen dynamisch eingefügt werden, dann in der Regel aus statischen Konfigurationen. Also von Entwicklern/Administratoren festgelegten Werten. Das ist auch das, was ein ORM macht, das ja auch SQL-Abfragen dynamisch erstellen muss.Also von Entwicklern/Administratoren festgelegten Werte[ ].Code:(tabelle1 LEFT JOIN tabelle2 ON tabelle1.t1_ID = tabelle2.t2_t1_ID_FK) INNER JOIN ...
Dazu wird gegen das information_schema auf Existenz abgeprüft. Ergebnis ist, das nur noch Elemente überbleiben, die es in der DB gibt. Da hat eingeschleuster Code, der hier ja nur von einem kriminellen Entwickler stammen kann, keine Chance.
Ergebnis ist ein "Datensatz" mit allen Bezeichnern, die es ermöglichen die Abfrage eindeutig zu formulieren. Die wird dann "zusammengeschnippelt und fertig.
Ich kenne das weder von der ABAP-Programmierung noch von der Programmierung mit VBA für Access anders.
Kommentar
-
Zitat von Alf2016 Beitrag anzeigenDazu wird gegen das information_schema auf Existenz abgeprüft. Ergebnis ist, das nur noch Elemente überbleiben, die es in der DB gibt.
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Das hält aber einen Angreifer auch nicht davon ab Elemente zu verwenden, die er gar nicht verwenden dürfte. Nur auf die Existenz alleine zu prüfen reicht nicht aus. Es muss auch irgendwo festgelegt sein (z.B. anhand einer Whitelist), welche überhaupt abgefragt werden dürfen.
Ich habe irgendwie den Eindruck, es fällt dir schwer, dich davon zu lösen, daß deine Lieblings-DBs, deine Liebslings-Features, -Implementierungen usw. nicht immer allle Problemfälle abdecken. Das tun sie einfach nicht. Und von daher finde ich meinen Weg, mich nicht vorschnell auf z.B. PostgreSQL statt MySQL, prepared statements statt mysqli, Objektorientierung statt prozeduraler Stil "zu schmeißen", gar nicht so schlecht. Wenn ich irgendwann was davon brauche, werde ich das früh genug erkennen und es anwenden. Dank der vielen Informationen aus diesem Forum, dank dir, protestix und anderen, werde ich den richtigen Zeitpunkt sicher nicht verpassen. Dafür sei dir gedankt. Ich wünsche uns allen eine geruhsame Nacht.
Kommentar
-
Zitat von hellbringerPlausibilitätsprüfungen haben nichts mit SQL-Injections zu tun. ...Zitat von Alf2016 Beitrag anzeigen...Natürlich haben die was miteinander zu tun. ...... Ich prüfe doch an jeder wichtigen Stelle (u.a. bei Kontextwechsel, aber längst nicht nur da), ob Daten- so überhaupt zulässig sind
- sie in dem erwarteten Range sind oder so gar nicht auftreten dürften bzw. ob völlig anders darauf zu reagieren ist
- ob sie den richtigen Datentyp haben (Dein "1 or 1" ist kein Integer, würde also sofort bei der Typprüfung durchfallen)
- usw.
Ob jemand ein Geburtsdatum 01.01.1900 haben kann ist eine Plausibilitätsprüfung hat aber mit einer SQL-Injection nichts zu tun. Wenn jemand durch die Eingabe versucht konkret die SQL-Syntax deiner Abfrage zu manipulieren, dann schon.
Der Kontextwechsel ist quasi die erste Ebene. Da geht es auch um Syntaxüberschneidungen etc.. Injections können daher auf Grund vom Kontextwechsel passieren oder aber wie weiter oben gezeigt auch ohne/direkt.
Somit Kontextwechsel hat in der Ebene als Begriff für sich in dieser ersten Ebene eigentlich noch nichts mit Plausibilität und Ranges etc. zu tun. Das passiert dann nachrangig, weil natürlich zuerst mal die korrekte Behandlung von "eingehenden" Daten syntaxtechnisch auf den Boden gebracht werden muss.
Schau dir mal den hier zB an: https://wiki.selfhtml.org/wiki/Progr...Kontextwechsel
Alles andere wurde oben schon gesagt, du kannst den anderen hier ruhig glaubenThe string "()()" is not palindrom but the String "())(" is.
Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
PHP.de Wissenssammlung | Kein Support per PN
- 1 Likes
Kommentar
-
Zitat von hausl Beitrag anzeigen
Alf2016 Du machst hier halt zwei Dinge auf einmal die sicherheitstech. "irgendwie" schon zusammengehören (sollten Hand in Hand gehen) und dennoch eigene Dinge mit eigenen Namen und Charakteristiken sind.
Ob jemand ein Geburtsdatum 01.01.1900 haben kann ist eine Plausibilitätsprüfung hat aber mit einer SQL-Injection nichts zu tun. Wenn jemand durch die Eingabe versucht konkret die SQL-Syntax deiner Abfrage zu manipulieren, dann schon.
Der Kontextwechsel ist quasi die erste Ebene. Da geht es auch um Syntaxüberschneidungen etc.. Injections können daher auf Grund vom Kontextwechsel passieren oder aber wie weiter oben gezeigt auch ohne/direkt.
Somit Kontextwechsel hat in der Ebene als Begriff für sich in dieser ersten Ebene eigentlich noch nichts mit Plausibilität und Ranges etc. zu tun. Das passiert dann nachrangig, weil natürlich zuerst mal die korrekte Behandlung von "eingehenden" Daten syntaxtechnisch auf den Boden gebracht werden muss.
Schau dir mal den hier zB an: https://wiki.selfhtml.org/wiki/Progr...Kontextwechsel
Alles andere wurde oben schon gesagt, du kannst den anderen hier ruhig glaubenPHP-Code:mysqli_real_escape_string
Kommentar
-
Hä?
Daß es hier um "Glaubensfragen" geht, war von der 1. Minute an mein Verdacht.
Spaß beiseite: Welche alternative bzw. über die Behandlung mit hinaus gehende Behandlung des Kontextwechsels schlägst du vor?
Ich denke es ist hier alles mittlerweile mehrmals gesagt worden und irgendwo sprachst du eigentlich von einer "Denkpause". Ev. sollten wir es hier dabei belassen.
Ich bin jedenfalls mal raus. Von meiner Seite ist alles gesagt.The string "()()" is not palindrom but the String "())(" is.
Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
PHP.de Wissenssammlung | Kein Support per PN
Kommentar
-
Zitat von hausl Beitrag anzeigenHä?
Eben nicht. Es gibt genaue Namen für genaue Dinge. "Strom" ist in Wahrheit auch viel mehr im Detail und du "machst Sicherheit" wenn du es so nennen willst. Gehört zusammen aber sind im Detail unterschiedliche Dinge die unterm Strich die Anwendung einfach sicherer machen und die Lampe einfach leuchtet (Analogie zum Strom).
Ich glaube der Begriff Prepared Statements ist in diesem Thread noch kaufm gefallen
Ich denke es ist hier alles mittlerweile mehrmals gesagt worden und irgendow sprachst du von einer "Denkpause". Ev. sollten wir es hier dabei belassen.
Ich bin jedenfalls mal raus. Von meiner Seite ist alles gesagt.
Kommentar
-
Zitat von Alf2016 Beitrag anzeigenGibt es im Rahmen des prozeduralen Stils, ohne Verwendung von prepared statements und über die Verwendung von "mysqli_real_escape_string" hinaus noch Maßnahmen, die man beim Kontextwechsel zur Anwendung bringen sollte? Vielleicht kannst du oder jemand anders das noch "schnell" beantworten.
Es gibt keinen Grund heutzutage nicht Prepared Statements zu verwenden, außer vielleicht nostalgische Gefühle. Es gibt Werkzeuge, die einem die Arbeit wesentlich einfacher machen als früher. Absichtlich veraltete Werkzeuge zu verwenden grenzt an Masochismus.
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Keine Ahnung, ich schreibe nicht absichtlich Steinzeitcode, sondern setze auf moderne Maßnahmen. Warum sich unnötig das Leben schwerer machen?...
Für alle, die was zum Kontextwechsel wissen möchten: Ich bin bei selfhtml fündig geworden. Ob da nun alles steht oder ob es darüber hinaus noch wichtige Dinge, ggfs. eine direkte Antwort auf meine Frage aus #53 gibt, weiß ich nicht. Von daher ist jeder, der noch was zum Thema weiß, eingeladen, es zu posten (Zustimmung des TE vorausgesetzt).
Kommentar
-
Bzgl. Kontextwechsel gibt es hier auch eine kurze Zusammenfassung: https://php-de.github.io/jumpto/kontextwechsel/Competence-Center -> Enjoy the Informatrix
PHProcks! • Einsteiger freundliche Tutorials • PreComposed Packages
Kommentar
-
Zitat von Arne Drews Beitrag anzeigenBzgl. Kontextwechsel gibt es hier auch eine kurze Zusammenfassung: https://php-de.github.io/jumpto/kontextwechsel/
Kommentar
-
Zitat von hellbringer Beitrag anzeigenEs gibt Werkzeuge, die einem die Arbeit wesentlich einfacher machen als früher. Absichtlich veraltete Werkzeuge zu verwenden grenzt an Masochismus.
Rcitig ist, "state of the art" hat nichts aber auch gar nichts mit persöhnlichen präffrenzen zu tun, und für Glaubenfragen gibt es in den meisten Religionen zuständige stellen.
Dass Dich erst nach Deinem 184 Post mit der Wissens Sammlung beschäftigst, strange.
Da postet man doch lieber:
Vielleicht kannst du oder jemand anders das noch "schnell" beantworten.
Kommentar
Kommentar