register_globals per httpd spezial aktivieren ?!

[derdemo]

Hallo,

ich habe das Problem das ich die funktion register_globals ON nicht per Confixx 3.0 (httpd spezial) aktiviert bekomme ?!
Kann mir da jemand einen tip geben, wie der genaue eigabestring lautet ?
habe hier im forum nichts passendes gefunden mit httpd spezial ?

würde mich über hilfe freuen
gruss dennis

[blnsnoopy26]

Ich glaube nicht das du das willst, anosnsten schreib gleich das root PW auf deine webseite.

[derdemo]

hallo,

habe hier scripts die nur mit globals_on laufen :(

habe mich natürlich hier mal umgesehen und gelesen das es nicht UNBEDINGT ein sicherheitsrisiko ist ?

habe auch gelesen das es irgendwie möglich ist nur für einen user unter confixx globals auf ON zu setzen ?!
leider habe ich nirgends gefunden.

gruss dennis

[kuntho]

Wenns unbedingt wirklich sein muss, versuchs mal mit folgendem Eintrag in die httpd_spezial:

Code: Select all

php_admin_flag register_globals On

Du solltest Dir aber über die Folgen im Klaren sein. Skripte, die register_globals brauchen, haben auf einem Internet - Server definitiv nichts zu suchen! Es gibt andere Möglichkeiten, die Variablen die man benötigt, an den Skript zu übergeben!

[Joe User]

habe hier scripts die nur mit globals_on laufen :(

Umschreiben!

habe mich natürlich hier mal umgesehen und gelesen das es nicht UNBEDINGT ein sicherheitsrisiko ist ?

Nur auf anderweitig gesicherten "Single-User-Systemen"...

[jaky]

Geht das auch in Connfixx nur für ein bestimmtes Web?

Ich möchte nur ungern den gesamten Server damit freigeben.

[manfred, das mammut]

Spreche mir nach: Ich will NIEMALS register_globals auf on setzen...

Guckst Du hier -> http://de.php.net/register_globals

Viele Grüße

sp@php.net

[mc5000]

Soll das ne Abschreckungskampange sein?? :twisted:

Die Funktion erhöht die Sicherheit!!! :lol:
Daher ist es durchweg anstrebenswert und zu empfehlen sie zu aktivieren.
Programme die mit dieser Einstellung nicht laufen sind genau zu betrachten und (wenn möglich) durch andere zu ersetzen.

Doch hängt es in erster Linie von dem Script ab, wie "sicher" es ist.

Und dann bleibt noch die alte Wahl zwischen Funktionalität und Sicherheit!
Für viele hier ist es natürlich keine Frage was Vorrang hat! Doch zum Glück kann ja jeder diese Wahl selber treffen!

Abgesehen von dieser Endlosdiskussion wurde das Thema auch schon recht oft im Board behandelt, oder??

Gruß *ohne_jemandem_auf_den_schlips_treten_wollend*

MC

[manfred, das mammut]

Jepp, soll abschrecken.

Man muss auch klar unterscheiden:
safe_mode on erhöht die Sicherheit.
register_globals off ist für die Basissicherheit zwingend notwendig. Da geht kein Weg dran vorbei.

[jaky]

Hab ich ja verstanden, begriffen und so ....

Das sind 2 Scripte von einem Kunden. Bannerrotation und Kleinanzeigenmarkt.

Ist das Umschreiben sehr schwer?

Von PHP hab ich keinen blassen Schimmer.

[mc5000]

Ist das Umschreiben sehr schwer?

Nö!

Von PHP hab ich keinen blassen Schimmer.

Dann -> doch!

Empfehlung: http://www.php.net oder Du fragst jemand der sich mit so was auskennt - "GelbeSeiten" :lol:

[fritz]

Spreche mir nach: Ich will NIEMALS register_globals auf on setzen...

Guckst Du hier -> http://de.php.net/register_globals

Viele Grüße

sp@php.net

Hi Manfred,
darf ich mal provokativ fragen, warum die PHP-Entwickler die Funktion 'register_globals' nicht einfach wieder 'ausbauen' ?
Man könnte doch Millionen Unwissende automatisch vor Schaden bewahren ;-)
Gruss Fritz

[legato]

Naja, man hört immer wieder das es auch rausfallen wird...

Ich schätze mal die Option ist noch drin weil es einfach zu viele Scripte gibt die nicht ohne laufen. Irgendwann wird es sicherlich rausfliegen, mich würds nicht stören.

[manfred, das mammut]

Ich muss zugeben, dass ich selbst nicht weiss, warum register_globals noch vorhanden ist.

Ich persönlich nutze register_globals als Debug-Funktion, gerade weil man damit schnell ein paar Variablen über den Get-String manipulieren kann.

[Roger Wilco]

darf ich mal provokativ fragen, warum die PHP-Entwickler die Funktion 'register_globals' nicht einfach wieder 'ausbauen' ?
Man könnte doch Millionen Unwissende automatisch vor Schaden bewahren ;-)

Wieso wieder ausbauen? Reicht es etwa nicht, dass der Defaultwert für register_globals "off" ist?

[manfred, das mammut]

Es gibt immer einen DAU, der den roten Knopf drückt...

[beff]

Leute, tut mir Leid, aber wenn ich in einem Skript jede Variable sauber initialisiere (entweder von POST, GET, SESSION, COOKIE etc. holen, oder mit einem Wert belegen), dann ist es vollkommen egal, ob register_globals On oder Off ist. Ein sorgfältig programmiertes Skript bietet keine Angriffsfläche für das einschleusen von Werten.

Die Panikmache um register_globals hat wohl vielmehr damit zu tun, dass die Leute dazu gezwungen werden sollen, sauber zu programmieren. Denn "unsaubere" Programme funktionieren mit register_globals Off nicht ;).

Ã?brigens: die vielen "Hobby-Programmierer" sind sowohl die Ursache für den Erfolg als auch für den kindlichen Ruf, den PHP hat. Und PHP versucht jetzt immer mehr, "professioneller" zu werden (gerade die 5er Version hat ziemlich viel bei Java abgekuckt), auch wenn viele Dinge noch fehlen.

[manfred, das mammut]

Denkfehler.

Selbst wenn Du alle externen Variablen sauber über POST, GET etc. initialisierst, können dennoch alle internen Variablen von außen geändert werden. Mit register_globals macht man das Skript nacht außen "dicht".

[Roger Wilco]

Selbst wenn Du alle externen Variablen sauber über POST, GET etc. initialisierst, können dennoch alle internen Variablen von außen geändert werden.

Nein. Wenn ich eine Variable in meinem Skript richtig initialisiere (oder anders gesagt, mit einem Wert belege), kann sie nachträglich nicht mehr von außen geändert werden. Auch nicht mit aktivierten register_globals.

[fritz]

Wieso wieder ausbauen? Reicht es etwa nicht, dass der Defaultwert für register_globals "off" ist?

Du siehst doch, wie viele es auf ON setzen (möchten), um ihre Krüppelscriptprobleme zu lösen. Und so gefährden die nun mal vorhandenen 'unerfahrenen' Admins nicht nur sich selbst, sondern evtl. noch ihre 'Nachbarschaft'. Denn nicht alle, die es einfach so lösen, kündigen das hier oder in anderen Foren an, und lassen diese 'Ermahnungen' / 'Belehrungen' über sich ergehen und lernen daraus.
Aber im Grunde ist mir das egal und die Diskussion darüber unwichtig. Ich habe nur darauf reagiert, wenn jemand eine Funktion einbaut, feststellt, dass sie Gefahr bedeutet, empfiehlt, sie NIE auf ON zu setzen, warum sie dann nicht konsequenterweise wieder ausgebaut wird. Roger W., ich hoffe, ich habe mich jetzt verständlich ausgedrückt!?

Gruss Fritz

[Roger Wilco]

Roger W., ich hoffe, ich habe mich jetzt verständlich ausgedrückt!?

Du hattest dich auch vorher schon klar und verständlich ausgedrückt.
Aber nur weil es eine Sprache einfach macht, sich in den Fuß zu schießen, muß man ja nicht gleich den Abzug entfernen. ;)

[beff]

@Manfred: Kein Denkfehler, sondern ein Lesefehler *g*. Aber Roger hat das ja schon berichtigt. Mein Denkansatz war schon richtig ;).


Ok, worum es ja eigentlich geht, das ist die SICHERHEIT!

Frage: Kann ich Sicherheit damit erreichen, dass ich register_globals auf Off stelle?

Antwort: Nein. Denn dadurch verringere ich allenfalls die Anzahl der manipulierbaren Variablen. Aber selbst mit register_globals Off bin ich keineswegs davor geschützt, dass z.B. jemand POST-Daten manipuliert und eine SQL-Injection durchführt.

Und vor allem: Wenn ich von heute auf morgen register_globals ausschalte, steigen mir meine Kunden aufs Dach.

Die Sicherheit für PHP-Skripte liegt in anderen Dingen.

- magic_quotes On - Damit verhindere ich SQL-Injections.

- openbasedir restriction - Jeder Kunde/jedes Webangebot sollte seinen eigenen abgeschotteten Bereich haben, und nur in diesem darf er rumfuhrwerken.

- Datenbankbenutzer mit eingeschränkten Rechten benutzen (z.B. nur SELECT, und nur Tabelle usr_web18_1). Was die openbasedir restriction für das Dateisystem ist, ist der eingeschränkte DB-User für die Datenbank ;).

- safe_mode on - Damit verhindere ich, dass jemand zum Beispiel eine PHP-Datei hochlädt (es gibt genug PHP-Skripte, die das erlauben, traurig aber wahr), eine (z.B.) dbaccess.php includet und Angriffe gegen die DB fährt. Denn beide Dateien haben verschiedene Besitzer (z.B. web18 und wwwrun), und damit können sie nicht zusammenarbeiten. Für den Fall, dass der safe_mode Off sein muss (auch hier gibt es Software, z.B. das CMS Mambo in manchen Fällen), ist es natürlich Pflicht, die Endung hochgeladener Dateien zu prüfen (z.B. nur Bilder zulassen etc.).

Berücksichtigt man diese Dinge, so ist im Falle eines Programmierfehlers allerhöchstens das zugehörige Webangebot gefährdet, aber nicht der ganze Server. Und auch register_globals schützt nicht vor fehlerhaften PHP-Skripten ;).

Wie gesagt: register_globals wird meiner Meinung nach überbewertet, und dient meiner Meinung nach nur dazu, dass ein minimal besserer Programmierstil gepflegt wird und Skripte minimal weniger manipulirbar sind. Sicherheit kriegt man dadurch aber nicht zustande. Ich lass mich aber gern eines anderen belehren, allerdings nicht mit besserwisserischen Sprüchen, sondern nur durch echte Fakten :).

[[tom]]

Ich stell mich mal auf Manfreds Seite und will das mit einem anderen Beispiel illustrieren.

Eine Firewall kann ich so konfigurieren, dass alles erlaubt ist und nur das, was ich expiliz eintrage, verboten ist.

Ich kann aber auch erstmal alles verbieten und nur das erlauben, was ich explizit eintrage.

Ist die 2. Konfiguration sicherer? Nö - aber sie schützt nur vor Vergesslichkeit und Konfigurationsfehlern. Und darum geht es.

register_globals on bedeutet also, dass man alle möglichen und unmöglichen Variablen initialisieren muss. Bei Firewalls käm keiner auf die Idee zu sagen: "Pah - das ist doch kein Problem - das mach ich locker".

Abgesehen von der Unwissenheit schützt register_globals off vor Vergesslichkeit und der Schwäche des Ã?bersehens. ;-)


[TOM]

[kawfy]

Ok, worum es ja eigentlich geht, das ist die SICHERHEIT!

Richtig Beff. Beispiel zu register_globals: Was ist an "include $_GET['datei'];" sicher? -- Richtig, es wird mit Sicherheit gehackt. :-D Glückwunsch. :arrow: Es kommt auf das Ã?berprüfen des Queries im Skript an. Motto: "traue keinem GET" (oder POST oder ...).

Einer geht noch: allow_url_fopen abschalten. Wer es braucht, kann es ja einschalten, z. B. mit ini_set(). Achso, geht ja nicht, weil dann wieder die zig installierten Skripte der Kunden nicht funktionieren. :? Muss man einen Mittelweg finden ...

[beff]

@TOM: Sorry, aber das ist kein Beispiel, sondern ein Vergleich. Ob der Vergleich einer Firewall mit register_globals gerechtfertigt ist, ist außerdem die Frage.

Außerdem kann man gegen Vergesslichkeit auch das Error-Reporting von PHP eine Stufe hochsetzen, dann meckert er auch wegen nicht initialisierten Variablen. OK, nicht ganz ernst gemeintes Argument von mir, aber stimmen tut's :D.

Aber gut, deshalb nochmal die Preisfrage:

Auf einem Webserver (z.B. 1&1 Rootserver) hat jeder Kunde einen eigenen Unterordner, welcher zugleich sein Basedir ist, und eine eigene Datenbank mit eigenem Benutzer, dessen Rechte sich auf nur diese Datenbank beschränken. Die Direktive openbasedir_restriction ist aktiviert, register_globals ebenfalls.

Frage:
Ist es mit dieser Konfiguration möglich, dass ein Angreifer die Daten anderer Kunden manipulieren oder gar Root-Rechte auf dem Server erlangen kann? Falls ja, geben Sie ein beliebiges Stück PHP-Code an, mit dem dies möglich wäre.

Hinweis:
Dies wurde von mehreren Leuten in diesem Thread indirekt behauptet.

Arbeitszeit: unendlich
Erlaubte Hilfsmittel: alle
Belohnung: ein Appel und ein Ei

Viel Erfolg ;).


Ich bleibe bei meiner Behauptung:

Die Sicherheit eines Servers liegt allein im BaseDir und in der Einschränkung des Datenbankbenutzers. Nur diese beiden Dinge können gegen schlecht programmierten oder böswilligen PHP-Code etwas ausrichten.

register_globals Off hingegen ist gegen so etwas absolut machtlos, und kann deshalb kein Basisbestandteil der Sicherheit eines Webservers sein!