Rainer: mysql IN

Hallo,

$sql_em = "SELECT lfdnr_erinnerung,betreff FROM tabelle WHERE benutzer_id = '".$_SESSION["session_benutzerid"]."' OR herkunft = '".$_SESSION["session_herkunft"]."' OR benutzergruppe_id IN (".implode(",",$s_b).")";

Wenn ich das letzte "OR benutzergruppe_id IN (".implode(",",$s_b).")" weglasse funktioniert die Abfrage.

Die Testausgabe der Query sieht aber sauber aus.

SELECT lfdnr_erinnerung,betreff FROM tabelle WHERE benutzer_id = 'B_4fcc7ff051e4f' OR herkunft = 'DE' OR benutzergruppe_id IN (BG_5034adfe4ffdb,BG_5034adfe4ffe6,BG_5034adfe4fff1)

Geht das mit MySql nicht oder ist da doch ein Fehler.

Version 5.x

Gruß Rainer

  1. Hi,

    SELECT lfdnr_erinnerung,betreff FROM tabelle WHERE benutzer_id = 'B_4fcc7ff051e4f' OR herkunft = 'DE' OR benutzergruppe_id IN (BG_5034adfe4ffdb,BG_5034adfe4ffe6,BG_5034adfe4fff1)

    Müssten bei den Werten innerhalb der () nicht noch entsprechend ' gesetzt werden?
    IN ('BG_5034adfe4ffdb','BG_5034adfe4ffe6','BG_5034adfe4fff1')

    ~dave

    1. Moin!

      Müssten bei den Werten innerhalb der () nicht noch entsprechend ' gesetzt werden?
      IN ('BG_5034adfe4ffdb','BG_5034adfe4ffe6','BG_5034adfe4fff1')

      Joa. So is dat. Wird gern mal weggelassen wenn man code codet. Und dann is man gern auch schon betriebsblind. ;)

      --
      Signaturen sind blöd!
      1. Danke, das wars..

        1. Moin!

          Danke, das wars..

          Du hast keinerlei Escaping in deinem Code! Viva la SQL-Injection!

          - Sven Rautenberg

          1. Du hast keinerlei Escaping in deinem Code! Viva la SQL-Injection!

            Wie willst du mir in einem mit HTACCESS geschütztem Bereich, auf den man zusätzlich nur mit einer auf dem Server registrierten IP (bedeutet du musst eine feste IP haben, welche ich registrieren muss) in einem SELECT, welcher nur Daten aus der Session bzw. einem Array entgegennimmt, eine SQL-Injection verpassen?

            Überall WO es notwendig ist arbeite ich mit mysql_real_escape_string.

            Gruß Rainer

            1. Tach,

              Wie willst du mir in einem mit HTACCESS geschütztem Bereich, auf den man zusätzlich nur mit einer auf dem Server registrierten IP (bedeutet du musst eine feste IP haben, welche ich registrieren muss) in einem SELECT, welcher nur Daten aus der Session bzw. einem Array entgegennimmt, eine SQL-Injection verpassen?

              und du kannst auf ewig so garantieren, dass das so bleibt und es niemals eine Sicherheitslücke geben wird, die das aushebelt?

              Überall WO es notwendig ist arbeite ich mit mysql_real_escape_string.

              Es ist _immer_ notwendig.

              mfg
              Woodfighter

            2. Hi,

              Wie willst du mir in einem mit HTACCESS geschütztem Bereich, auf den man zusätzlich nur mit einer auf dem Server registrierten IP (bedeutet du musst eine feste IP haben, welche ich registrieren muss) in einem SELECT, welcher nur Daten aus der Session bzw. einem Array entgegennimmt, eine SQL-Injection verpassen?

              Woher sollte Sven wissen, dass das so ist?

              Überall WO es notwendig ist arbeite ich mit mysql_real_escape_string.

              IMHO ist es _immer_ sinnvoll Daten kontextgerecht zu behandeln.

              ~dave

            3. Moin!

              Wie willst du mir [...]  in einem SELECT [...] eine SQL-Injection verpassen?

              Das hast Du aber nicht gefragt, oder?

              --
              Signaturen sind blöd!
            4. Moin!

              Du hast keinerlei Escaping in deinem Code! Viva la SQL-Injection!

              Wie willst du mir in einem mit HTACCESS geschütztem Bereich, auf den man zusätzlich nur mit einer auf dem Server registrierten IP (bedeutet du musst eine feste IP haben, welche ich registrieren muss) in einem SELECT, welcher nur Daten aus der Session bzw. einem Array entgegennimmt, eine SQL-Injection verpassen?

              Überall WO es notwendig ist arbeite ich mit mysql_real_escape_string.

              Es ist ÜBERALL notwendig.

              Warum Ausnahmen machen? Warum drüber nachdenken, ob der Bereich durch anderweitige Maßnahmen, die auch mal scheitern können (unachtsam deaktiviert etc.) oder diesen durch Kopieren von Code in einen ganz anderen Bereich verlassen, "gesichert" ist.

              Wenn man sich als professionellen Programmierer sieht, hat man solche Ausreden nicht nötig, wie du sie hier gerade anbringst. Sicherheit ist nie "optional" oder "gerade hier nicht notwendig".

              - Sven Rautenberg