Ankündigung

Einklappen
Keine Ankündigung bisher.

SQL Injection durch escapen verhinden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • SQL Injection durch escapen verhinden

    Hallo zusammen,

    ich beschäftige mich gerade mit dem abwehren von SQL Injection und bin hierbei auf den Beitrag in der Wissenssammlung gestoßen. Ich hätte dazu eine Frage, da ich das Escapen bei einer SQL Abfrage nicht ganz verstehe. Wie genau muss was bei einer SQL Abfrage escapt werden? Könnte mir da jemand ein einfaches Beispiel (anhand meinem Beispiel) nennen, (falsch und richtig).

    Beispiel:

    PHP-Code:
    mysqli_query($con"select id from tabelle where name='".$_POST["name"]."'");//  Meine momentane Abfrage; was muss hier escapt werden, damit es gegen SQL Injection sicherer ist 
    Sollte es noch weitere Möglichkeiten geben, wie ich diese Abfrage (mysqli) gegen SQL Injection absichern kann wäre ich sehr dankbar, wenn mir das jemand kurz (anhand meinem Beispiel) zeigen könnte

    Im Voraus ein Dankeschön
    Falke07

  • #2
    Such einfach nach "prepared statements" - das ist kein Hexenwerk, das gibt's zig tausend mal zu lesen. Hier z.B.

    https://phpdelusions.net/mysqli
    [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

    Kommentar


    • #3
      Und eine nette PHP-Referenz gibt es auch.

      PHP-Code:
      $name $con->escape_string($_POST["name"]);
      //lässt %_ wie sie sind 

      Kommentar


      • #4
        Such einfach nach "prepared statements"
        Bzw. zumindest das hier nutzen.. als prozeduale Variante (wie du verwendest).
        PHP-Code:
        mysqli_real_escape_string($con$sql); 
        Steht aber auch in der Doku.
        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


        • #5
          mysqli_real_escape_string
          bietet keinen geeigneten Schutz gegen SQL Attacken. Nur in Verbindung mit einer angemessenen Eingabeprüfung kann hier einigermassen sicher gegen Attacken vorgegangen werden. Dazu gehört, dass man die Daten vorab auf Länge und Typ überprüft.

          Aber "union all","truncate mytable" etc. würden dann auch nicht verhindert.

          Es ist schon schwierig dass einigermassen sicher gegen alle möglichen Angriffe hinzubekommen, will man doch bei Namen möglichst viel zulassen, damit "O'Brian" oder "Karl-Heinz" nicht abgelehnt werden.

          Einzig prepared Statements bieten hier einen Schutz.

          Ein Artikel zu der Problematik findet sich zum Beispiel hier.

          Kommentar


          • #6
            Zitat von protestix Beitrag anzeigen
            mysqli_real_escape_string
            bietet keinen geeigneten Schutz gegen SQL Attacken.
            Doch, ist es.

            Zitat von protestix Beitrag anzeigen
            Nur in Verbindung mit einer angemessenen Eingabeprüfung kann hier einigermassen sicher gegen Attacken vorgegangen werden. Dazu gehört, dass man die Daten vorab auf Länge und Typ überprüft.
            Validierung hat nichts mit der Behandlung des Kontextwechsel zu tun. Und mit Angriffen auch nur bedingt (wenn es ein Bug ermöglicht), aber in der Regel nicht.

            Zitat von protestix Beitrag anzeigen
            Aber "union all","truncate mytable" etc. würden dann auch nicht verhindert.
            Das ist Code vom Programmierer und keine Daten. Weiß also nicht, was du meinst. Wenn dieser Text in den Daten drin steht, ist er wirkungslos, weil eben nur Daten.

            Zitat von protestix Beitrag anzeigen
            Es ist schon schwierig dass einigermassen sicher gegen alle möglichen Angriffe hinzubekommen, will man doch bei Namen möglichst viel zulassen, damit "O'Brian" oder "Karl-Heinz" nicht abgelehnt werden.
            Das ist eigentlich ganz einfach:

            1. Kontextwechsel beachten.
            2. Zeichenkodierung beachten.

            Fertig.

            Zitat von protestix Beitrag anzeigen
            Einzig prepared Statements bieten hier einen Schutz.
            Prepared Statements sind eine andere Herangehensweise. Die Vorteile davon sind ganz andere. Mit Schutz hat das nicht wirklich was zu tun.

            Kommentar


            • #7
              hellbringer
              hast du den von mir verlinkten Artikel gelesen?
              Da wird auf die Problematik eingegangen.

              Das Thema heisst: "SQL Injection durch escapen verhinden"

              Escaping(Maskierung von Zeichen) verhindert eben nicht SQL Injection, wenn man sich nur auf mysqli_real_escape_string verlässt.
              Zahlreiche Artikel belegen dass.

              Das prepared statements eine andere Vorgehensweise sind, sollte klar sein, dennoch ist nicht von der Hand zu weisen, dass durch die Trennung von Statement und Daten ein ziemlich hoher Schutz besteht.


              Kommentar


              • #8
                Zitat von protestix Beitrag anzeigen
                hast du den von mir verlinkten Artikel gelesen?
                Da wird auf die Problematik eingegangen.
                Ich habs kurz überflogen und nur eine Problematik mit missachtetem Kontextwechsel gesehen.

                Zitat von protestix Beitrag anzeigen
                Das Thema heisst: "SQL Injection durch escapen verhinden"

                Escaping(Maskierung von Zeichen) verhindert eben nicht SQL Injection, wenn man sich nur auf mysqli_real_escape_string verlässt.
                Zahlreiche Artikel belegen dass.
                Natürlich wird es dadurch verhindert den Kontextwechsel zu beachten.

                Zitat von protestix Beitrag anzeigen
                Das prepared statements eine andere Vorgehensweise sind, sollte klar sein, dennoch ist nicht von der Hand zu weisen, dass durch die Trennung von Statement und Daten ein ziemlich hoher Schutz besteht.
                Auch Prepared Statements verhindern keine SQL-Injections, wenn der Programmierer Mist baut. Aber das ist weder Schuld der Prepared Statements noch Schuld von mysqli_real_escape_string(). Dann wurden die Tools vom Programmierer einfach falsch verwendet.

                Kommentar


                • #9
                  Zitat von protestix Beitrag anzeigen
                  hellbringer

                  Escaping(Maskierung von Zeichen) verhindert eben nicht SQL Injection, wenn man sich nur auf mysqli_real_escape_string verlässt.
                  Zahlreiche Artikel belegen dass.
                  Könntest du einen dieser Artikel mal verlinken? Ich benutze es nicht, trotzdem sehe ich keinen Grund warum escaping mit den entprechenden Datenbankfunktionen ein Problem sein sollte. Namen wie "O'Brian" kann man defintitiv problemos eintragen wenn man kine prepared statements verwendet, sondern escaping.

                  Auch Prepared Statements verhindern keine SQL-Injections, wenn der Programmierer Mist baut. Aber das ist weder Schuld der Prepared Statements noch Schuld von mysqli_real_escape_string(). Dann wurden die Tools vom Programmierer einfach falsch verwendet.
                  Ebenso würde mich hierfür ein konkretes Beispiel interessieren. Ich sehe keine Möglichkeit wie bei Trennung von SQL Anweisung und Daten noch SQL-Injection möglich sein soll.

                  Kommentar


                  • #10
                    Zitat von ChromOxid Beitrag anzeigen
                    Ebenso würde mich hierfür ein konkretes Beispiel interessieren. Ich sehe keine Möglichkeit wie bei Trennung von SQL Anweisung und Daten noch SQL-Injection möglich sein soll.
                    Das meine ich mit Mist bauen. Ist ja schon oft genug in diesem und anderen Foren vorgekommen, dass Leute Prepared Statements verwenden, dann aber die Werte direkt in den SQL-Code einfügen.

                    Kommentar


                    • #11
                      ChromOxid
                      http://www.sqlinjection.net/advanced...escape-string/
                      Artikel bei stackoverflow zum Thema

                      Kommentar

                      Lädt...
                      X