Christian Seiler: Sicherheitslücke in sehr vielen regulären Ausdrücken

Hallo Forum,

Ich wollte Euch nur aufmerksam machen auf einen Blog-Eintrag von Stefan Esser zum Thema "Reguläre Ausdrücke". Dort beschreibt er, dass das $-Zeichen in regulären Ausdrücken etwas anderes tut, als die meisten Leute erwarten. So kann es durchaus passieren, dass unzulässiger User-Input durchgelassen wird, obwohl er nicht sollte.

Viele Grüße,
Christian

  1. gudn tach!

    Blog-Eintrag von Stefan Esser zum Thema "Reguläre Ausdrücke"

    was "$" ma(t)cht ist mir klar, ich habe allerdings die potentielle sicherheitsluecke nicht verstanden.

    "In several circumstances a newline character can be dangerous. For example when you want to stop HTTP Response Splitting or Email Injection attacks."

    hat jemand je ein beispiel fuer "dangerous" parat?
    in einem e-mail-header wuerde ein zusaetzliches "\n" doch bloss dazu fuehren koennen, dass der header nicht vollstaendig ist und die e-mail z.b. gar nicht oder mit leerem betreff oder sowas gesendet wird.

    prost
    seth

    1. hi,

      in einem e-mail-header wuerde ein zusaetzliches "\n" doch bloss dazu fuehren koennen, dass der header nicht vollstaendig ist und die e-mail z.b. gar nicht oder mit leerem betreff oder sowas gesendet wird.

      http://www.drweb.de/webmaster/kontakt-formulare.shtml

      gruß,
      wahsaga

      --
      /voodoo.css:
      #GeorgeWBush { position:absolute; bottom:-6ft; }
      1. gudn tach!

        in einem e-mail-header wuerde ein zusaetzliches "\n" doch bloss dazu fuehren koennen, dass der header nicht vollstaendig ist und die e-mail z.b. gar nicht oder mit leerem betreff oder sowas gesendet wird.

        http://www.drweb.de/webmaster/kontakt-formulare.shtml

        hilf mir auf die spruenge, denn dort habe ich nicht finden koennen, was an einem abschliessenden "\n" so schlimmes sein soll. (es geht wohlgemerkt nicht um eingaben a la "irgendjemand@irgendwo.xyz\nCc: spamopfer@sonstwo.xyz, nocheinopfer@anderswo.xzy", sondern nur um sowas wie "foo@example.org\n".)

        prost
        seth

        1. gudn tach!

          geh ich nun recht in der annahme, dass mir hier keiner erklaeren kann, was nun genau die besagte sicherheitsluecke ist? oder s/kann/will/ (was ja noch verstaendlich waere)?

          ein analoger fragender eintrag meinerseits im php-blog blieb bisher ebenfalls unbeantwortet.

          prost
          seth

          1. Hallo seth,

            geh ich nun recht in der annahme, dass mir hier keiner erklaeren kann, was nun genau die besagte sicherheitsluecke ist? oder s/kann/will/ (was ja noch verstaendlich waere)?

            Naja, zumindest kommt Inhalt durch, der sonst nich durchkommen sollte. Und wenn der Parameter als letztes in eine Header-Zeile (E-Mail, HTTP, sonstwas) eingefügt wird, dann kann zumindest der Header vorzeitig terminiert werden, was zu unerwarteten Effekten führen kann. Hängt vermutlich stark von der Einzelanwendung ab, ob die Neue-Zeile nun wirklich ein Problem ist, oder nicht. Ich könnte mir auch vorstellen, dass im Einzelfall das vorzeitige Beenden vom Header dazu führen kann, dass dadurch bestimmte Informationen preisgegeben werden, die sonst nicht preisgegeben würden. Vermutlich dürfte es beim 0815-Formmailer aber nicht wirklich etwas ausmachen.

            Viele Grüße,
            Christian

            1. gudn tach Christian!

              Naja, zumindest kommt Inhalt durch, der sonst nich durchkommen sollte. Und wenn der Parameter als letztes in eine Header-Zeile (E-Mail, HTTP, sonstwas) eingefügt wird, dann kann zumindest der Header vorzeitig terminiert werden, [...]

              ok, z.b. koennten u.u. dann bcc-adressen ploetzlich im body erscheinen. das ist wohl wahr.

              aber der titel "Sicherheitslücke in sehr vielen regulären Ausdrücken" ist wohl etwas zu schlagzeilig.

              prost
              seth

              1. gudn tach!

                aber der titel "Sicherheitslücke in sehr vielen regulären Ausdrücken" ist wohl etwas zu schlagzeilig.

                noe, isser nedd! ich hab bloss nicht weit genug gedacht.
                Stefan Esser hat mittlerweile ein paar beispiele gegeben.

                prost
                seth

      2. Hallo.

          
        $absender = preg_replace( "/[^a-z0-9 !?:;,.\/_\-=+@#$&\*\(\)]/im", "", $_POST['absenderemail'] );  
        
        

        Wieso wird $absender im Header später noch richtig ausgegeben, wenn doch das @-Symbol als Zeichen in der Funktion angegeben ist?

        MfG, Kungschu.

        1. gudn tach!

          $absender = preg_replace( "/[^a-z0-9 !?:;,./_-=+@#$&*()]/im", "", $_POST['absenderemail'] );

          
          > Wieso wird $absender im Header später noch richtig ausgegeben, wenn doch das @-Symbol als Zeichen in der Funktion angegeben ist?  
            
          ^ als erstes zeichen innerhalb einer zeichenklasse negiert die zeichenklasse.  
            
          /[^abc]/ heisst also "ein zeichen, dass weder 'a' noch 'b' noch 'c' ist".  
            
          abgesehen davon ist das "bereinigen", wie es [dr. web](http://www.drweb.de/webmaster/kontakt-formulare.shtml) vorschlaegt, nicht immer sinnvoll. beachte dazu den kommentar [#6.1 im genannten blog](http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html#c7186).  
            
          ich denke zwar - entgegen Stefan Esser -, dass bei e-mail-adressen z.b. in einem formular nichts dagegen spricht, einen etwaigen abschliessenden zeilenumbruch einfach zu entfernen, aber automatisch alle "meistens-verbotenen" zeichen zu entfernen (wie es dr. web vorschlaegt), ist imho eine zu naive vorgehensweise.  
            
          prost  
          seth
          
          1. Hallo.

            ^ als erstes zeichen innerhalb einer zeichenklasse negiert die zeichenklasse.

            /[^abc]/ heisst also "ein zeichen, dass weder 'a' noch 'b' noch 'c' ist".

            D.h. also, hier werden alle Zeichen und Sonderzeichen bis auf die in der Funktion genannten ersetzt.? Ok.

            abgesehen davon ist das "bereinigen", wie es dr. web vorschlaegt, nicht immer sinnvoll. beachte dazu den kommentar #6.1 im genannten blog.

            Man mus differenzieren, ok.

            ich denke zwar - entgegen Stefan Esser -, dass bei e-mail-adressen z.b. in einem formular nichts dagegen spricht, einen etwaigen abschliessenden zeilenumbruch einfach zu entfernen, aber automatisch alle "meistens-verbotenen" zeichen zu entfernen (wie es dr. web vorschlaegt), ist imho eine zu naive vorgehensweise.

            Aber nur ein strip_tags() genügt auch nicht, so wie ich das verstehe.

            MfG, Kungschu.