[PHP] Sicherheit von Parametern aus superglobalen Arrays durch Validierung

[2nd]

Moin,

mich würde mal interessieren, wie Ihr folgenden sicherheitsrelevanten Sachverhalt seht:

Ich übergebe numerische Werte auf einer Website via GET-Parameter, also z. b. 0 - x. Nun stehen mir ja verschiedene Mittel und Wege der Validierung dieses Parameters zur Verfügung, bevor ich damit weiterarbeite, z. B. für eine Datenbankabfrage.

Auf dem Server sind die magic_quotes_gpc AUS.

Der naheliegendste Weg ist sicher der folgende: Ich filtere alles, was nach Sonderzeichen (", ' usw.) und Tags aussieht raus, da ich nichts von dem Zeug in dem Parameter drin haben will:

if (isset($_GET['parameter'])) $parameter = mysql_real_escape_string(strip_tags($parameter));

oder durch

if (isset($_GET['parameter'])) $parameter = htmlentities(strip_tags($parameter), ENT_QUOTES);

Damit wird alles ungültig, was nach XSS oder XQL-Injection aussieht.

Nun wollte ich mal wissen, wie das sich mit "casten" verhält, sprich ich mach eine Typenumwandlung wie folgt:

if (isset($_GET['parameter'])) $parameter = (int)$_GET['parameter'];

Damit bekomme ich bei Nicht-Integerwerten eine 0 als Ergebnis. Sieht also auch soweit gut aus. Rutscht mir damit was durch die Validierung?

Danke,

2nd

 

[koli.bri]

Genau den selben Ansatz hab ich zur Zeit auch.

Rein Logisch gesehen dürfte damit ja alles rausgenommen werden.
Entweder man bekommt ein Interger, oder ne Null, was ja auch ein Integer ist., mehr Fälle gibt ja nicht.

Einziges Problem ist dann noch, wenn es zu der Übergebenen Nummer keinen Datensatz gibt, und/oder was tun bei Null.
Aber das ist ja wieder eine andere Geschichte.

Ich schließe mich der FRage deshalb an

gruß
Lukasq

 

[2nd]

Einziges Problem ist dann noch, wenn es zu der Übergebenen Nummer keinen Datensatz gibt, und/oder was tun bei Null.

Als Problem würde ich das nicht sehen. Mit einem einfachen Count kann man ja prüfen, ob es Ergebnisse >0 gibt, wenn nicht wird halt reagiert

2nd

 

[wegus]

ich unterscheide immer gern zwischen 0,'' oder NULL!

Daher setze ich für sowas, angesichts der Typenfreiheit von PHP, manchmal eigene Flags, definiere mir Typenobjekte...

Vor allem, wenn ich wissen will ob jemand mir Datenunterschiebt, dann wandele ich nicht nur, ich mache asserts ( Bereichsprüfungen auf Plausibilität - etwa negative Preise) und schicke schonmal MD5-Checksummen über Teile der Formularvariablen mit um Manipulationen abfangen zu können.

 

[moses_78]

Ich weiss, dass meine Antwort jetzt zynisch klingen
könnte, und überhaupt nicht konstruktiv zur Lösung
des Problems beiträgt, ABER:

Seitdem ich nicht mehr in PHP frickele, habe ich end-
lich gemerkt, wie schlecht PHP eigentlich ist, schon
alleine wegen diesem Wirrwarr mit den Typen und der
Validierung von Input-Daten.

 

[wegus]

Seitdem ich nicht mehr in PHP frickele, habe ich end-
lich gemerkt, wie schlecht PHP eigentlich ist, schon
alleine wegen diesem Wirrwarr mit den Typen und der
Validierung von Input-Daten.

Da hast Du völlig recht, für manche Dinge ist aber PHP dennoch die bessere Wahl und wenn man sich Mühe gibt kann man da auch sauber implementieren!

Aber auch mir sind Typgebundene Sprachen mit Namespaces weitaus lieber geworden!

 

[2nd]

Danke für die Antworten.

Ich habe noch ein bisschen mit der Cast-Funktion rumgespielt und konnte nichts finden, was nach Lücke aussieht. Alles, was z .B. bei (int) nicht Integer ist, wird weggeschmissen und den Rest kriegt man mit einer Bereichsprüfung/Whitelist hin.

2nd