Nein, das Script läuft auch auf einem Server mit Globals=On.

Die vorgenommenen Änderungen garantieren lediglich, dass die benötigten Türen offen sind. Wenn der Server alle anderen Türen auch geöffnet hat (Globals=on), tut das nichts zur Sache.

Oder um es anders gesagt: Dieses Script arbeitet in einem höheren Sicherheitslevel (Globals=off) und ist deshalb auch in der Lage in unsichereren Leveln (Globals=on) zu arbeiten. Das umgekehrte ist nicht möglich.

mfg Gimli

EDIT: Ich weiss nicht ob ich deine Frage richtig verstanden habe. Willst du das Script auf einem Globals=on-Server sicherer machen, dh Türen und Fenster schliessen? Das ist nicht möglich. (Oder nicht dass ich wüsste) das ist aber nicht weiter schlimm, denn soweit ich das verstanden habe, handelt es sich nur um eine theoretische Sicherheitslücke. Mir ist kein Fall bekannt, in welchem die Globals=On Einstellung gravierend ausgenutzt wurde.

EDIT2: Das mit den Globals kannst du dir wie folgt vorstellen: Wenn sie aktiviert sind, nimmt der Server Änderungen am Script vor bevor er es ausführt. Darauf hast du keinen Einfluss. (Ob das jetzt technisch genau so abläuft weiss ich nicht, aber für die Vorstellung ist es passend)

Zitat

Original von jperl

Zitat

Original von maxtpayne
@seven

	PHP-Quelltext
1 2 3 4 5	$tab_user=$_REQUEST["tab_user"]; $user_name=$_REQUEST["user_name"]; $user_pw=$_REQUEST["user_pw"]; $tab_navbox$_REQUEST["tab_navbox"]; $tab_boxname$_REQUEST["tab_navname"];

ergänze das mal ganz am Anfang. Dann sollte das funktionieren.

Greetz

MaxTPayne

zwei = vergessen

	PHP-Quelltext
1 2 3 4 5	$tab_user=$_REQUEST["tab_user"]; $user_name=$_REQUEST["user_name"]; $user_pw=$_REQUEST["user_pw"]; $tab_navbox=$_REQUEST["tab_navbox"]; $tab_boxname=$_REQUEST["tab_navname"];

jperl

args nachwehen vom vortag


@seven

ich bin mir nicht ganz sicher aber wenn du explizit sagst die Variable bekomme ich durch ein Formular ($_POST) dann ist auch bei register globals on mehr Sicherheit gegeben weil der variablenwert durch nichts ersetzt wird weil ja nichts über ein Formular übergeben wurde.

Ich hab das jetzt nicht ausprobiert aber das sollte so sein .

Da wir aber durch $_REQUEST gesagt haben jeder Weg ist legitim also in unserm Beispiel ob durch das Fenster oder durch die Tür ($_GET oder $_POST) der Einbrecher kommt ist egal weil ich beides akzeptiere.

Greetz

MaxTPayne

also wie gesagt es werden ja bestimmte variablenwerte durch bestimmte Übertragungsmethoden übergeben einmal als Anhang an einer URL z.B.:

www.deinedomain.de/index.php?variable=wert

das ist eine Art der Übertragung. Wenn nun register_globals = off ist, ist diese $variable nicht automatisch verfügbar. Das muss man dan so machen z.B.:



so nun habe ich $variable in meinem php script initialisiert und kann diese dann auch im weiteren Script verwenden.

Nun kann man auch mit Formulare Daten übertragen. Das ist wiederum eine andere Art der Daten Übertragung.



so damit hätte ich die $variable wieder initialisert und könnte diese benutzen und weiterverarbeiten.

Natürlich gib es noch andere Möglichkeiten z.B. Cookies aber das lassen wir mal aussen vor.

Wenn ich nun register_globals = on habe muss ich diese initialiserung nicht machen

Das Problem bei register_globals = on ist das ich z.B. anstatt die Werte über ein Formular zu versenden das auch mit einem Anhang an einer URL machen kann.

Bei einem Webmail ist das ganz unpraktisch denn dann könnte ich in ganz kurzer Zeit einen E-Mail Bomber "bauen".

Beispiel:

Also unser Formular sieht so aus das man einen Namen und einen Text eingeben muss damit man dem Seitenbetreiber eine E-Mail schreiben kann. Beim abschicken wird man zur sendmail.php geleitet.

Wenn jetzt register_globals = on ist und ich in der sendmail.php nicht entsprechend überprüfe ob die Daten von meinem Formular kommen kann ich auch einfach

sendmail.php?name=1337hAx0r&text=viel_spaß_beim_loeschen

aufrufen und dadurch x beliebig viele E-Mails verschicken indem ich die Seite immer wieder aktualisiere.

Nun das ganze wäre nicht passiert wenn ich als Server Konfiguration register_globals=off hätte, denn dadurch wären die Werte von der URL nicht automatisch intialisert worden und somit ständen keine Werte in den Variablen.

Nun das Problem bei $_REQUEST ist das egal welche Art der Datenübertragung ich benutze die variable initialisiert wird. Nun das ist dan so als ob ich für die eine variable register_globals = on setze.

Greetz

MaxTPayne

Ich glaube ich verstehe Seven's Frage, und maxtpayne's Antwort ist nicht vollständig.

@ Seven, ich führe hier jetzt mal ein Beispielscript an:


Das ist nur ein beispiel, und nicht vollständig durchdacht, wo jetzt zb gespeichert wir ob wer admin ist. Aber als Beispiel reichts.
Irgendwie (Cookie, session, Formulareingabe) wird der Wert login übertragen. Ist dieser =1, so ist bereits ein benutzer eingeloggt, wenn nicht findet DB-Abfrage usw startt. Hat der Benutzer Admin-Rechte, wird die Variable $admin 1 gesetzt. Diese Varbiable wird nur während dem einloggen gesetzt.

Auf einem Server mit Globals On könnte ein Hacker jetzt folgende URL eintippen: http://testserver.de/script.php?login=1&admin=1
Da login = 1 ist, ist der Benutzer eingeloggt, und die Variable $admin kriegt den Wert 1, weshalb der Hacker das Adminmenü sieht.
Auf einem Server mit Globals Off gilt der Benutzer zwar als eingeloggt, an der Variable $admin wird aber keine Modifikation vorgenommen (sie ist daher leer).

Um die Sicherheit zu verbessern, könnte man jetzt noch sagen: Der Benutzer ist nur eingeloggt, wenn das Cookie mir diese Information übergibt. Dann müsste in diesesm Beispiel $_REQUEST['login'] durch $_COOKIE['login'] ersetzt werden.

Damit ein Script ausgenutzt werden kann (von einem Hacker) sind folgende Punkte erforderlich: Globals = On, der Hacker muss wissen welche Variable er wie modifizieren muss (entweder ausprobieren, was aber wohl nie Erfolge bringt, oder er kennt den Quelltext)
So, damit sich der Quelltext überhaupt ausnutzen lässt, muss der auch blöd genug sein. Wenn jetzt bei dem Beispiel oben die login-Schleife entfernt wird, wird jedes mal geprüft ob ein Benutzer in der Datenbank steht, auch die Variable $admin wird jedes mal gesetzt (das Script überschreibt dann einen allfällig übergebenen Wert)
Aber auch mit dieser Schleife ist die Verwundbarkeit in der Realität unrealistisch. Ob ein Benutzer Admin ist, ist ja genauso wünschenswert zu wissen wie ob er eingeloggt ist. Dh dieser Wert kommt von "aussen" (ob Cookie, Session oder Formular ist unwichtig). Dh um das Scrip Globals Off tauglich zu machen, würde $admin durch $_REQUEST['admin'] ersetzt werden. Das wäre jetzt angreifbar (bei globals on und off). Aber bei solch sensiblen Daten nimmt man meist zuverlässige Quellen (1. wahl Session oder evtl Cookie).

Die Unsicherheit durch Globals = On ist deswegen eher theoretische Natur, weil der Angreifer umfangreiche Kenntnisse über den Quelltext benötigt, und der Quelltext eine Manipulation zulassen muss (vom logischen Aufbau her). Dass all das zusammenkommt ist sehr unwahrscheintlich (wenn es wirklich eine tragende Sicherheitslücke wäre, hätte wohl kaum ein Server mehr die Globals auf On gesetzt).

Ich hoffe, alle deine Unklarheiten beseitigt zu haben.

mfg Gimli

Zitat

Original von SevenofNine
ah, ja danke dir , nun habe ich es auch verstanden.
Ich glaube ich sollte mich doch mal wieder hin setzen und mich versuchen in php zu vertiefen.

Du könntest solche nicht wirklich wichtigen Fragen auch einfach verdrängen Ich bin in PHP erfahrener als du, habe mich aber bis zu deiner Frage nie mit den Globals beschäftigt Für ein paar Scripte ist es nur wichtig zu wissen, dass man auf Usereingaben mit $_REQUEST['name'] zugreift (damits auch bei Globals off läuft), weswegen das aber so ist, ist unwichtig (Finde ich zumindest).

Zitat

Danke an alle!

np, habe ja auch was gelernt dabei

mfg Gimli