CMS - Der Dirigent » Community » DeDi-Talk

Neue Umfrage | neues Thema | Antworten

Entwicklung, Evtl. neues Board anlegen :-)?

« Älteres Thema | Neueres Thema » Thema abonnieren | Thema versenden | Thema drucken

stoph
Geschrieben am: 29. Mar 2003 - 07:11


Unregistered








 		Hi, ppl,

ich habe vor (evtl.) eine bestimmte Erweiterung für den Dirigenten
zu programmieren. Welche das ist, werde ich noch extra erläutern :-).
Könnt Ihr noch ein Entwicklung-Forum aufmachen?

Bis dahin schreibe ich meine Frage den client betreffend hier. :-)
Ich versuche mich in den DEDI-Quellcode einzuarbeiten und habe
gleich in der ersten Datei eine Verständnisfrage. Wenn sie zu banal,
oder gar ketzerisch erscheint, dann habt bitte Rücksicht.

Folgender Code (index.php - Zeilen 21-28):

CODE

// alle GET, POST und COOKIE wegen Globals_off parsen
$types_to_register = array('GET','COOKIE','POST','SERVER','FILES','ENV','SESSION','REQUEST');

foreach ($types_to_register as $global_type) {
$arr = @${'HTTP_'.$global_type.'_VARS'};

if (@count($arr) > 0) extract($arr, EXTR_OVERWRITE);
else {
 $arr = @${'_'.$global_type};
 if (@count($arr) > 0) extract($arr, EXTR_OVERWRITE);
}
}


Hier werden alle Variable aus den Arrays ($_GET, $_COOKIE, usw.) nochmals in
Arrays $HTTP_GET_VARS, $HTTP_COOKIE_VARS, usw. gespeichert. Warum?

Die Original-Variablen stehen sein php 4.1.0 allen zur Verfügung, auch wenn
register_globals eingeschalten ist. Die Variable ($HTTP_*_VARS) werden ja
für verschiedene Funktionen im Backend-Verzeichnis (Sessions, usw.) benutzt.

cu, stop.h
Top
pschuster
Geschrieben am: 29. Mar 2003 - 07:32


Unregistered








 		Hi stoph,

häh??

Mit diesem Code werden lediglich sämtliche Umgebungsvariablen zunächst in $arr geladen und dann in die Keyvariablen extracted. Soll heissen aus z.B. $HTTP_GET_VARS["test"] wird $test.
Sollten die Variablen $HTTP_x_VARS nicht zur Verfügung stehen (vielleicht ab PHP 5.0?) wird das selbe nochmal mit $_x probiert.

Einen schönen Tag noch
Patrick
Top
stoph
  Geschrieben am: 29. Mar 2003 - 08:20


Unregistered








 		OK, jetzt habe ich den Quelltext kapiert.
Extract hatte ich wohl nur anfangs wahrgenommen
und dann später durch das Arraygeparse in meinem
Schädel ersetzt smile.gif

Ein glanzvoller Einstieg in diesem Forum. rolleyes.gif

Wobei sich aber meine nächste Frage aufdrängt warum
die Variable wieder zurückgewandelt werden.

Die $_GLOBALS, $_POST, ... Sachen wurden doch aus
Sicherheitsgründen in Produktionsumgebungen
eingeführt. Siehe: PHP-Website
Damit werden doch die Vorteile, die sich daraus ergeben
wieder rückgängig gemacht, weil die Kapselung wieder
aufgehoben wird.

Evtl. sollte dann die alten Variable von HTTP_*_VARS
lieber in $_*.Arrays geschrieben und darauf hingewiesen
werden, dass der Einsatz von "register_globals=off" unsicher
ist.

Auch das ist eine Verständisfrage. Wenn mir jetzt jemand erzählt,
dass das Risiko gar nicht so gross ist, oder es eigentlich gar nichts
macht, wenn Variable theoretisch überschrieben werden können,
oder dieser Fall durch den obigen Code auch ausgeschlossen wird,
dann lasse ich mich gern belehren.

cu, stop.h wink.gif
Top
Sven777b
Geschrieben am: 29. Mar 2003 - 09:38


Unregistered








 		die Variablen $HTTP_*_VARS werden an keiner Stelle zurückgeschrieben oder modifiziert. Es wird lediglich der Schritt simuliert, der bei register_globals=on auch bloss durchgeführt wird. Ich verstehe auch die Frage nicht so ganz , denn offiziell wird register_globals=on als gefährlich eingestuft und deshalb bei der installation von PHP defaultmäßig auf "off" gestellt. Die meisten Server mit der ganz neuen PHP-Version stehen auf register_globals=off.

"wer lesen kann ist klar im Vorteil" biggrin.gif

die von dir gepostete Referenz enthält als allerersten Satz:
Ein Feature von PHP zur Erhöhung der Sicherheit ist die Konfiguration von PHP mit register_globals = off.

Grüße - Sven
Top
stoph
  Geschrieben am: 29. Mar 2003 - 12:10


Unregistered








 		OK. Dann muss ich mich wohl noch anders ausdrücken. :-)

Hey, ich kann lesen und ... naja, alles, was ich jetzt noch
schreiben würde könnte als Angriff ausgelegt werden. biggrin.gif

Ein kleiner SecurityAudit:

"register_globals" (ab sofort RG genannt) hat den Vorteil, dass
alle externen Variablen in einem Array landen und dort gekapselt sind.

Angenommen, ich über gebe per GET eine Variable "dedi_path",
dann ist diese, wenn RG an ist, sofort im Script aktiv.
Wird in diesem Fall im Quelltext durch include("config.php"); zwar
wieder überschrieben, aber die Variable war da.

Wenn RP aus ist (was richtig und sicher ist), landet sie im
Array $_GET (oder $_REQUEST).

Jetzt kommt das, was mich so stutzig macht. Der aktuelle
Quellcode geht her und nimmt alle SICHEREN und ABGESCHIRMTEN
Variablen aus den Array wieder heraus und macht richtige
Variable daraus. Folgender CODE:
CODE
extract($arr, EXTR_OVERWRITE);

nimmt meine unsichere Variable im $_GET-Array und
überschreibt (EXTR_OVERWRITE) die existierende Variable
$dedi_path, die in der "config.php" zugewiesen wurde.

Ein Beispiel wäre es jetzt, diese Variable durch eine externe
Website zu ersetzen.

CODE
http://www.my.de/index.php?dedi_path=http://...

(geht jetzt so nicht, aber es soll hier nur das Prinzip verdeutlicht werden)

Der Schutz, den man durch register_globals erhalten hat
wurde hier eindeutig ausgehebelt und sogar "verschlimmbessert".

Zudem sollten die Variablen $idcat und $idcatside noch darauf
geprüft werden, ob sie wirklich integer-variablen sind.

Angenommen ein Angreiffer ersetzt die int-Werte durch
einen Text string, diese Variablen werden später ungeprüft in
eine SQL-Abfrage eingebunden:

CODE

SELECT idcatside FROM $dedi_db[cat_side] WHERE idcat='$idcat' AND is_start='1' LIMIT 0,1


Ein Angreiffer würde den Inhalt von $idcat anders festlegen.
Z.B.
CODE

1'  OR > '1' AND (DELETE FROM *) AND idcat='1


dann würde die SQL-Abfrage (sofern sie funktioniert; was hier nicht der
Fall ist) folgend lauten:

CODE

SELECT idcatside FROM $dedi_db[cat_side] WHERE idcat='1'  OR > '1' AND (DELETE FROM *) AND idcat='1' AND is_start='1' LIMIT 0,1


Ich hoffe meine Beweggründe sind deutlich geworden. cool.gif

cu, #chri "stop.h"
Top
Eppi
Geschrieben am: 29. Mar 2003 - 12:24


.....................noname


Gruppe: Admin
Beiträge: 8077
Mitgliedsnummer: 1
Mitglied seit: 23. Mar 2003


 		werd ich gleich umsetzen :-) Das mit den globals werd ich vielleicht auch noch andersrum angehen.

Merci

--------------------

"Heute ist nicht aller Tage... ich komm wieder, keine Frage!"
Top   
stoph
Geschrieben am: 29. Mar 2003 - 13:01


Unregistered








 		smile.gif

Für die erste Lücke reicht es ja, die config-Datei nach dem
"AntiRegisterGlobals"-Code einzubinden.

Es wird aber auf allen wichtigen php-Seiten geraten,
globale-Variable im eigenen Array zulassen und damit
zu arbeiten.

Evtl. könnte man ja eine Prüfklasse für externe Daten
schreiben. In Java wäre das die "assert"-Funktion.

Edit:

php hat schon so eine Funktion (wusste ich gar nicht)
http://www.php.net/manual/de/function.assert.php

Noch besser soll die php-Adaption von JUnit sein:
http://pear.php.net/package-info.php?pacid=38

cu, stop.h

Bearbeitet von stoph am 29. Mar 2003 - 13:09
Top
Eppi
Geschrieben am: 29. Mar 2003 - 16:48


.....................noname


Gruppe: Admin
Beiträge: 8077
Mitgliedsnummer: 1
Mitglied seit: 23. Mar 2003


 		Achso, Entwicklerforum werden wir die Tage einrichten.

--------------------

"Heute ist nicht aller Tage... ich komm wieder, keine Frage!"
Top   

Thema wird von 0 Benutzer gelesen (0 Gäste und 0 Anonyme Benutzer)
0 Mitglieder:

7 Antworten seit 29. Mar 2003 - 07:11

Thema abonnieren | Thema versenden | Thema drucken

<< Zurück zu DeDi-Talk

Neue Umfrage | neues Thema

Home | Das Projekt | Download | Entwicklung | Dokumentation | Forum | Impressum