nicht angemeldet
Sicherheitsrisiko mit GET, POST, etc.
Ave Forum!
Des öfteren habe ich gehört (bzw. gelesen), dass importierte Parameter mit GET oder POST ein Sicherheitsrisiko darstellen. Kann mir jemand sagen inwiefern? Wie kann jemand schaden anrichten? Kennt jemand Seiten, wo dieses Problem genau beschrieben ist?
Grazie mille!
Sox
-
Hallo Sox,
Des öfteren habe ich gehört (bzw. gelesen), dass importierte
Parameter mit GET oder POST ein Sicherheitsrisiko darstellen. Kann
mir jemand sagen inwiefern? Wie kann jemand schaden anrichten?
Kennt jemand Seiten, wo dieses Problem genau beschrieben ist?Ganz einfach: man kann so Variablen-Werte überschreiben. Beispiel:
<?php
if(logged_in()) {
$a = "value";
# tu nochwas
}if($a == "value") {
tu_was_sicherheitskritisches();
}?>
Jetzt rufe das Script mit script.php?a=value auf.
Grüße,
CK--
Es ist uns nicht möglich, in einem Bereich unseres Lebens richtig zu verhalten, wenn wir in allen anderen falsch handeln. Das Leben ist ein unteilbares Ganzes.-
Hey,
Des öfteren habe ich gehört (bzw. gelesen), dass importierte
Parameter mit GET oder POST ein Sicherheitsrisiko darstellen. KannGanz einfach: man kann so Variablen-Werte überschreiben. Beispiel:
Das Problem tritt nur in Verbindung mit alten PHP-Versionen auf, oder
wenn sich ein Provider an die veralteten Einstellungen klammert, um
seine Seite am Laufen zu halten (und die einiger besonders träger
Kunden). phpinfo() gibt Auskunft, ob das Problem wirklich auftritt -
die entsprechende Einstellung nennt sich "register_globals" (und sollte
heutzutage auf "off" stehen).Diese "injizierten Werte" lassen sich aber einfach ausschalten, indem
du einfach folgendes an den Anfang aller Skripte schreibst:<?php
$GLOBALS = array();Noch besser wäre es allerdings "php_option register_globals off" in
der .htaccess zu notieren.MsF,
milky-
Hallo milky,
<?php
$GLOBALS = array();Das geht bei mir nicht, siehe: http://www.christian-seiler.de/temp/globals.php?a=b. Wenn man allerdings
foreach (array_keys ($GLOBALS) as $var) {
unset ($GLOBALS[$var]);
}verwendet, geht es: http://www.christian-seiler.de/temp/globals.php?a=b&method=1
Aber Danke für den Denkansatz. :-)
Noch besser wäre es allerdings "php_option register_globals off" in
der .htaccess zu notieren.Das würde ich nicht vorschlagen, da man sich in Scripten nicht darauf verlassen kann. Denn diese .htaccess-Option funktioniert nicht bei jedem Hoster (je nachdem, ob AllowOverride Options gesetzt ist) und man weiß ja vorher nicht, wo seine Scripte eingesetzt werden. Man kann sich in PHP-Scripten auf nichts von außen verlassen, deswegen sollte man z.B. <?php statt <? nehmen, magic_quotes_gpc-Deaktivier-Code einbauen und register_globals beachten, damit man wirklich sicher ist.
Viele Grüße,
Christian-
Hey Christian,
Das geht bei mir nicht, siehe: http://www.christian-seiler.de/temp/globals.php?a=b. Wenn man allerdings
Dann hab ich wohl einfach Glück, denn bei meinen PHP-Versionen funktioniert
auch die Billig-Lösung ganz prima.Das würde ich nicht vorschlagen, da man sich in Scripten nicht darauf verlassen kann. Denn diese .htaccess-Option funktioniert nicht bei jedem Hoster (je nachdem, ob AllowOverride Options gesetzt ist) und man weiß ja vorher nicht, wo seine Scripte eingesetzt werden. Man kann sich in PHP-Scripten auf nichts von außen verlassen, deswegen sollte man z.B. <?php statt <? nehmen, magic_quotes_gpc-Deaktivier-Code einbauen und register_globals beachten, damit man wirklich sicher ist.
Also wenn man Apache verwendet ist es schon relativ zuverlässig, weil der
sofort einen Fehler meldet, wenn "php_option" in .htaccess auftaucht, aber
die Providernussis das verboten hatten (ebenso wenn PHP via CGI
eingebunden wird). An der Stelle ist es also mal ganz nützlich, daß sich
Apache immer gleich beschwert und abbricht.Und die Variante .htaccess "php_option" ist IMHO schneller, als all die
grußeligen Workarounds, die in ansonsten in PHP-Skripte reingebastelt
werden. Und besonders bei "magic_quotes_gpc" sollte man unbedingt versuchen es via
.htaccess zu korrigieren, weil das Hin- und Herkonvertieren nicht nur lahm
sondern auch unsauber ist.MsF,
milky-
Hallo milky,
Dann hab ich wohl einfach Glück, denn bei meinen PHP-Versionen funktioniert
auch die Billig-Lösung ganz prima.Darf ich erfahren, welche PHP-Version Du hast?
Also wenn man Apache verwendet [...]
Und wer garantiert, dass die Scripte immer mit einem Apachen ausgeführt werden?
Und die Variante .htaccess "php_option" ist IMHO schneller, als all die
grußeligen Workarounds, die in ansonsten in PHP-Skripte reingebastelt
werden. Und besonders bei "magic_quotes_gpc" sollte man unbedingt versuchen es via
.htaccess zu korrigieren, weil das Hin- und Herkonvertieren nicht nur lahm
sondern auch unsauber ist.Sicherlich. Ich habe ja auch nichts dagegen, dass das *zusätzlich* passiert. Aber letztendlich sind die Scripte selbst dafür verantwortlich, wenn es um solche Dinge geht. Daher: Wenn möglich, mit .htaccess deaktivieren, aber immer in den Scripten Auffang-Code zu haben, falls das eben nicht funktioniert (man kann ja mit ini_get & Co abfragen, ob bestimmte Optionen gesetzt sind).
Viele Grüße,
Christian-
Hey Christian,
Darf ich erfahren, welche PHP-Version Du hast?
4.3.4-cgi und 5beta*-cgi (also kein Apache und kein libphp; auf meiner
home box)Und wer garantiert, dass die Scripte immer mit einem Apachen ausgeführt werden?
Aber glücklicherweise benutzen ja die meisten Anbieter Apache.
Sicherlich. Ich habe ja auch nichts dagegen, dass das *zusätzlich* passiert. Aber letztendlich sind die Scripte selbst dafür verantwortlich, wenn es um solche Dinge geht. Daher: Wenn möglich, mit .htaccess deaktivieren, aber immer in den Scripten Auffang-Code zu haben, falls das eben nicht funktioniert (man kann ja mit ini_get & Co abfragen, ob bestimmte Optionen gesetzt sind).
Sicherheitshalber baue ich in meine Scripte auch immer Korrekturcode ein,
aber tatsächlich nur für die Leute, die kein Apache/libphp oder die
.htaccess-Methode verwenden können.
Wenn ich mir aber sicher bin, daß es in einer meiner Installationen nicht
nötig ist, dann wird der Code wieder entfernt, weil "php_option" nunmal
verlässlicher ist.milky
-
-
-
-
Moin
Des öfteren habe ich gehört (bzw. gelesen), dass importierte
Parameter mit GET oder POST ein Sicherheitsrisiko darstellen. KannGanz einfach: man kann so Variablen-Werte überschreiben. Beispiel:
Das Problem tritt nur in Verbindung mit alten PHP-Versionen auf, oder
wenn sich ein Provider an die veralteten Einstellungen klammert, um
seine Seite am Laufen zu halten (und die einiger besonders träger
Kunden). phpinfo() gibt Auskunft, ob das Problem wirklich auftritt -Mom.. Du erzählst hier Unfug-
RegisterGlobals =off zu verwenden und sich drauf verlassen, dass alles Dicht ist ist genauso unsicher.
Es ist nämlich völlig egal ob ich einen Falschen wert mittels $_Get['var'] ins Skript bringe oder einfach nur mit $var Ihn falsch abfrage. Wichtig ist zu verifizieren 1. Wo die Werte herkommen, und 2. zu prüfen ob Diese gültig sind.
"Schlechter Stil" führt zu Unsicherheiten egal ob der Provider RegisterGlobals on oder off hat.
RegisterGlobals off erschwert die Fehler nur mehr nicht.Außerdem ist Register Globals kein Problem "alter" PHP Versionen sondern der Einstellungen.
Und mir ist keine Massenhoster bekannt er RgisterGlobals =off hat.TomIRL
-
Hallo zusammen,
Danke für alle Antworten!Wichtig ist zu verifizieren 1. Wo die Werte herkommen,
Wie mach ich das?
und 2. zu prüfen ob Diese gültig sind.
Wie meinst du das? Ob der Typ der Variable richtig ist?
Danke
Sox-
Hey Sox,
Wichtig ist zu verifizieren 1. Wo die Werte herkommen,
Wie mach ich das?Normalerweise holst du dir Formular-Daten über $_REQUEST["wert"].
Aber wenn du sicher bist, einen Wert als Cookie abgespeichert
zu haben, ist es besser auch nur $_COOKIES[] abzufragen.
Ebenso gibt es auch $_GET[] und $_POST[]. In der Praxis macht es
jedoch kaum Sinn sich darum zu kümmern, weil der Anwender (mit
präparierten Clients) ohnehin alle drei beliebig mit Daten
spicken kann.Wie meinst du das? Ob der Typ der Variable richtig ist?
Du solltest die Werte nicht direkt weiterverarbeiten, sondern die
eingenden Daten erst filtern. Ich hatte früher mal eine kleine
Fkt. eben dafür verwendet:function expect($name, $regex='/^\w+$/') {
if (preg_match($regex, $_REQUEST[$name], $uu)) {
return($uu[0]);
}
}Und wenn du nun einen Parameter einlesen willst, der auf jeden Fall
eine Zahl enthalten muß, dann nimmst du:$zahl = expect("zahl", "/^\d+$/");
Und nur wenn dir absolut egal ist, was in einer Variablen steht,
solltest du den $_REQUEST["wasauchimmer"]-Wert direkt verwenden.MsF,
milky
-
-
Hey,
Mom.. Du erzählst hier Unfug-
RegisterGlobals =off zu verwenden und sich drauf verlassen, dass alles Dicht ist ist genauso unsicher.Ja, aber es ging doch hier erstmal nur um das Problem mit der manipulierten
Programmablauflogik, was in dem Beispiel von Christian Kruse auch nochmal
ziemlich gut verdeutlicht wurde.register_globals=off ist natürlich sicherheitstechnisch genauso irrelevant
wie magic_quotes_gpc=on, wenn jemand wirklich null Ahnung davon hat, wie
eingehende Daten in einem Skript behandelt werden sollten.Außerdem ist Register Globals kein Problem "alter" PHP Versionen sondern der Einstellungen.
Und mir ist keine Massenhoster bekannt er RgisterGlobals =off hat.Ja, das trifft den Nagel auf den Kopf!
Es ist wirklich kein Problem der alten PHP-Versionen, sondern eher der
veralteten PHP-Einstellungen - An dieser Stelle nochmal tausend Dank
an Projekte wie PhpNuke und phpBB.Grüße,
milky
-
-
Hallo milky,
[...]
die entsprechende Einstellung nennt sich "register_globals" (und
sollte heutzutage auf "off" stehen).Darum ging es dem OP doch.
Grüße,
CK--
Willst du die Freuden dieser Welt geniessen, so musst du auch ihr Leid erdulden.
-
-