Sicherheitslücke in sehr vielen regulären Ausdrücken
Christian Seiler
- php
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
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
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
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.
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
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
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
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
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
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.
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
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.