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
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    Zitat von Alf2016 Beitrag anzeigen
    Was wäre da jetzt falsch? Das $abc? Wie würde das richtig aussehen? Kann man auch die Tabelle als Parameter eingeben?
    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.

    Kommentar


    • #47
      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.
      Ich komme immer mehr zu dem Zwischenfazit, daß unter Web-Programmierern nicht besonders sorgfältig gearbeitet wird. Nehmen wir diese "dynamisch zusammengesetzte" Abfrage oben: Was kann dazu führen, daß sowas dynamisch geschehen muß? Dein ORM? Wenn du das sagst, ok. Interessiert mich aber nicht, brauch ich nicht.
      Also von Entwicklern/Administratoren festgelegten Werte[ ].
      Das wäre z.B. im Falle der Funktion so, die ich einem Besucher in https://www.php.de/forum/webentwickl...90#post1547190 vorgeschlagen habe. Da wird in den Parametern die Tabelle, ggfs. eine Abfrage statt dessen - in der Form
      Code:
      (tabelle1 LEFT JOIN tabelle2 ON tabelle1.t1_ID = tabelle2.t2_t1_ID_FK) INNER JOIN ...
      - die Feldliste als Array und ein WHERE-Clause sowie ein ORDER BY clause als optionale Parameter übergeben. Außerdem wird die "Gruppierungsspalte" und die zu summierende Spalte übergeben. Alles als Text. Diese Texte werden nun gründlich auseinandergenommen mit dem Ziel, festzustellen, ob es die genannten Tabellen und die Felder überhaupt gibt.

      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


      • #48
        Zitat von Alf2016 Beitrag anzeigen
        Dazu wird gegen das information_schema auf Existenz abgeprüft. Ergebnis ist, das nur noch Elemente überbleiben, die es in der DB gibt.
        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.

        Kommentar


        • #49
          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.
          Selbstverständlich. Wollen wir jetzt ein Brainstorming machen, was da noch alles reingehört? Vielleicht fallen mir dann alle Prüfroutinen wieder ein, die ich 2012 für eine umfangreich SAP-Datenübernahme entwickelt habe. Vielleicht auch nicht. Vielleicht fallen dir die fehlenden ein, vielleicht auch nicht. Was willst du eigentlich mit sowas erreichen? Es geht um das grundsätzliche Problem und da warst gerade du es, der nachgewiesen hat, daß prepared statements hier nicht helfen würden.

          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


          • #50
            Zitat von hellbringer
            Plausibilitä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.
            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 glauben
            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


            • #51
              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 glauben
              Daß es hier um "Glaubensfragen" geht, war von der 1. Minute an mein Verdacht. Spaß beiseite: Welche alternative bzw. über die Behandlung mit
              PHP-Code:
              mysqli_real_escape_string 
              hinaus gehende Behandlung des Kontextwechsels schlägst du vor?

              Kommentar


              • #52
                Hä?

                Daß es hier um "Glaubensfragen" geht, war von der 1. Minute an mein Verdacht.
                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 gesamt einfach sicherer machen bzw. die Lampe einfach leuchtet (Analogie zum Strom).

                Spaß beiseite: Welche alternative bzw. über die Behandlung mit hinaus gehende Behandlung des Kontextwechsels schlägst du vor?
                Ich glaube der Begriff Prepared Statements ist in diesem Thread noch kaum gefallen

                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


                • #53
                  Zitat von hausl Beitrag anzeigen
                  Hä?



                  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.
                  Auf einmal fällt dir die "Denkpause" wieder ein. Du hast in meinem letzten Post wohl das eine oder andere mißverstanden: "Glaubensfrage" war ganz anders gemeint und mit dem Hinweis "von der 1. Minute an" eigentlich auch verständlich, aber gut. Was die Alternativen zu mysqli_real_escape_string betrifft: Da war nicht die grundlegende Alternative Prepared Statements gemeint und somit auch dein schulmeisterlicher Hinweis "Ich glaube der Begriff Prepared Statements ist in diesem Thread noch kaum gefallen " überflüssig. Mir ging es darum und ich versuche die Frage ein letztes Mal möglichst präzise und unmißverständlich zu formulieren: Gibt 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.

                  Kommentar


                  • #54
                    Zitat von Alf2016 Beitrag anzeigen
                    Gibt 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.
                    Keine Ahnung, ich schreibe nicht absichtlich Steinzeitcode, sondern setze auf moderne Maßnahmen. Warum sich unnötig das Leben schwerer machen?

                    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


                    • #55
                      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?...
                      Vielleicht findest du ja hier (S. 6 des pdf, untere Hälfte der Seite, Stichworte "Metallblock", "Feile") die Antwort.

                      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


                      • #56
                        Bzgl. Kontextwechsel gibt es hier auch eine kurze Zusammenfassung: https://php-de.github.io/jumpto/kontextwechsel/
                        Competence-Center -> Enjoy the Informatrix
                        PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                        Kommentar


                        • #57
                          Zitat von Arne Drews Beitrag anzeigen
                          Bzgl. Kontextwechsel gibt es hier auch eine kurze Zusammenfassung: https://php-de.github.io/jumpto/kontextwechsel/
                          Danke, ich schau's mir an.

                          Kommentar


                          • #58
                            Zitat von hellbringer Beitrag anzeigen
                            Es gibt Werkzeuge, die einem die Arbeit wesentlich einfacher machen als früher. Absichtlich veraltete Werkzeuge zu verwenden grenzt an Masochismus.
                            oder man nutzt sowas als handicap, mache sehen solche sachen sehr sportlich, besonders bei veralteter Hardware.
                            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


                            • #59
                              so leute es läuft jetzt alles danke an alle

                              Kommentar

                              Lädt...
                              X