register_globals enabled

Hallo KingKoehnchen,

bei mir ist das Problem mit register_globals in der 6er Version beim Installieren aufgetaucht, doch wie schon beschrieben, hat bei mir der Trick mit der php.ini Datei geklappt. Allerdings habe ich die nicht in den Drupal Root Folder gepackt, sondern in selbe Verzeichniss wie die .htaccess, cron.php, index.php (...) Dateien.

der Patch dafür ist:

memory_limit = 32M
register_globals = Off
safe_mode = Off
max_execution_time = 60
max_input_time = 120

Als "Problem" kann man das Verlangen nach register_globals = off kaum unpassender bezeichnen. Es ist einfach merkwürdig wenn Hoster meinen diese Option aus Kompatiblitätsgründen an zu lassen, und somit die Sicherheitsproblematik dieser Option ignorieren. Scripte, die dieses Option benötigen, sollten einfach nicht mehr genutzt werden.

gruß pebosi

Vielen Dank für Eure Antworten. Ich möchte hier eine kleine Diskussionsplattform für dieses Thema anstreben, an dessen Ende eine optimale Lösung für dieses Problem gefunden werden soll.

@lubino: Hast Du die php.ini auf dem Server eines Hosters abgelegt? Bei mir tut sich da garnichts.
@pebosi: da stimme ich Dir zu

Wer hat noch Erfahrungen mit diesem Problem gemacht und evtl. eine Lösung gefunden?

Jou die Datei ist auf meinen Server (1und1). schnurrt wie ein Kätzchen.

Klappt auch bei mir ohne Mucken - Provider ist Domainfactory.

@lubino: könntest Du Deine komplette php.ini hier mal posten? Oder handelt es sich nur um die paar Zeilen?

@KingKoehnchen
Bei Drupal 6.2 in der Datei modules/system/system.install die Zeilen 55, 56, 57, 58, 59 löschen oder durch // (slashslash) auskommentieren ;)

@peposi
PHP-Systeme die eine Systemanpassung benötigen, um die eigene Sicherheit zu gewährleisten ist mehr als fraglich, aber das hätte dir auch das 1. Semester-Lehrbuch erklärt.

Drupal 6.2 prüft "register_globals" bei der Installation. In der Laufzeit wird diese nicht geprüft und erscheint deshalb bei der Installation als sinnlos oder bei der Nutzung als unausgereift.

@mkay - Habe Deinen Tip befolgt und die entsprechenden Zeilen auskommentiert. Funktioniert reibungslos. Also, kurzes positives Feedback!

Hallo,

allinkl hat defaultmäßig leider auch register globals auf on. (wahrscheinlich wurden die zig mal angerufen, wieso script xy nicht läuft) Es ist allerdings relativ einfach den Wert selbst zu ändern. Erstellt einfach eine .htaccess-Datei mit folgendem Inhalt

php_flag register_globals off

-------------------------------------
Drupal is sächsäää! :-D http://www.flickr.com/photos/8471827@N06/2531785706/

Also ich hatte beim Einrichten von Drupal auf einem Webspace auch Probleme mit register_globals. Nach kurzer Recherche hab ich aber herausgefunden, dass man das bei diesem Provider (PixelX) in der Server Konfiguration per Web-Oberfläche umstellen kann. Vielleicht geht das auch bei anderen Providern?

Vielen Dank,
hat bei mir auch super geklappt.

mein Provider gab auf meine Anfrage hin folgende Empfehlung:

Um die PHP Variable register_globals auf 0 zu setzen erstellen Sie im gewünschten Verzeichnis (z.B. /public_html) eine Datei mit Namen "php-cgi.ini" für PHP4 bzw. "php5-cgi.ini" für PHP5 und folgendem Inhalt:

[php]
register_globals = off

Vielleicht dient das jemandem.
Grüsse

Mal ne Frage zu register_globals, denke das passt hier ganz gut rein:

Wieso verlangt Drupal denn dass diese auf off gestellt sein müssen?

Öffnen sich so irgendwelche Sicherheitslücken?
Wenn ja, Kann mir jemand vielleicht ne Codezeile nennen, wo dies so ist?

Es gibt doch eigentlich nur Probleme, wenn jemand sich auf die einstellung On verlässt und diese einstellung dann plötzlich auf Off steht.
Anders herum bleibt es sich doch gleich.

gruß

Hallo Sevvo,

mir scheint es so, als würdest Du nicht wissen was Register Globals sind, lies das doch mal nach http://php.net/manual/de/security.globals.php und gib Dir dann selbst die Antwort :-)

habe diese seite des öfteren gelesen und auch die beispiele:

Das Beispiel der Seite für register globals on:

Beispiel der Seite für register_globals off

Aber bei der 2ten Variante können doch auch register_globals auf on sein? Oder warum denn nicht? Bzw was is dann gefährlich?
Kommt das nicht drauf an wie man die Variablen erstellt, also dass wenn register_globals auf off sind, ich besser die supeglobals verwenden sollte und bei sonstigen Variablen diese im Quelltext initialisiert werden.

Hallo Sevvo,

naja das super fatale an aktivierten Register Globals ist, das User allein durch die Eingabe in ein Formular beliebige Variablen erstellen können. (betonung auf können)

Lies Dir vielleicht auch mal das durch http://support.hostpoint.ch/index.php?page=ArticleDetailPage&navigation=... Zu diesem Theme wurde schon super viel geschrieben. Es gibt eigentlich keinen Grund sowas wie RegisterGlobals auf On zu stellen.

Das ist ja genau, was ich meinte, ich muss die Variable vorher initalisieren und dann ists sicher, das wird mir ja in deinem Link gesagt, soweit ich das jetzt entnommen habe.

Deshalb ja meine Frage, welche nun etwas genauer lautet:

Ist Drupal denn unsauber programmiert oder wieso besteht es auf diese Funktion?
Gibt es denn öfters solche Code-Zeilen in Drupal bei denen Variablen nicht initialisert werden? Und kann mir explizit für Drupal jemand ein Beispiel nennen?

Bzw wie war das mit den Formularen gemeint? Da hab ich doch auch feste Variablennamen, wie kann da beliebig Variablen erstellen? Beispiel wäre nett, würde mich echt mal interessieren, danke an die helfende Hand.

Beispiele aus dem Link:

Nun ja, der Grund ist für ON ist bei mir momentan, dass ich eine Webseite für jemanden erstellen soll und derjenige bei dem er hostet bietet nur eine globale php.ini die auch für andere Projekte gilt, und wegen fehlender Server-Rechte kann ich weder eine php.ini, noch .htaccess erstellen oder über ini_set Änderungen durchführen.
Darf allerdings Änderungen in der globalen php.ini durchführen, jedoch nicht in der httpd.conf. Und weil die globale Einstellung nicht geändert werden darf aus register_globals off, da er die einzelnen Projekte auch nicht selbst verwaltet und die diese Eintsellung auf on beibehalten möchte, zumindest global. Würde ja gerne irgendwie die Einstellungen lokal überschreiben, allerdings weiß ich nicht genau wie, da man die AlloOverride Rechte ja z.b in der httpd.conf setzen muss, auf die ich wiederum keinen Zugriff habe. Habe ich in der php.ini Möglichkeiten dazu?

Erföffnen sich jemand Möglichkeiten für mich wie ich mein Problem löse kann?

Du verstehst da etwas falsch. Drupal setzt voraus, dass Register-Globals DEAKTIVIERT ist, eben um diesen Angriffsvektor gar nicht erst zu eröffnen und Modulentwickler auf dumme Gedanken zu bringen.

Heißt das, dass ich Drupal(den core) auch mit aktiviertem register_globals zum laufen bringen kann und es sich nichts an der Sicherheit ändert?
Ausgenommen mal unsaubere Module.
Mich interessiert halt warum dieses Verlangen nach register_globals off besteht, wenn prinzipiell gar kein Bedarf herrscht.

Das ganze dreht sich also nur um Standard-Sicherheitsbedenken und der Drupal-Core ist auch mit aktivierten reg_glob sicher?.

Weiter oben wurden ja z.B auch entsprechende Codezeilen genannt, welche für die Prüfung zuständig sind und behauptet dass diese Prüfung nur bei der Installation stattfindet, allerdings ist dies auch der einzigste Beitrag des Users, was seine glaubwürdigkeit etwas einschränkt.

Nochmal ganz langsam und zum mitlesen:
1. Register_Globals = On ist aus Sicherheitsgründen bedenklich und verleitet zu schlechtem Programmierstil
2. Drupal will bösem Verhalten keinen Nährboden bieten
3. Aufgrund 2. ist Register_Globals = Off eine Systemvoraussetzung für den Betrieb von Drupal und diese wird entsprechend abgeprüft
4. Um Drupal auch mit aktivierten Register_Globals zum Laufen zu bekommen muss man es hacken und das ist wiederum böse!

Ist doch echt schade, dass man im Jahr 2010 noch breitreten muss warum es sinnvoll ist einen alten Zopf von PHP abzuschneiden, abgeschnitten zu lassen und auch nicht aus Neugier und weil es theoretisch doch irgendwie geht ihn auszugraben und wieder anzukleben.

zu 1) Es verleitet zu schlechtem Programmierstil, wenn jedoch richtig programmiert, ist es egal. Oder irre ich?
zu 2) Verständlich, aber ich habe Gründe warum ich dies eventuell umgehen möchte (siehe 2 Beiträge weiteroben, letzter Abschnitt). Wenn dir dazu vll etwas einfällt?
Es ist nicht mein Webspace und er greift für mehrere Projekte, also globale Änderungen schlecht.
zu 3) Hier in dem Beitrag wird ja behauptet dass das lediglich 5 Codezeilen für die Prüfung bei der Installation zuständig sind und wenn sich der ganze Trouble nur wegen diese 5 Zeilen enwickelt, dann entferne ich diese. (nachdem ich mir die auch mal angeschaut hab)
zu 4) Wenn du das dann als Hacken bezeichnest, bitte, ich passe das System halt etwas an, nach meinen Bedürfnissen.
Aber wieso böse? Das ist unter anderem genau der Sinn und Zweck von Open-Source Software.

Ich verstehe ja denn Sinn und Zweck, warum man das ganz auf Off schalten soll, und bei meinem Webspace ist dies auch so, bzw ich kann die Einstellungen lokal anpassen, jedoch bei dem Webspace um den es hier geht, gibt es eben nur die globalen Einstellungen und leider weiß ich nicht wer jetzt angespasst wird. Der Webspace oder Drupal.

Kann mir jemand bitte mal sagen, ob er iwelche Sicherheitsbedenklichen Drupal-spezifischen Einwände gegen Verwendung von Drupal mit aktivierten register_globals hat, die sich nicht nur dadrauf beziehen, dass man register_globals generell nicht mehr verwenden sollte?

gruß

Was heißt hier schon "richtig"? Die Entwickler des Core und der Module verlassen sich korrekterweise darauf, dass Register Globals ausgeschaltet ist. Du findest in diversen Modulen haufenweise Code, wo Variablen die etwa nur lokal verwendet werden nur dann initialisiert werden, wenn sie auch Inhalt bekommen. Ansonsten bleiben sie gewissermaßen nicht-existent. Eine spätere Funktion die nun abprüft ob die Variable Inhalt hat oder nicht geht nicht davon aus, dass vllt. jemand diese von außen dank aktivierter Register Globals vorbelegt hat. So kannst du auch bei grundsätzlich "korrekter" Programmierung Variablen vorbelegen, schlichtweg weil die Entwickler sich auf die Einhaltung der Systemvoraussetzungen verlassen (und auch verlassen können müssen).

Hosting für das entsprechende Projekt wechseln. Ich sehe meine Aufgabe auch darin Kunden adäquat zu beraten und dazu würde in diesem Fall auch die Darlegung der Sicherheitseinschränkung und die Kollision mit den Systemvoraussetzungen von Drupal (und mittlerweile jedem halbwegs brauchbaren System). Wenn er für seine alten Projekte, vllt. weil er den Aufwand eines Updates oder einer Anpassung der Programmierung scheut, den vorhandenen Webspace beibehalten möchte, kann er da ja tun. Aber er muss ja nicht zusätzlich auch in ein neues und "sauberes" Projekt gleich ein Loch reinreißen.

Falsch. Der Trouble entwickelt sich aufgrund historischer Altlasten von PHP, uralten Hosting-Paketen, doofer Hoster, schlechter Beratung, Unwissenheit und sturer Kunden. Du machst den Bock zum Gärtner (bzw. den Gärtner zum Bock) wenn du die Schuld irgendwo in Drupal und bei dessen Entwicklern suchst. Ganz egal ob es sich um 5, 50 oder 5000 Codezeilen handelt.

Unter uns Drupalern wird das unkoordinierte Ändern von Core-Dateien als hacken bezeichnet, ja. Unkoordiniert heißt in dem Zusammenhang, dass du keine Issue zu dem Problem auf Drupal.org eröffnet und etwa einen Patch zur Lösung des Problems angehängt hast. Das hätte auch praktisch keine Chancen auf Erfolg, da du hier keine Funktionalität hinzufügst, oder einen Fehler behebst, sondern du entfernst ein Sicherheitsfeature. Wenn du in deinem Wagen die elektr. Wegfahrsperre deaktivierst kannst du im Fall der Fälle ja mal schauen wie du das mit deiner Versicherung abgekaspert bekommst ;)

Habt ihr mal direkt auf kurzem Dienstweg mit dem Hoster gesprochen? Viele Hoster vor allem kleinere Hoster sind gar nicht so böse und doof und haben ggf. pfiffige Leute und Lösungsvorschläge.

S.o.

Ja, ok, war vielleicht bisschen unkorrekt formuliert. Ich habe halt mal gelernt, dass ich Variabeln generell initialisieren sollte.

Bezieht sich das den auch auf Core-Module? Sorry, ich kanns nich lassen. ;-)

Wird wohl nicht möglich sein.

Soweit ich das verstanden habe, ist der Webspace halt untervermietet, aber es gibt nur eine globale php.ini. Da steckt man halt irgendwie in der Zwickmühle.
Ändere ich einfach mal die Konfiguration von sagen wir mal 10 mir unbekannten Projekten (auch wenn diese Einstellungen vll sinnvoll wäre) oder versuch ich mich zu vergwesissern, dass das neue Projekt auch stabil läuft ohne dieses Sicherheits-Feature, was man ja auch absichern könnte.

Ich habe niemandem Schuldvorwürfe gemacht (sorry, wenn ich sich einige drupalentwickler angegangen fühlen sollten) , ich wollt mich lediglich absichern, dass ich eventuell drupal und seine core-module auch auf die genannte Art und weise sicher ausführen kann, da ja nicht unbedingt gesagt ist, dass nur weil register_globals auf on gestellt ist, gleich jede Seite unsicher wird. Mir wär ja auch lieber ich könnte die Sache serverseitig lösen.

Ok, das war mir nicht klar. Dann versuche ich eben Drupal zu hacken. ;-)
Und die Idee mit der Issue habe ich ja auch wegen den von dir genannten argumenten nicht getan.
Ein Sicherheitfeature zu entfernen ist vielleicht nicht klug, aber wenn der betreffende Code dadurch eventuell nicht unsicherer würde, finde ich könnte man das tun. Werde das ganz nun aber mal weiter mit den betreffenden Leuten absprechen und mir den Code am Wochende mal etwas zu Gemüte führen. Kannst du mir vielleicht ein paar Module nennen wo ich sowas finden könnte?

Ja , ein Ticket wurde erstellt, aber eben nur Einstellungen in der php.ini erlaubt. Und da kann ich sowas nicht einstellen, oder? Bräuchte doch Zugriff auf die httpd.conf?

Also auch in Core-Modulen solche Probleme wenn ich denn hacke? ;-) Sorry, die Neugierde nicht auf...

Aber danke jedenfalls für die Statements, muss mir am Wochende dazu mal noch mehr Gedanken machen und ein paar Sachen abklären.
Wenn jemand noch was einfällt bitte Meinungen äußern, auch wenn ich merke niemand mag mich wirklich dabri unterstützen diese Sache abzustellen.

grüße

Dass dich niemand unterstützen will stimmt doch gar nicht. Hier wollen dir einige helfen aber du willst eben einen völlig falschen Weg einschlagen, das ist das Problem.

Und Core-Hacks macht man einfach nicht, zumal der Hack dann mit jedem Update wieder flöten geht...

Du willst ein Sicherheits-Feature entfernen, um eine "PHP-Altlast" weiter zu verwenden? Sorry, aber das halte ich einfach für total unsinnig.

Bei sowas muss man sich eben als Entwickler auch mal stur stellen und denen eintrichtern, wenn die Drupal ordentlich haben wollen, müssen sie für dieses Projekt eben auf entsprechenden Webspace umschwenken. Man muss ja nicht mit allen Projekten umziehen, sondern kann einen Webspace nur für dieses Projekt nehmen. Das was du da vor hast ist schlicht und ergreifend falsch. Mit Drupal bekommst du ein sicheres und "regelmäßig" aktualisiertes Framework und dann reißt du dort absichtlich eine Sicherheitslücke rein, was soll denn sowas?

Meine Meinung: Die Einzig richtige Lösung wäre es, entsprechend konfigurierten Webspace zu verwenden und das muss dem Kunden dann eben mal klar gemacht werden. Und wenn die da einen auf stur machen, haben sie Pech.

Amen!

Ok, mal noch zur Vollständigkeit, Webspace wurde jetzt übrigens doch erfolgreich angepasst und nicht Drupal. Sah am Anfang halt so aus als wäre eine Anpassung des Webspaces unmöglich.
Danke für eure Hilfe