Server steht unter Hack- Attacke...

Mit PHP 6 wird sich das leidige Thema "register globals" eh erledigt haben....;)
 
Auf vielen Servern ist es aber trotzdem an und was in PHP 6 kommt steht auch garnicht zu Debatte da er es bestimmt nicht hat.

Und wenn ihm solche links wie in seinen Logs gezeigt sorge bereiten sollte er RG abschalten falls es das noch nicht ist. Und ja man kann es umgehen wenn das Script schlecht geschrieben ist und das ganze z.B. durch ein extract() aufhebt. Was aber wohl eher sellten der Fall ist. Ich wollt Ihme ja nur einen Tipp geben.

Es soll nicht die Übergabe von GetVariablen verhindert werden
Click to expand...
Der Logschnipsel sieht aber danach aus.
 
Ich bin kein Programmierer aber ich denke das "include $seite;" aus dem Artikel ein Problem ist. Weil z.B. index.php?seite=http....

Aber genau das wird doch durch RG = off unterbunden. Wenn man die index.php aus dem ersten Beispiel nimmt dann kann die variable $seite von aussen nicht definiert werden wenn RG = off.

Aber Programmierer sehen das wohl von einem anderen Standpunkt aus. :)
 
ghost1978 said:
Dies bedeutet das nicht definierte Variablen von "aussen" nicht bestimmt werden können.
Click to expand...
Und wo definiert man diese dann?

Nein, im Ernst Ghost, das ist eine Fehlinterpretation Deiner seits.
register_globals ist dafür da das ein "?var=xyz" nicht automatisch eine globale Variable $var mit dem Inhalt xyz erzeugt wird. Statt dessen muss man speziell per $_GET['var'], $_POST['var'] oder $_REQUEST['var'] darauf zugreifen.
Dennoch ist ein include($_GET['var']) weiterhin möglich. Und damit existiert die selbe Sicherheitslücke!
Register_globals ist also nicht die Lösung. (Und das ist nicht nur die Sicht der Programmierer.)

Für einen include() ist eben der Programmierer selbst verantwortlich! Wenn er ihn aus Parametern zusammenbaut, muss er diese vorher prüfen.
Man kann zwar mit dem Holzhammer ausholen und gleich allow_url_fopen ausschalten, aber das ist auch nicht immer die gangbare Lösung.

PS: Das Problem von RG stammt einfach aus der Geschichte von PHP und wurde bereits zur Einführung von PHP 5 standardmäßig abgeschaltet. Aber aus Kompatibilität per Einstellung von "register_globals" weiter geführt. In PHP 6 werden viele Altlasten aus PHP 4 endgültig ad Acta gelegt, diee bereits in PHP 5 als "deprecated" geführt worden sind.

huschi.
 
Last edited by a moderator:
Für einen include() hingegen ist ein Programmierer schon selbst verantwortlich. Man kann zwar mit dem Holzhammer ausholen und gleich allow_url_fopen ausschalten, aber das ist auch nicht immer die gangbare Lösung.
Click to expand...
So ist es!

Meine Empfehlung:
Code: 
register_globals=Off
allow_url_fopen=On
allow_url_include=Off
 
ghost1978 said:
So etwas wie /index.php?file=Script oder /index.php?file=../../../etc/hosts geht dann nicht mehr.
Click to expand...

Blödsinn... entweder der Programmierer arbeitet direkt mit der $_GET oder $_REQUEST-Variable - dann ist die Einstellung von Register-Globals sowieso egal.
Oder der Programmierer ist faul und emuliert register-globals=on, indem er einfach das $_REQUEST Array mit einer Schleife durchläuft und dann die normalen Variablen füllt. Habe ich auch alles schon gesehen...
 
combie said:
Meine Empfehlung:
Code: 
register_globals=Off
allow_url_fopen=On
allow_url_include=Off
Click to expand...

Sicherlich ein Schritt in die richtige Richtung, jedoch bringt url_include off auch keine 100% Sicherheit, genauso wenig wie fopen off. Seit PHP 5.2 sind neue URL Typen (z.b. "data") möglich die weder von url_fopen noch von url_include überhaupt als URL erkannt werden.

Um nur PHP abzusichern wäre Suhosin das Heilmittel (zumindest in Punkto RFIs), aber am Besten wären Suhosin plus Mod Security....gerade wenn CMSs wie Joomla im Einsatz sind (wie es hier der Fall ist).
 
Last edited by a moderator:
Seit PHP 5.2 sind neue URL Typen (z.b. "data") möglich die weder von fopen noch von include überhaupt als URL erkannt werden.
Click to expand...
Bahnhof!
Wie soll man über diese Wrapper externe Scripte ausführen lassen können?
Weder im PHP Handbuch noch in meinem Gedächtnis findet sich dergleichen.
Kläre mich bitte auf.
Restricted by allow_url_include Yes
Click to expand...
 
Last edited by a moderator:
Gut, bezieht sich natürlich mehr auf local file inclusions, aber diesen Aspekt darf man, gerade wenn man Fremd-Sites hostet, nicht einfach ausschliessen und sich nur auf RFIs konzentrieren....;)

Der "data" URI Type kann jedoch auch für externe Angriffe benutzt werden, Beispiel:
http://securitytracker.com/alerts/2008/Jun/1020322.html
 
Last edited by a moderator:
Naja...
Gegen schlampige Parameterprüfung, ist kein Kraut gewachsen.
Und wie das "data://" da wirklich zur Auswertung kommt, ist dort leider nicht beschrieben. Weil, es einfach in einen Get Parameter zu werfen, richtet noch keinen Schaden an.
 
You must log in or register to reply here.
Back
Top