Filterung hexadezimaler Zeichen

[cortex]

Wie geht Ihr eigentlich mit der Filterung böser User-Daten um, insbesondere hexadezimaler Zeichen ?

Prüfe ich bspw. eine GET-variable auf "dates" wird ebenso "%64%61%74%65%73" akzeptiert. Das macht die Anwendung prinzipiell für Manipulationen anfällig.

Sollte man mit einer White- / Blacklist arbeiten ? Kann der Server so konfiguriert werden, dass hex-Werte nicht akzeptiert werden ?

Bin gespannt auf Eure Meinung,
cx

[smartweb]

Wo siehst Du da Hex-Werte?

Wenn Du %64 meinst, naja da kannst Du doch einfach hergehen und checken ob der User ein valides Datum eingegeben hat:

PHP-Code:


if (!preg_match("/[0-9]{2}-[0-9]{2}-[0-9]{4}/",$_GET['datum'])) { //dd-mm-yyyy
 $error++;
 exit();
} 

//oder davor:
foreach($_GET as $k => $v) {
 ${$k} = preg_replace("/%/","",$v);
}

//oder das Datum einfach mit checkdate() prüfen 


[cortex]

du hast mich leider falsch verstanden; ich meine folgendes:

http://domain.de/index.php?var=dates

wird genau so akzeptiert wie:

http://domain.de/index.php?var=%64%61%74%65%73

cx

[Indyk]

wenn ich es richtig verstehe, werden doch nur die Hexa akzeptiert die einem von dir gesetzten Parameter entsprechen, oder nicht?

Wo ist also der unterschied ob der Parameter alphanumerisch , Hexa oder binär übergeben wird?

Ist dir eine Sicherheitslücke für Hexa werte bekannt? Wenn ja wärst du so freundlich diese mit anderen Server Besitzern zu teilen?

[cortex]

Zitat von Indyk

wenn ich es richtig verstehe, werden doch nur die Hexa akzeptiert die einem von dir gesetzten Parameter entsprechen

das stimmt soweit für das gezeigte beispiel - solange ich mit einer art whitelist arbeite, sehe ich auch kein problem: die kodierung der übergebenen zeichen ist egal.

kenne ich allerdings den inhalt der user-daten nicht (z.b. beliebige texteingabe) sehe ich das risiko, dass hex-kodierte zeichen wie < oder > in die anwendung gelangen.

cx

ps. kann sein, dass ich den wald vor lauter bäumen nicht sehe...

cx

[cortex]

nun, es hat sich ja kaum jemand an der diskussion beteiligt... schade. bin bei der frage inzwischen durchgestiegen - falls irgend jemand interesse bekunden sollte, schreib ich nochmal ein paar zeilen dazu.

cx

[smartweb]

Wie gesagt, das einfachste ist wohl alle % zu ersetzen...

[cortex]

Zitat von smartweb

Wie gesagt, das einfachste ist wohl alle % zu ersetzen...

1. es wurde noch gar nichts gesagt...

2. ich spreche über ein generelles problem - nämlich die unterschiedlichen möglichkeiten zur kodierung von zeichen. das ganze ist ein wenig komplexer.

3. das prozent-zeichen hat selbst im täglichen sprachgebrauch eine wichtige bedeutung - einfach ersetzen is nich.

cx

[Indyk]

Zitat von cortex

nun, es hat sich ja kaum jemand an der diskussion beteiligt... schade. bin bei der frage inzwischen durchgestiegen - falls irgend jemand interesse bekunden sollte, schreib ich nochmal ein paar zeilen dazu.

cx

Hiermit krame ich diesen etwas älteren Thread raus und bekunde Interesse.

[DokuLeseHemmung]

Dann will ich mal meine bescheidene Meinung einstreuen.....

Einen generischen Parametertest einzubauen halte ich nur für beschränkt sinnvoll.
Weiter als http://www.hardened-php.net/suhosin/a_feature_list.html DARF man nicht gehen.

Ob % im GET oder gar JS in Textareas, erst die Anwendung selber kann entscheiden, ob das an der Stelle erlaubt ist. Von daher MUSS jeder Parameter einzeln, vor der Verwendung, geprüft werden.

Eine recht brauchbare Basis ist: http://de.php.net/manual/de/book.filter.php

Dem laxen Umgang mit Typen, Codierungen usw. im PHP kann man nur mit Disziplin beikommen.