Bilder mittels IMCE und FCKeditor in Textfelder einbinden

Inzwischen habe ich festgestellt, dass die hochgeladenen Bilder im Ordner /files sich überhaupt nicht abrufen lassen. Mit keinem Browser....

Meine Suche hat dann im Ordner /files eine .htaccess-Datei entdeckt, in der steht

"SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks".

Wenn ich die Datei lösche, lässt sich der Inhalt von /files problemlos abrufen. Ich dachte schon, das wär es. Aber nun die schlechte Nachricht: Drupal legt automatisch eine neue .htaccess an!!!

Was soll ich machen? Kann man den Inhalt dieser Datei irgendwie verändern, so dass die dort liegenden Bilder auch abgerufen werden können?

Gruß
tom

Hab das Problem gelöst:
Nachdem ich die Inhalte der .htaccess-Datei komplett gelöscht habe, funktioniert nun der Zugriff auf die Bilder ohne Probleme.

Das Einzige, was mich nachdenklich macht, ist die Tatsache, dass die .htaccess-Datei ja wohl nicht ohne Sinn existierte... Habe ich jetzt ein Sicherheitsproblem???

tom

Hallo,
habe das gleiche Problem. Lösung funktioniert, aber soll das so sein? Wie macht ihr das denn?
Gruß
Karsten

Naja, wir haben einfach das Problem nicht :)) Vielleicht aufgrund von Unterschieden bei den Dateiberechtigungen.

Mich würde sehr interessieren, wie die Unix-Dateiberechtigungen (manchmal auch als "Dateiattribute" übersetzt) in Eurem files-Verzeichnis aussehen, könntet Ihr die bitte mal inklusive Besitzer- und Gruppenzugehörigkeit der Dateien posten? Interessant wäre dabei eine Mischung von Dateien, die einerseits via Drupal hochgeladen wurde und andererseits via FTP-Client.

Mir ist die Sache nicht ganz klar. Es scheint eine böse Sicherheitslücke im Zusammenhang mit (älteren?) Apache-Standardkonfigurationen zu geben, und zwar insbesondere mit der Drupal 4.x-Linie. Warum die .htaccess heute noch so rabiat geschrieben wird, habe ich noch nicht herausgefunden, aber ich vermute, dass die Sicherheitslücke theoretisch auch mit aktuellen und auf bestimmte Weise konfigurierten Apaches noch auftreten kann. Zumindest image_cache soll sogar seinen Dienst versagen, wenn die .htaccess nicht genau so wie von Drupal geschrieben im files-Ordner thront.

Die Sicherheitlücke wird als höchst kritisch beschrieben: hochgeladene Dateien, die auf eine bestimmte Weise benannt werden, sollen so ausführbar sein! Das würde ich gern genau verstehen, aber die Drupal-security-Pages sind da auf bestimmte Weise wage ;-)

Vielleicht verstehts ja mal einer und erklärt es mir, der hier vorbeikommt.

OK - ein bisschen schwierig, das herauszukriegen, aber jetzt ist zur Hälfte klar, wie das läuft. Also an alle, die die .htaccess in der oben beschriebenen Weise geleert haben: bitte erstellt doch einmal eine Datei namens phpinfo.php.1 (ja genau: phpinfo Punkt php Punkt eins) folgenden Inhalts:

Das "Punkt eins" am Dateiende, weil Drupal so "schlau" ist, hochgeladene ".php"-Dateien als ".php.txt" abzulegen. Textdateien werden natürlich nicht ausgeführt. Aber weiter: diese so benannte Datei dann via Upload als Anhang zu einem Node hochladen und letzteren abspeichern. Und schliesslich den URL "http://www.example.com/files/phpinfo.php.1" bzw. "http://www.example.com/sites/default/files/phpinfo.php.1" im Browser ausführen (je nach Location Eures files-Ordners). Wenn dann ganz brav die blau-weiss-beliebte Ausgabe der phpinfo() zu sehen ist, dann wird einem klar, warum das ein Sicherheitsrisiko höchster Alarmstufe ist, sofern registrierten Usern Uploads gestattet sind. Jeder User mit Upload-Rechten kann beliebigen PHP-Code auf dem Server ausführen!

Hintergrund ist, dass der Apache Dateien als php-Dateien ausführt, wenn im URL ".php" vorkommt, nicht etwa nur, wenn er mit ihm endet. Das ist ein brisantes Thema, überall in Foren sehe ich den "heissen" Tipp mit dem Leeren der .htaccess bei Anzeigeproblemen - ein ziemlich riskanter Tipp.

Wenn CGI/SSI für Eure Site enabled ist, funktioniert das übrigens auch mit .shtml-, .pl-, .py- .cgi-Dateien! In Summe nicht sehr amüsant. Und genau aus diesem Grunde insistiert Drupal Core auf der .htaccess und legt sie beinhart wieder an, wenn sie gelöscht worden sein sollte.

Doch warum genau diese 3 Zeilen der .htaccess einen Angriff dieser Form verhindern, das wüsste ich noch gern. Auch warum das files-Anzeigeproblem nur einige wenige haben, die anderen aber nicht.
Eine Vermutung zur Funktionsweise ist, dass die SetHandler-Zeile ein Unset auf nachzuladende Skriptinterpreter macht. Warum das aber das Anzeigen von Grafiken unter bestimmten (mir leider unbekannten Bedingungen) verhindern soll? Wer hilft mir auf die Sprünge? Dann kann Schneekoenig und anderen geholfen werden.

Das meiste hast du ja schon fleißig recherchiert, während ich mich im Studio gequält habe ;)

Dann mal von meiner Seite aus der Rest zur Lösung des Rätsels:

Die erste Zeile weist Apache an für alle Dateien im Verzeichnis und allen Unterverzeichnissen den angegebenen Handler zu benutzen. Ein Handler namens Drupal_Security_Do_Not_Remove_See_SA_2006_006 ist natürlich nirgends definiert, daher benutzt Apache stattdessen den Standard-Handler und schickt die Dateien als statische Dateien raus (anstatt die übergeordnete A, wenn sie angefordert werden. Durch das explizite Setzen dieses Handlers werden evtl. bereits gesetzte Handler für dieses Verzeichnis und alle Unterverzeichnisse überschrieben. Standardmäßig erbt das files-Verzeichnis "von oben" ja sonst einen Handler, der in der Apache-Konfiguration mit Zeilen wie "AddHandler application/x-httpd-php5 .php" gesetzt wird.

Die beiden darauf folgenden Zeilen dienen lediglich noch dazu, evtl. Optionen (die automatisch aus der Konfiguration des Elternordners übernommen werden) komplett zu resetten (alle Optionen sind deaktiviert), um im Anschluss explizit zu erlauben, dass symbolischen Links (kleine Spezialität von Unix-Dateisystemen ;-) ) gefolgt wird.

Was das ab und an auftretende Problem mit der Bilderanzeige angeht, müsste man mal die komplette Serverkonfig durchforsten. Vermutlich ist irgendwo was hartverdrahtet, dass die Bilder mit falschem oder fehlendem Header ausliefert, wenn der Handler genullt wird.

--
"Look, Ma, I'm dead!"
Cell, Stephen King