endlich mal wieder register_globals

[elrond]

Hallo allerseits,

auch wenn einigen das Thema sicherlich zum Hals raushängt, würde ich es gern nochmals zur Diskussion stellen.

Alles was ich bisher an negativen Dingen zu "register_globals=on" rausfinden konnte ist, dass ein potentieller Angreifer in der URL eine Variabel erzeugen könnte um in den Ablauf des Scripts einzugreifen. Durch den expliziten Aufruf der Vars aus den globalen Array $_GET & $_POST verliert ein solcher Angriff seine Wirkung.

Könnte mir vielleicht jemand die Augen öffnen und diese für mich sehr theoretische Bedrohung erklären ?

Da ich keine Vars kenne die per Default immer benutzt werden verstehe ich die Gefahr nicht wirklich...



PS: Ich habe die Frage ernst gemeint...

[Gaert]

http://www.google.de/search?q=securi...le+Suche&meta=

[mehlvogel]

Das ganze hängt natürlich auch mit schlechtem Code zusammen, nehmen wir an du hast Code like this:

$query = "SELECT blabla FROM blabla WHERE blub='".$blubb."'";

Wenn $blubb nun aus einem POST Formular kommt, und vorher nicht kontrolliert wird, könntest du per GET einfach an die URI hängen:

bla.php?blubb='; DELETE * FROM blabla;

Datenbank == flöten. Jetzt kommt: Ah schlechter Code, da passiert mir sowas nicht, sowas mach ich net - ja, aber es gibt _viel_ mehr schlechten Code im Netz als man denkt. Man kann auch register_globals off übergehen, aber wenn man das benutzt, dann kommt man evtl. schon auf den Gedanken das man die Variable vielleicht escapen sollte. Ausserdem finde ich es immer übersichtlicher wenn man $_GET oder $_POST im Quelltext sieht, denn so weiß man wo die Werte herkommen - Stichwort: Überishctlichkeit

[elrond]

Damit sehe ich mich in meinem ursprünglichen Post bestätigt.

Es ist natürlich so, daß schlampiger Code immer eine gewisse Unsicherheit mit sich bringt, und wer sql-queries auf der URL übergeibt, dem ist latürnich nicht zu helfen....

Nach wie vor sehe ich aber nicht, daß eine Site die "register_globals=on" arbeitet per Definition unsicher ist. Es ist in dieser Konfiguration eben nur einfacher unsicheren Code zu produzieren...

Ausserdem finde ich es immer übersichtlicher wenn man $_GET oder $_POST im Quelltext sieht, denn so weiß man wo die Werte herkommen - Stichwort: Überishctlichkeit

das unterschreibe ich gern...

[Cosmo]

gerade eben dachte ich noch "komisch immer sind register globals auf off, na ja wegen der Sicherheit, mmmm"

aber wenn man mal so durch die Gegend streift gehen fast alle Tips in die Richtung "dein Script geht nicht dann stell doch mal register Globals auf on"

Da ich ein Freund von möglichst sauberen Code bin (ich sage nicht das ich das in vollendung kann) bin ich gerne bereit mit $Post und den anderen Kumpels zu arbeiten.....

leider geht das nur in der Theorie so da auf den von mir genutzten Servern nicht nur neue Seiten liegen, na ja und wer will schon alle alten Seiten neu durchsehen.

Die so gerühmte abwärtskompatibilität ist auf keinen Fall einwandfrei schade auch.

Und so lange es immer wieder heißt "stell doch auf on" sehe ich in auf breiter Front keinen wirklichen Fortschritt

[Gaert]

Hallo,

jetzt habe ich etwas mehr Zeit.

Original geschrieben von elrond

Damit sehe ich mich in meinem ursprünglichen Post bestätigt.

Die Problematik mit register_globals=on ist generell folgende:
Du gibst einem potentiellen Angreifer die Möglichkeit Variablen in deinem Skript mit Werten zu initialisieren, also quasi dein Skript ohne dein Einverständnis zu manipulieren.
Dies wird durch register_globals=off verhindert, da dadurch ein eigeneer Namensraum für sämtliche Werte die von "Aussen" kommen geschaffen wird.
Um den selben Sicherheitseffekt zu erreichen müsstest du SÄMTLICHE Variablen (nicht nur die, von denen du erwartest, dass sie von "Aussen" kommen), die du in deinem Skript verwendest vor der ersten Verwendung initialisieren.

Das Beispiel welches Mehlvogel gebracht hat, ist ein sehr schönes Beispiel für eine SQL Injection - allerdings hat sie nicht direkt etwas mit dem Thema register_globals zu tun.
Man kann das Problem allerdings umformulieren, damit dir die Problematik klar wird... nehmen wir an der Entwickler erwartet nicht, dass $blubb von aussen mit Werten gefüllt wird. Er verwendet das Skript beispielsweise auf einer Seite welche eine Suchfunktion bietet, und die sich den Suchwert z.B. in der Session merkt - das Skript baut daraus dynamisch eine WHERE Klausel zusammen speichert sie in $blubb. Beim ersten Aufruf der Seite wäre $blubb dann unter Umständen nicht initalisiert, da noch kein Suchwert in der Session vorhanden ist. Mit register_globals=off wäre das kein Problem - mit register_globals=on schon, denn damit gibst du einem Angreifer die Möglichkeit (wie im Beispiel von Mehlvogel) eine SQL Injection vorzunehmen.
Alles was der Angreifer dazu braucht, ist Kenntnis über die Funktionsweise deines Skripts - diese kann er auf vielerlei Wege bekommen haben.
Selbst der Sauberste Programmierer macht irgendwo solche Fehler... Fakt ist, dass register_globals=off dieses Problem behebt, und dass register_globals=on Angreifern die Tore zu den Variablen deines Skripts öffnet.

Original geschrieben von elrond

Nach wie vor sehe ich aber nicht, daß eine Site die "register_globals=on" arbeitet per Definition unsicher ist. Es ist in dieser Konfiguration eben nur einfacher unsicheren Code zu produzieren...

Ich hoffe ich konnte es dir erklären - wir können gerne weiter Diskutieren, wenn du es noch nicht verstanden hast.

@Cosmo
Ich hoffe auch du hast verstanden worum es geht!
Die Abwärtskompatibilität ist übrigens gewährleistet - ab PHP 4.1 sind die $_ Arrays vorhanden und werden gefüllt (unabhängig von register_globals der Einstellung deines Providers - wenn ein Provider eine ältere Version einsetzt solltest du ohnehin wechseln) - wenn du anständig programmierst und die Superglobalen Arrays einsetzt, wirst du nie Probleme mit Abwärtskompatibilität haben.

Original geschrieben von elrond
na ja und wer will schon alle alten Seiten neu durchsehen.

Jeder, der sichere Skripts haben möchte!

Original geschrieben von elrond
Und so lange es immer wieder heißt "stell doch auf on" sehe ich in auf breiter Front keinen wirklichen Fortschritt

In PHP 5 wird es diese Möglichkeit irgendwann nicht mehr geben - spätestens dann werden die Leute sich umstellen müssen.

So leit es mir tut... Leute die aus Bequemlichkeit register_globals auf on stellen sollte man alle in einen Sack packen und draufschlagen - damit produzieren sie nicht nur unsichere Skripte sondern schaden auch noch dem Ruf von PHP, da jeder behauptet PHP Skripte wären potentiell unsicher.

Gruß,

Gaert

[elrond]

Danke Gaert,

das macht die Sache etwas klarer...


Bei Licht betrachtet, ist das Ganze aber nur für sehr einfache Scrips relevant.

Sobald ich anfange in Funktionen zu arbeiten stehen Variabeln nicht einfach so zur Verfügung. Dh. der Entwickler muß explizit die Vars in der Funktion sichtbar machen.
Im Fall von "register_global=on" kann einfach ein "global $var" verwendet werden. Anderenfalls würde ich, schon um Schreibarbeit zu sparen folgendes tun: "$var=$_POST['var']".

Das beudeutet in jedem Fall, dass die Variable explizit benutzt wird, und egal wie viele Vars der Angreifer "erfindet" werden diese keine Auswirkung haben, da sie nicht in der Funktion sichtbar gemacht werden. Wichtig ist in jedem Fall, daß der Var-Inhalt vor der Verwendung validiert wird, egal auf welchem Weg die Var in die Funktion gelangt.

Wenn man natürlich innerhalb der funktion ALLE Vars sichtbar macht (zB. in einer Schleife), besteht das beschriebene Problem.

[Cosmo]

Ich hoffe auch du hast verstanden worum es geht!

Sir, ja Sir

Die Abwärtskompatibilität ist übrigens gewährleistet - ab PHP 4.1 sind die $_ Arrays vorhanden

ja eben erst ab 4.1 leider sprech ich hier von Versionen < 4.1

tellen sollte man alle in einen Sack packen

n bischen hart ausgedrückt aber mitmachen will ich auch

[elrond]

Ich möchte nicht den Eindruck erwecken, daß ich hier Partei für's Schreiben unsicherer Script ergreife...

...dennoch gehöre ich zu denen die Bequemlichkeit schätzen....

[comrad]

Hi

es ist eine Umstellung von wenigen Sekunden, um vor jedem Script die übergebenen Variablen einzulesen. Das kann man selbst sogar wieder serialisieren.

Auf jedenfall ist der Mehraufwand minimal, der Nutzen dafür um so grösser.

comrad

[mehlvogel]

auf php.net ist noch ein gutes Beispiel, umgehen eines Logins:

[php]
// Beispiel 15-14. Mit register_globals=on arbeiten

<?php
if ($username) { // kann vom User mit get/post/cookies übermittelt werden
$good_login = 1;
}

if ($good_login == 1) { // kann vom User mit get/post/cookies übermittelt werden
fpassthru ("/highly/sensitive/data/index.html");
}
?>

// Beispiel 15-15. Mit register_globals = off arbeiten

<?php
if($_COOKIE['username']){
// kann nur von einem Cookie kommen
$good_login = 1;
fpassthru ("/highly/sensitive/data/index.html");
}
?>

[elrond]

danke mehlvolgel,

jetzt komme ich der Sache gedanklich näher...

Bei der Arbeit mit "register_globals=off" ist sichergestellt, dass eine Var,die ich aus einem Cookie beziehen mächte, tatsächlich auch aus dieser Quelle stammt, und nicht un der URL erzeugt wurde. Damit ist die geklärte Herkunft eines Wertes Teil der Validitätsprüfung.