Seite 5 von 6

Verfasst: 14.10.2006 17:13
von IPB_Flüchtling
Danke für die Auskunft, larsneo!

Da ich auch bei folgendem Eintrag in die .htaccess einen 500er-Error erhalte, gehe ich davon aus, dass auch Folgendes in der .htaccess nicht möglich ist, was wiederum mgutt bei seiner Beispiel-htaccess berücksichtigen sollte:

Code: Alles auswählen

# forbid files without extensions
AcceptPathInfo off
LG, IPB_Flüchtling

Verfasst: 15.10.2006 12:37
von mgutt
larsneo hat geschrieben:
wie setzt man denn allow_url_fopen per .htaccess auf off?
leider gar nicht.
http://www.cms-sicherheit.de/module-blog-viewpub-tid-1-pid-2.html hat geschrieben:Die seit PHP 4.0.4 gesetzte Grundeinstellung allow_url_fopen=on ermöglicht in vielen schlecht geschriebenen Skripten die Einbindung von entferntem Programmcode. Seit PHP 4.3.4 ist diese Einstellung darüberhinaus leider auch PHP_INI_SYSTEM, was bedeutet, dass ein lokales Überschreiben via ini_set() nicht mehr möglich ist. Dies führt dazu, daß gerade im Shared Hosting die Anwender in aller Regel auf gute Progammierung vertrauen müssen, da viele Provider allow_url_fopen auf on gesetzt haben.
Das stimmt zwar, aber die Erklärung passt nicht. ini_set hat nur was mit Scripten zu tun. Also innerhalb von .php-Dateien. Aber es stimmt schon. Das ist eine Systemkonstante, die nur in der php.ini geändert werden kann.

Welche Befehle per .htaccess eingestellt werden können und welche nicht kann man hier nachlesen:
http://ch2.php.net/manual/de/ini.php#ini.list

Erklärung bei "allow_url_fopen" ist "PHP_INI_SYSTEM", also nur php.ini

Wobei "AcceptPathInfo" eine Core Einstellugn von Apache ist und auf den php-Seiten dazu keine Infos zu finden ist. Die findet man wiederrum hier:
http://httpd.apache.org/docs/2.0/mod/core.html

Um diese Einstellung wiederrum setzen zu können kann es je nach Servereinstellung nötig sein die allowoverride auf all zu setzen:
http://httpd.apache.org/docs/2.0/mod/co ... owoverride

Das kann aber nicht per .htaccess gesteuert werden :(

Ist also alles abhängig von den Servereinstellungen.

Gruß

Verfasst: 16.10.2006 00:16
von IPB_Flüchtling
Danke auch Dir für die Ausführungen, mgutt!

Ist schon ein spannendes Gebiet. Es gilt halt immer explizit darauf hinzuweisen, ob sich ein Sicherheitstipp auf den Admin eines Root-Servers oder auf jemanden, der (so wie ich) mit shared hosting sein Auslangen findet, bezieht.

Schönen Wochenanfang!
IPB_Flüchtling

Verfasst: 16.10.2006 01:10
von Dave
Wenn ich mich nicht irre kann man doch den allow_url_fopen einfach mit fsockopen umgehen? Weil der klappt trotz allow_url_fopen = Off bei mir. Also bringt das doch eigentlich 0 :roll:

Verfasst: 16.10.2006 08:52
von larsneo
dann zeig' mir mal eine remote code execution mit fsock_open :D

spass beiseite, es geht nicht darum, das generelle einbinden fremder inhalte zu unterbinden (ich möchte z.b. auch weiterhin rss-ticker verwenden), sondern lediglich darum, das risiko einer remote code injektion zu verringern. leider gottes sind in vielen aktuellen projekten unvaliderte include/include_once statements die in verbindung mit register_globals=on und allow_url_fopen=on nun einmal wirklich böse folgen haben können (gerade aktuell habe ich ein entsprechendes c99-site-defacement aufgrund einer lücke in jinzora auf dem tisch gehabt).

das problem ist aber zugegebenermassen, dass selbst bei allow_url_fopen=off nachwievor injektionen mittels php://input bzw. data:// urls möglich sind - und da hilft zumindestens aktuell afaik nur suhosin.

Verfasst: 16.10.2006 15:27
von Dave
Was ich mal überlegt habe ein Thema machen wo man die Mods aufzählt (Mit versionsnummer) in der eine Sicherheitslücke vorhanden ist. Aber da wird die liste wohl sicher seeeehr lange :roll:

Verfasst: 17.10.2006 17:31
von mgutt
Dave hat geschrieben:Was ich mal überlegt habe ein Thema machen wo man die Mods aufzählt (Mit versionsnummer) in der eine Sicherheitslücke vorhanden ist. Aber da wird die liste wohl sicher seeeehr lange :roll:
Das wäre deswegen quatsch, weil dann jeder Noob mit hacken anfängt. Es sollte keine Sícherheitslücken geben. Hast Du eine gefunden muss sie gemeldet und behoben werden. Nicht umsonst werden "offizielle" Mods aus der Datenbank geschmissen, wenn Sicherheitslücken gefunden werden.

Gruß

Verfasst: 17.10.2006 17:53
von Dave
Will ja keine Anleitung dafür machen ala der und der Mod hat die und die Sicherheitslücke ;)

Verfasst: 18.10.2006 12:50
von mgutt
Ich denke das Unterbinden des fehlerhaften Mods ist sinnvoller, als die Zeit dazu zu opfern eine Liste zu machen. Wer einen fehlerhaften Mod installiert hat, der hat eh schon verloren. Außer er macht eben ein Update.

Gruß

Verfasst: 18.10.2006 13:35
von cYbercOsmOnauT
Dave hat geschrieben:Was ich mal überlegt habe ein Thema machen wo man die Mods aufzählt (Mit versionsnummer) in der eine Sicherheitslücke vorhanden ist. Aber da wird die liste wohl sicher seeeehr lange :roll:
-> http://www.osvdb.org