dynamic-net.ch AG News

PHP mit register_globals Off verwenden UPDATE

Sat, 04 Feb 2012 08:00:00 GMT

Aus Sicherheitsgr�nden ist auf unseren Webservern die PHP Direktive register_globals ausgeschaltet. �ltere PHP Skriptl�sungen, wie z.B. PHP Nuke und osCommerce, sind auf eingeschaltete Globale Variablen angewiesen, moderne weisen jedoch sogar auf diese Sicherheitsl�cke hin, wenn register_globals aktiviert ist.

In der Regel l�sst sich jedes PHP-Skript so programmieren, dass diese Voraussetzungen nicht erforderlich ist. Das Skript ist dann sauberer programmiert und bietet eine h�here Kompatibilit�t.

Der Hauptunterschied liegt in der Verwendung von Variablen, die nicht im aktuell ausgef�hrten PHP Skript definiert werden, z.B. Formularvariablen via POST- oder URL-Parameter via GET-Methode, aber auch Cookie-Variablen. Im folgenden Beispiel wird eine Formularvariable ("benutzer") abgefragt:

Mit register_globals On:

$b=trim(addslashes(strip_tags($benutzer)));
# ...
?>

Mit register_globals Off (Code kompatibel zu On):

$b=trim(addslashes(strip_tags($_POST['benutzer'])));
# ...
?>

Weiterf�hrende Informationen finden Sie auf der PHP-Website:
� Kapitel 29. Verwendung von Register Globals

Schneller Workaround:
Um z.B. per GET �bergebene Parameter im Skript weiter verwenden zu k�nnen, empfiehlt sich, im Parameter empfangenden PHP-Dokument zuoberst die PHP-Funktion extract() zu verwenden. Diese Funktion weist Array-Key/Value-Parametern entsprechende Variablennamen mit deren Inhalt zu.
Folgende Codezeilen sollten also die Funktionalit�t Ihres Skripts wiederherstellen:

extract($_GET, EXTR_SKIP);
#
# Hier folgt Ihr eigener Code
# ...
#
?>

Wenn Formulardaten per POST �bermittelt werden, muss anstelle von $_GET das $_POST-Array referenziert werden.

Wichtiger Hinweis: Dieser Workaround ist nur als tempor�re L�sung zu verstehen, der Code sollte zeitnah angepasst werden. Beachten Sie den Parameter EXTR_SKIP, der verwendet werden muss, damit aus Arrays extrahierte Variablen nicht lokal vorhandene �berschreiben!

Berechtigung von Dateien nach PHP-Upload (chmod, umask, 600)

Sat, 04 Feb 2012 08:00:00 GMT

In einigen Serverkonfigurationen werden Dateien nach PHP-Upload per Standard auf die Rechte 600 gesetzt (Lese- und Schreibrechte nur f�r den erstellenden Benutzer). Damit der Webserver die Berechtigung hat, die Dateien des Web-Users anzuzeigen, sind zus�tzliche Berechtigungen notwendig, die jedoch derzeit nicht per Standard gesetzt werden k�nnen.

Mit diesem Tech-Channel Beitrag zeigen wir Ihnen L�sungen f�r ausgew�hlte CMS und eigene Skripte auf.

Joomla
Das CMS Joomla bietet bei der Installation die Option zur Definition von festen Verzeichnis- und Dateirechten. W�hlen Sie diese Option mit den Standardwerten 644 f�r Dateien und 755 f�r Verzeichnisse aus.
Nachtr�glich k�nnen Sie diese Option im Men� Site -> Global Configuration setzen, wie in folgendem Bild dargestellt:

Gallery2 (Menalto)
Auch die Menalto-Galerie bietet die M�glichkeit, �ber die Konfiguration Standardrechte zu setzen. Die Option finden Sie unter Site-Administration -> Allgemeine Einstellungen:

Eigene Skripte
Damit Dateien in eigenen Skripten die korrekten Rechte erhalten, bieten sich zwei L�sungswege an:

1. PHP-Funktion chmod() (empfohlen)
Rufen Sie die Funktion in Ihrem Upload-Skript direkt nach Upload mit der neu erstellten Datei auf.

# ...
# Ihr Upload-Code
# ...
// Bei einem erstellten Verzeichnis (selten):
chmod ("./verzeichnisname", 0755);
// Bei einem hochgeladenen Bild (oder sonstiger Dateityp):
chmod ("./verzeichnis/meinbild.jpg", 0644);
?>

2. PHP-Funktion umask()
Wenden Sie diese Funktion idealerweise am Anfang des Upload-Skriptes an. Umask ist als eine Art inverse Maske zu verstehen. Um die gew�nschten Berechtigungen zu erhalten, setzen Sie den Wert 022:

umask(022);
# ...
# Ihr Upload-Code
# ...
?>

Perl: Sicheres Skripting mit perlsec

Sat, 04 Feb 2012 08:00:00 GMT

Perl-Skripte werden auf den Webhosting-Servern neu per Standard unter Ber�cksichtigung der Perl security ausgef�hrt, um "tainted data" (verschmutzte Daten) aus Umgebungsvariablen zu verhindern, welche die Ausf�hrung von schadhaftem Code erm�glichen k�nnen.

M�glicherweise erhalten Sie neu folgende Fehlermeldung bei Ausf�hrung eines Perl-Skripts (im Beispiel formmail.pl) im error.log (bei Webhosting-Kunden im Browser nur durch "Internal Server Error 500" erkennbar):

Insecure $ENV{PATH} while running setuid at formmail.pl line 391.
Premature end of script headers: /home/www/webX/html/cgi-bin/formmail.pl

Um diesen Mangel zu beheben, kann der Pfad im Array der Umgebungsvariablen neu gesetzt und nicht ben�tigte gel�scht werden. F�gen Sie nach den allgemeinen Definitionen folgende zwei Zeilen in Ihr Perl-Skript ein:

$ENV{PATH} = "/bin:/usr/bin";
delete @ENV{ 'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

Die von uns bereitgestellte Version von FormMail.pl wurde bereits aktualisiert und steht in der FAQ zum Download bereit.

MySQL-Fehler: 1054 - Unknown column 'p.products_id' in 'on clause' (oder �hnlich)

Sat, 04 Feb 2012 08:00:00 GMT

MySQL in der Version 5 ist gegen�ber Version 4 weniger tolerant bez�glich nachl�ssig formulierter Queries - insbesondere betrifft dies Abfragen mit JOIN Syntax. Sind z.B. in der Abfrage Tabellen in falscher Reihenfolge der JOIN-Verkn�pfung vorangestellt, wird bei MySQL 5 oben angegebene Fehlermeldung generiert.

Betroffen sind u.a. Versionen von osCommerce und Woltlab Burning Board. Patches werden teils von den Skriptherstellern oder Skriptnutzern bereitgestellt (siehe unten).

Als schneller Workaround ein Auszug eines Problemskripts in osCommerce. Folgende Abfrage erzeugt den oben genannten Fehler:

select count(p.products_id) as total from products_description pd, products p left join manufacturers m on p.manufacturers_id =[...]

Wird diese Abfrage folgendermassen korrigiert, funktioniert die Abfrage problemlos:

SELECT COUNT(p.products_id) AS total FROM products p, products_description pd LEFT JOIN manufacturers m ON p.manufacturers_id =[...]

Patches
F�r betroffene osCommerce-Versionen steht hier ein Patch zum Download bereit.

Sensible Zugangsdaten in Perl- und PHP-Skripten sicher verwenden

Sat, 04 Feb 2012 08:00:00 GMT

Nahezu jedes CMS und auch viele kleine Skripte, wie z.B. G�steb�cher, verwenden MySQL-Datenbanktabellen. Um die Datenbankverbindung herzustellen, m�ssen die Zugangsdaten mit ihren entsprechenden Skriptbefehlen meist in zu inkludierenden Dateien im Web gespeichert werden.

In seltenen F�llen kann es durch Fehlkonfigurationen oder tempor�ren Diensteausf�llen passieren, dass Code von Skripten vom Perl- oder PHP-Interpreter nicht geparst (Befehle ausgef�hrt) wird. Dies h�tte zur Folge, dass der Source-Code dem Betrachter der Seite zum Download angeboten wird - was unter Umst�nden z.B. die erw�hnten MySQL-Zugangsdaten oder sonstige sensible Informationen offenlegt.

Um diese Art Sicherheitsl�cke zu umgehen, empfiehlt es sich, sensible Daten ausserhalb des f�r den Browser erreichbaren Verzeichnisses zu platzieren:

�ber den Browser sind per Standard alle Dateien in dem Verzeichnis /html und darunter zu erreichen. Die Ordnerstruktur des Webhostings bietet auch ein Verzeichnis /files, dem keine (Sub-)Domain zugewiesen werden kann, worauf Sie jedoch normal Zugriff haben und Daten speichern k�nnen. Es empfiehlt sich, an diesem Ort Ihre sensiblen Skriptdaten zu speichern. Innerhalb Ihres Webs k�nnen Sie bei PHP mit einer include(), require() oder require_once()-Funktion diese Dateien referenzieren.

Anwendung mit fertigen PHP-Skriptl�sungen, wie z.B. Joomla, WordPress, usw.

Bei CMS und anderen Fertigl�sungen liegt meist eine Konfigurationsdatei vor, die im Stamm- oder einem eigenen include-Verzeichnis gespeichert ist.
Um diese Konfigurationsdatei mit ihren sensiblen Daten auszulagern, f�hren Sie folgende Schritte aus:

Kopieren Sie die Konfigurationsdatei in das Verzeichnis /files (oder ein dort angelegtes Unterverzeichnis)
Ersetzen Sie die originale Konfigurationsdatei durch eine Datei mit folgendem Inhalt:
?>
Ersetzen Sie im Beispiel webX durch Ihre Webnummer (Benutzername) und passen Sie den Namen der Kopie der Konfigurationsdatei an.

Die Konfigurationsdatei wurde nun ausgelagert und ist ausserhalb des f�r den Browser sichtbaren Bereichs.

Hinweis:
Durch diese Methode kann die globale Konfiguration z.B. von Joomla sehr wahrscheinlich nicht mehr �ber das Administrationsinterface modifziert werden. Nehmen Sie �nderungen in der Konfiguration daher immer direkt in der Konfigurationsdatei vor.

osCommerce mit register_globals Off

Sat, 04 Feb 2012 08:00:00 GMT

Aus Sicherheitsgr�nden ist die PHP-Direktive register_globals ausgeschaltet. Damit osCommerce funktioniert, k�nnen Sie folgenden Patch installieren, der die Notwendigkeit von eingeschalteten globalen Variablen aufhebt:

http://www.oscommerce.com/community/contributions,2097

Hilfe bei 500 Fehler (Internal Server Error)

Sat, 04 Feb 2012 08:00:00 GMT

Wenn� bei Aufruf Ihrer Domain oder einer Unterseite ein 500-Fehler generiert wird, hat dies vermutlich eine der folgenden Ursachen:

ung�ltige .htaccess-Datei
Pr�fen Sie, ob Sie eine .htaccess-Datei verwenden, die ung�ltige oder nicht erlaubte Inhalte hat. Gewisse Optionen oder �berschreibungsfunktionen sind in .htaccess-Dateien nicht erlaubt. Kommentieren Sie ggf. probeweise einzelne Zeilen durch Voranstellen eines #-Zeichens aus
zu grossz�gig gesetzte Datei- und/oder Verzeichnisrechte
Wenn Ihr Web mit dem PHP-Wrapper suphp l�uft, geniessen Sie einen besonderen, zus�tzlichen Schutz Ihres Webs. PHP-Dateien werden hier nur ausgef�hrt, wenn Ihrem Web-Benutzer die auszuf�hrende PHP-Datei geh�rt und maximal die Standardrechte zugewiesen bekommen hat. �ber chmod oder WebFTP k�nnen Sie ggf. die Rechte bei Verzeichnissen auf 0755 und bei PHP-Dateien auf 0644 �ndern.
Viele Skriptl�sungen empfehlen, die Rechte auf 0777 zu setzen, was ein Schreiben, �ndern und L�schen von Daten von "jedermann" in Ihrem Web erm�glicht. Diese "Empfehlung" m�ssen Sie ignorieren, damit der 500-Fehler nicht auftritt.

Bei Fragen zu diesem Thema oder Bedarf an Hilfestellung steht Ihnen unser Support-Team gerne zur Verf�gung.

dynamic-net.ch AG News

PHP mit register_globals Off verwenden *UPDATE*

Berechtigung von Dateien nach PHP-Upload (chmod, umask, 600)

Perl: Sicheres Skripting mit perlsec

MySQL-Fehler: 1054 - Unknown column 'p.products_id' in 'on clause' (oder �hnlich)

Sensible Zugangsdaten in Perl- und PHP-Skripten sicher verwenden

osCommerce mit register_globals Off

Hilfe bei 500 Fehler (Internal Server Error)

PHP mit register_globals Off verwenden UPDATE