Ankündigung

Einklappen
Keine Ankündigung bisher.

Wann genau sind Injections möglich?

Einklappen

Neue Werbung 2019

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

  • Wann genau sind Injections möglich?

    Wie der Titel bereits sagt, würde ich gerne wissen, wann genau Injections möglich sind. Ich habe jegliche Datenbankabfragen die Usereingaben enthalten mit mysql_real_escape_string escaped und Ausgaben zusätzlich noch mit htmlentities. Ist das sicher genug? Und könnte beispielsweise hier
    PHP-Code:
    SELECT FROM user WHERE bann '1' ORDER BY id DESC LIMIT 15 
    Auch eine Injection möglich sein? Ich danke für Antworten!

  • #2
    http://php-de.github.io/jumpto/sql-injection/ . Im Grunde ist der "Kontextwechsel" die "Wurzel des Bösen".

    Und zu SELECT * hier noch: http://php-de.github.io/jumpto/code-smells/#select-

    LG
    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


    • #3
      Und falls du die Antwort auf dein Beispiel da oben nicht findest:
      Es ist zu empfehlen, jeden variablen Wert, der in Query-Strings eingefügt wird, durch die passende Escape-Funktion zu schicken.
      => Du hast keine variablen Werte, ergo auch nicht anfällig.

      Kommentar


      • #4
        Zitat von xkevin96x Beitrag anzeigen
        PHP-Code:
        SELECT FROM user WHERE bann '1' ORDER BY id DESC LIMIT 15 
        Übrigens.. warum ist 1 bei dir als String angegeben? Wenn bann 0 oder 1 sein kann (quasi true oder false) dann verwendet doch den Typ TINYINT mit 0 oder 1 als Zahl. Nur weils mir gerade aufgefallen ist
        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
          Und um auf dem neusten Stand zu sein solltest du auf PDO und Prepared-Statements umsteigen, dadurch kannst du dir das escapen sparen und bist trotzdem abgesichert.
          [QUOTE=nikosch]Macht doch alle was Ihr wollt mit Eurem Billigscheiß. Von mir aus sollen alle Eure Server abrauchen.[/QUOTE]

          Kommentar


          • #6
            Zusätzlich sollte dein Motto sein, vertraue niemanden, auch nicht deinen Benutzern. NIE

            Kommentar


            • #7
              Übrigens, das zusätzliche escapen mittels htmlentities() ist nicht nötig um SQL-Injections zu verhinden. (Das macht deine Daten unter Umständen sogar kaputt)

              Kommentar


              • #8
                Zitat von xkevin96x
                und Ausgaben zusätzlich noch mit htmlentities
                htmlentities() für Ausgaben ist ok.
                Und mysql_real_escape_string() für Eingaben die du in deiner query an die DB schickst.

                Siehe http://php-de.github.io/jumpto/kontextwechsel/ das ist im Grunde das Ganze Thema worum es bei dem escapen geht.

                Und den Post #5 beachten, die mysql_ Erweiterung sollte man gar nciht mehr verwenden, die fliegt bald komplett aus PHP raus. Siehe: http://php.net/manual/en/migration55.deprecated.php
                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

                Lädt...
                X