Seite läuft auf Linux, nicht aber Unix-Server

[dabauer82]

Hallo,

wir haben für einen Lehrstuhle eine Webseite mit CMS geschrieben. Die seite funktioniert auch 'fehlerfrei'. Zu sehen unter kc.pagehost.de. Dort ist ein Linuxserver.

Als wir nun die Seite und alles was damit zu tun hat, auf den UNIXserver des Lehrstuhls kopiert haben, mussten wir feststellen, dass fast gar nichts mehr geht. Das Design passt nicht, einige Funktionen sind defekt und das Backend geht gar nicht mehr.

Wie kann ich am besten jetzt prüfen, wo die Defizite des Unixsystems sind, bzw welche Misskonfiguration dort vorliegt!. Könnte PHP oder MySQL nicht korrekt konfiguriert sein? Fehlerhaft?

http://www.tet.tu-cottbus.de/kc_tet

grüße

[miker]

Wenn ich mir den Quelltext von http://www.tet.tu-cottbus.de/kc_tet ansehe, sehe ich ganz unten auf der Seite:

Code: Select all

<b>Warning</b>:  Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in <b>Unknown</b> on line <b>0</b><br />

Möglicherweise führt das zu den Problemen?

Und warum hat die CSS-Datei die Extension .php? Ich weiß nicht genau, wie sich das verhält, aber möglicherweise läuft der PHP-Interpreter drüber und deswegen wird sie nicht korrekt ausgelesen.

[elias5000]

Die Antwort findet sich im Quelltext der Seite:

Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively.

Auf register_globals=on basierend zu programmieren ist extremely deprecated und nach aktuellen Maßstäben schlechter Style.
Es ist für fast alle in letzter Zeit aufgetretenen Sicherheitsprobleme im Zusammenhang mit PHP erforderlich und sollte unter keinen Umständen in neue Projekte einfließen.

Was ihr jetzt machen könntet, ist register_gobals auf on zu setzen, oder (was wesentlich besser wäre) euren Code so umschreiben, dass er keine Globals mehr benötigt.
Dies wäre eine gute Gelegenheit für einen Codereview und die Konsultation von erfahreneren Programmierern für den Review sicherheitskritischer Codebereiche. (Ich leite mal aus der Verwendung von Globals die Notwendigkeit eines solchen Review ab.)

[dabauer82]

ok, also alles neu? :-)
Danke schon mal für den Hinweis. Es liegt natürlich bei dem Lehrstuhl zu sagen, Globals on oder aus, jede nachdem werden wir dan handeln müssen.

danke dennoch.


die css endet auf PHP, da wir die css styles aus den Datenbank auslesen. so können die stylsheets über das Backend geändert werden, bzw. das Design gesteuert werden...

[mattiass]

Und warum hat die CSS-Datei die Extension .php?

Ich mache das manchmal, um CSS passend zum Browser auszuliefern. Man muss nur den richtigen Header mitgeben.

[mattiass]

Danke schon mal für den Hinweis. Es liegt natürlich bei dem Lehrstuhl zu sagen, Globals on oder aus, jede nachdem werden wir dan handeln müssen.

Ja. Am Besten ist es allerdings die RegisterGlobals auf Off zu lassen und die Scripte zu korrigieren. Oft reicht eine zentrale Include-Datei, welche POST- und GET-Variablen in die bislang von außen übergebenen Variablen überführt.

Code: Select all

$style = $_GET['style'];
$page = $_GET['page'];
// ...

So kann man dennoch einer Übergabe von eigentlich nur intern verwendeten Variablen vorbeugen.