RewriteRule in htaccess verhindert das Anlegen von Bildern über Styles

Ich habe da leider keine Lösung für Dich.
Aber würde mich interessieren, welcher Hoster das ist?

Insgesamt hört sich das für mich alles etwas seltsam an. Der Anbieter hat von einem Kunden einen Tipp hinsichtlich einer Sicherheitslücke bekommen und verbietet daraufhin SetHandler in htaccess files und erklärt Drupal zur "unnormalen" Web-Anwendung und empfiehlt seinen Kunden (die vermutlich Hoster sind) von Drupal generierte Dateien anzupassen und das vermutlich potentiell ohne dass der einzelne Kunde des Hosters davon weiß. Hm, der Ansatz ist spannend. Was passiert denn wenn Kunden Drupal neu installieren? Wacht der Hoster dann ständig über alle Files auf dem Server? Und wenn man der Überzeugung ist dass solche weitverbreiteten Produkte wie Apache und Drupal so enormen "Unsinn" verzapfen, dass man solche Klimmzüge machen muss, dann sollte man sich vermutlich mal an die Communities der Produkte wenden und dort darauf aufmerksam machen.

Im übrigen stellt ein User fest, dass Neos offenbar auch von dem Problem betroffen ist. Das zur der Aussage das Drupal das einzige betroffene System ist ...

Wenn der Anbieter das wirklich so durchziehen will, ist ein Hoster der diese Software verwendet vermutlich kein geeigneter Drupal-Hoster mehr ...

Konkret zu Deinem Problem. Ich würde mal versuchen die beiden SetHandler Anweisungen auszukommentieren und dann schauen was passiert. Es sollte eigentlich alles wie gehabt funktionieren. Wenn Du dann die vom Anbieter empfohlene Zeile einfügst und es dann nicht mehr funktioniert, dann solltest Du Dich mit dieser Info an den Anbieter wenden.

Und ich empfehle nicht generell die SetHandler-Anweisungen aus der .htaccess zu entfernen und Drupal live so zu betreiben. Das würde ich nur in diesem speziellen Fall zum Debugging temporär so machen, bis zumindest eine gleichwertige Lösung gefunden ist.

Also um mal das Problem zu lösen

Ich habe mir gerade die aktuelle.htaccess der letzten Drupal 7 version angesehen und darin kann ich die von deinem Provider, der übrigens keine Ahnung hat, was er da eigentlich schreibt, bemängelte Zeile nicht ausmachen.

http://cgit.drupalcode.org/drupal/tree/.htaccess?h=7.x&id=600c1346ed976e...

Wenn ich nicht völlig blind bin, jedenfalls.

Solltest du diese Zeile dort also auch nicht finden, reicht es vielleicht schon den Core zu aktualisieren oder testhalber einfach die .htaccess vom Chor repo einzuspielen um zu sehen, ob's hilft.

Der Befehl "SetHandler" liegt in der .htaccess unter sites/default/files

Grüße Jenna

Liebe Kollegen,
Vielen Dank für Eure Rückmeldungen. Ich war jetzt über ein langes Wochenende weg, daher meine verspätete Antwort. Aber nun meine Erklärungen bzw. Erkenntnisse.
Erklärung:
Unser Server wird von unserem Provider mit Liveconfig verwaltet bzw. konfiguriert. Dass nun die neueste Version von liveconfig den Befehl sethandler nicht mehr unterstützt nehme ich einfach so hin, da kann ich auch nichts daran ändern.Und da kann mein Provider auch nichts dafür, der kann das auch nur zur Kenntnis nehmen.

Meine Erkenntnisse sind nun folgende:
Der SetHandlerbefehl hat in .htaccess unter sites/default/files hat anscheinend einen handler eingebunden, den es garnicht gibt. Sobald ein Script im files-Folder aufgerufen wurde, wurde dieser Handler aufgerufen, und da es ihn nicht gibt, bricht die Scriptausführung ab.
Der Vorschlag von den liveconfig-Entwicklern sieht so aus, dass eine Rule eingebunden wird, die die Ausführung von allen Scripten verhindert.

RewriteEngine On
RewriteRule .+\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]

Der F-Flag bedeutet Forbidden, er gibt den Usern einen 403 Error zurück und das wars. Leider werden eben auch Scripten geblockt, die mit den Bilder Aktionen ausführen wollen, wie zum Beispiel das Anlegen einer Bildvariante (Thumbnail) etc. Diese Scripten liegen nicht im files-Verzeichnis, greifen aber darauf zu. Tja, und da ich mich mit htaccess nicht so toll auskenne, frage ich mich, ob es nicht eine Möglichkeit gibt, nur Scripten zu blocken, die tatsächlich im files-folder liegen.
Weiß einer von Euch darüber Bescheid?
Ich werde jedenfalls bei den Entwicklern von liveconfig noch anfragen, welchen Vorschlag sie haben. :-)
Vielen Dank

Wolfgang

Hallo Wolfgang

Grundsätzlich würde ich sagen, wenn ihr das Verzeichnis und die Dateien mit den Rechten 775 ausstattet ist alles gut.

Um ein Skript auszuführen muss das ja erstmal auf eine Datei zugreifen. Bei den Rechten 777 kann ich das auch von außen tun. Das ist sinnvoll, wenn ich Bilder durch einen externen Dienstleister von aussen direkt auf der Platte nachbearbeiten lassen will.

In der Regel machen das aber immer entweder der angemeldete Nutzer oder eben die Gruppe des Webservers.

Sind die Rechte richtig gesetzt, kann auch keiner so einfach Schadcode einschleusen. Das ist ja genau der Fall, den der SetHeandler abdecken soll und zwar auch dann, wenn hier die Rechte mit 777 gesetzt sind.

Setzt ihr jetzt chmod -R 775 geht von aussen nur noch lesen, aber eben nicht schreiben.

Problem gelöst. Auch ohne die Direktive.

Ich habe nun Hilfe von den Entwicklern von Liveconfig bekommen:

Die neue Rewrite-Rule in sites/default/files/.htaccess verhindert, dass Scripten in diesem Verzeichnisbaum ausgeführt werden. Gleichzeitig setzt sie alle Rules aus der .htaccess-Datei im Webroot außer Kraft.
Damit werden auch Aufrufe von nicht existierenden Dateien nicht mehr über die /index.php geschleust, und das war der Grund für das fehlerhafte Verhalten.
Nun habe ich in die .htaccess unter "sites/default/files" eine Rule eingefügt, die für diesen Verzeichnisbaum diese Aufgabe übernimmt:
RewriteRule ^ /index.php [L]
Jetzt funktioniert alles so, wie es soll!
Viele Grüße und Vielen Dank, auch und besonders an die Entwickler von LiveConfig :-)

Wolfgang