Moin,
Von: Dieter Kroemer [mailto:kroe@rs-schesslitz.de]
Welche Sicherheitsrisiken bekomme ich denn damit?
Ganz einfach: normalerweise wird damit jede in einem Formular übergebene Variable auch PHP bekannt gemacht. Dabei werden also quasi "automagisch" neue Variablen angelegt - oder eben genau so "automagisch" mit neuem Inhalt überschrieben. Kenne ich als "böser Bub" nun wichtige Variablen innerhalb des Scriptes, kann ich hingehen, und mir ein eigenes Formular (nicht unbedingt PHP generiert, nur mit der gleichen ACTION) erstellen, daß gezielt diese nicht mehr formularinternen sondern rein scriptinternen Variablen ändert. Gibt's da dann z.B. eine Variable "$uploadpfad", kann ich diese von einem entsprechend "vergifteten" Formular ebenfalls ändern - mit den dadurch wohl recht klar ersichtlichen Folgen, insbesondere wenn bei der Prüfung der Identität eines Benutzers etwas sorglos umgegangen wird (also genau bei "einfachen" Skripten), bzw. wenn ich auf einem OS arbeite, daß es mit User-/Gruppen-Berechtigungen nicht gerade genau nimmt... Mit "registerglobals = off" kann ich zwar über $scriptvariable = HTTP_GET_VARS['formularvariable']; (bzw. dasselbe mit HTTP_PUT_VARS) nur etwas "umständlicher" an den Inhalt der Variablen in meinem Formular kommen, dafür kann ich aber sicher sein, daß wirklich nur diejenigen Variablen einen Wert zugewiesen bekommen, denen ich auch aus dem Formular etwas übergeben lassen wollte. Ein Freibrief für "sichere" Scripte ist das dabei allerdings nicht - es verhindert lediglich das Überschreiben von scriptinternen Variablen, nicht aber Probleme wie sie z.B. durch gezielt manipulierte Daten auftreten können (Session hijacking, absolute Pfad/Dateinamen etc.).
Viele Grüße Dieter
Bis denn Gerard
Hallo Gerard Am Donnerstag, 26. Juni 2003 15:10 schrieb Jensen, Gerard:
Moin,
Von: Dieter Kroemer [mailto:kroe@rs-schesslitz.de]
Welche Sicherheitsrisiken bekomme ich denn damit?
Ganz einfach: normalerweise wird damit jede in einem Formular übergebene Variable auch PHP bekannt gemacht. Dabei werden also quasi "automagisch" neue Variablen angelegt - oder eben genau so "automagisch" mit neuem Inhalt überschrieben.
Kenne ich als "böser Bub" nun wichtige Variablen innerhalb des Scriptes, kann ich hingehen, und mir ein eigenes Formular (nicht unbedingt PHP generiert, nur mit der gleichen ACTION) erstellen, daß gezielt diese nicht mehr formularinternen sondern rein scriptinternen Variablen ändert. Gibt's da dann z.B. eine Variable "$uploadpfad", kann ich diese von einem entsprechend "vergifteten" Formular ebenfalls ändern - mit den dadurch wohl recht klar ersichtlichen Folgen, insbesondere wenn bei der Prüfung der Identität eines Benutzers etwas sorglos umgegangen wird (also genau bei "einfachen" Skripten), bzw. wenn ich auf einem OS arbeite, daß es mit User-/Gruppen-Berechtigungen nicht gerade genau nimmt... ACK
Mit "registerglobals = off" kann ich zwar über
$scriptvariable = HTTP_GET_VARS['formularvariable']; Hier sollte man, wenn man schon mit dem Problem konfrontiert neu beginnen muss, lieber gleich auf $_GET, $_POST, $_COOKIE etc. zugreifen, weil HTTP_GET_VARS etc pp. IMHO schon sehr bald nicht mehr unterstützt werden. Dann hat man das Problem wieder von Neuem. Die neuen Arrays gibt es parrallel schon seit 4.1, sollten also überall verfügbar sein.
Ein Freibrief für "sichere" Scripte ist das dabei allerdings nicht - es verhindert lediglich das Überschreiben von scriptinternen Variablen, nicht aber Probleme wie sie z.B. durch gezielt manipulierte Daten auftreten können (Session hijacking, absolute Pfad/Dateinamen etc.). FULLACK. Ein sehr wichtiger Hinweis.
CU Thorsten -- Thorsten Körner http://www.123tkShop.org
Hallo Thorsten, hallo Leute, Am Donnerstag, 26. Juni 2003 15:21 schrieb Thorsten Körner:
Am Donnerstag, 26. Juni 2003 15:10 schrieb Jensen, Gerard: [...]
Mit "registerglobals = off" kann ich zwar über
$scriptvariable = HTTP_GET_VARS['formularvariable'];
Hier sollte man, wenn man schon mit dem Problem konfrontiert neu beginnen muss, lieber gleich auf $_GET, $_POST, $_COOKIE etc. zugreifen, weil HTTP_GET_VARS etc pp. IMHO schon sehr bald nicht mehr unterstützt werden. Dann hat man das Problem wieder von Neuem. Die neuen Arrays gibt es parrallel schon seit 4.1, sollten also überall verfügbar sein.
Und wie lange funktioniert $_GET usw? ;-) Ich hab für das Webinterface der Fontlinge eine kleine Funktion gebastelt, die das ganze kapselt und sogar ein Fallback auf globale Variablen enthält - somit läuft das Fontlinge WebGUI auch mit PHP 4.0, falls jemand noch sowas hat ;-) Dieser Fallback dürfte nichtmal ein Sicherheitsproblem für neuere PHP-Versionen sein, da dort $_GET AFAIK immer definiert ist. <?php function safeget ($param) { # import URL params from $_GET # If the wanted param was not given, there will be no error message # (E_NOTICE level). In this case, this function will return an empty # string. $retval=""; # import from $_GET if (isset($_GET["$param"])) $retval=$_GET["$param"]; # compatibility code for PHP 4.0 (and older) global $$param; if ( ! isset($_GET) && isset($$param)) $retval=$$param; return $retval; } # end safeget() ?> Die Funktion wird ähnlich verwendet wie $_GET. Statt $myvar = $_GET['irgendwas'] schreibt man eben $myvar = safeget('irgendwas')
Ein Freibrief für "sichere" Scripte ist das dabei allerdings nicht - es verhindert lediglich das Überschreiben von scriptinternen Variablen, nicht aber Probleme wie sie z.B. durch gezielt manipulierte Daten auftreten können (Session hijacking, absolute Pfad/Dateinamen etc.).
FULLACK. Ein sehr wichtiger Hinweis.
Gleich noch ein recht nützlicher Tip: in der php.ini [1] error_reporting = E_ALL statt error_reporting = E_ALL & ~E_NOTICE eintragen, dann werden z. B. uninitialisierte Variablen und Array-Elemente gemeldet. Das hat gleich mehrere Vorteile: - Vertipper in Variablennamen fallen sofort auf - mögliche Sicherheitslücken durch nicht initialisierte globale Variablen fallen ebenfalls auf - die könnten eine Angriffsfläche für Angreifer sein, was ja in diesem Thread schon oft genug diskutiert wurde. - ehemals durch register_globals importierte Variablen fallen sofort auf, man spart sich das Suchen ;-) Oder kurz gesagt: error_reporting = E_ALL - das "use warnings" für PHP ;-) Übrigens: meine safeget-Funktion verursacht _absichtlich_ _keine Warnung_, falls ein Parameter nicht an die URL angehängt wurde, sondern liefert in diesem Fall einen Leerstring zurück. Wer unbedingt einen Hinweis sehen will, sollte das if (isset($_GET["$param"])) streichen ;-) Gruß Christian Boltz [1] oder in der httpd.conf (gern auch für einen <VirtualHost> oder (ungetestet) für ein <Directory>) php_value error_reporting "E_ALL" php_value register_globals Off -- Aus der Beschreibung entnehme ich, daß deine Fonts nach Typ 3 konvertiert werden (Finger im Hals) und deine Bilder auf Screen- Qualität (Fuß zum Finger dazusteck...) [Ratti in suse-linux]
Hallo, On Fri, 27 Jun 2003, Christian Boltz schrieb:
Ich hab für das Webinterface der Fontlinge eine kleine Funktion gebastelt, die das ganze kapselt und sogar ein Fallback auf globale Variablen enthält - somit läuft das Fontlinge WebGUI auch mit PHP 4.0, falls jemand noch sowas hat ;-)
Whut??!? php 4.x? $ rpm -q --queryformat "%{name}-%{version} %{buildtime:date}\n" mod_php mod_php-3.0.11 Fri 23 Jul 1999 03:25:43 PM CEST -dn'*SCNR*'h -- 134: Benutzerfreundlichkeit Der Benutzer hat zum Admin freundlich zu sein. (Thorsten Fenk)
Am Sam, 2003-06-28 um 01.02 schrieb David Haller:
Whut??!? php 4.x?
$ rpm -q --queryformat "%{name}-%{version} %{buildtime:date}\n" mod_php mod_php-3.0.11 Fri 23 Jul 1999 03:25:43 PM CEST
-dn'*SCNR*'h
Jaja.
grep "root" /etc/aliases kaiser_willem:root
SCANR, Ratti :-) -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
participants (5)
-
Christian Boltz -
David Haller -
Jensen, Gerard -
Joerg Rossdeutscher -
Thorsten Körner