Beiträge von WolfgangS

Unser liveconfig ist nun upgedatet. Leider habe ich noch eine Drupal 6 Webseite laufen, und da funktioniert die Lösung nicht. Es werden die Bilder nicht angelegt, obwohl nicht vorhandene Dateien an die index.php weitergeleitet werden. Da es mir nicht möglich ist, die Programmierung von Drupal nach zu vollziehen, habe ich folgende Lösung gefunden:
in der sites/default/files/.htaccess wird mit einem filesmatch abgefragt, ob eine Scriptdatei aufgerufen wurde. Nur dann wird die rewriterule gestartet:

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

Meine Tests sind positiv verlaufen, wenn ich eine php-Datei in das files-Verzeichnis gelegt habe, wurde diese blockiert. Wenn andere Dateien aufgerufen werden, so kommt die Regel nicht zu Anwendung, und die Rewriterule aus der htaccess-Datei im Root-Verzeichnis greift.
Ist die Lösung Ihrer Meinung nach valide?
Danke
Wolfgang

Vielen Dank für die Hilfe. Ich wäre nicht drauf gekommen, da ich mich zu wenig mit rewrite-Rules auskenne!
Viele Grüße
Wolfgang

Vielen Dank für Ihre Antwort. Ich habe jetzt ausgiebig mit verschiedenen Einstellungen getestet. Eine test.txt unter "sites/default/files" konnte ich über den Browser lesen, ohne Fehlermeldung. Eine test.php wurde mit einem Fehler 403 abgewiesen. Ein selbst geschriebenes php-Script konnte aus dem Webroot heraus problemlos eine Kopie einer Jpeg-Datei, die im files-Verzeichnis liegt, anlegen.
Auf den ersten Blick sollte alles richtig sein, trotzdem geht der upload nicht korrekt.
Ich habe jetzt gesehen, dass das Bild in einer Variante tatsächlich hochgeladen wird, aber alle anderen Varianten wie Thumbnails etc. eben nicht angelegt werden.
In der access-log steht lediglich, dass auf die Thumbnail-Datei nicht zugegriffen werden kann. Das ist klar, sie ist ja auch nicht angelegt.
In der Error Log konnte ich einen Fehler produzieren: pipe broken.
mod_fcgid: ap_pass_brigade failed in handle_request_ipc function
Allerdings scheint das lediglich ein Hinweis darauf zu sein, dass der Server und der Client nicht mehr miteinander kommuniziert haben.

Ich habe jetzt eine meiner Webseiten local in einer Virtualbox-Ubuntu 18.04 Installation angelegt. Sie läuft unter php 7.2, mit Drupal 7.61
Ich habe allen Ordnern und Dateien als owner und group "www-data" zugeordnet, und dazu für alle Ordern und Dateien 777 angelegt. Trotzdem kommt immer noch der Fehler.
Ich habe noch die htaccess im Webroot durch die Standard-htaccess ersetzt, auch das ändert nichts an dem Fehler.
Sobald ich aber die Rewrite-Rule auskommentiere, und den alten SetHandler Befehl wieder aktiviere, geht wieder alles so wie es soll.
Bin für jeden Tip dankbar

Wolfgang

Hallo Liveconfig,
ich habe nun auf meinen Drupal-Webseite die htaccess-Einträge im sites/default/files Ordner angepasst, und die Rule eingebaut, die Ihr als Ersatz für den SetHandler-Befehl vorgeschlagen habt.

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

Leider hat der eine sehr negative Auswirkung:
Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt, andere Versionen in 250 x 250 Pixel, je nach Definition durch den Programmierer, der die Webseite angelegt hat. Die Rule verhindert das Anlegen dieser Styles, die redaktionelle Tätigkeit auf den Webseiten wird komplett lahmgelegt. Meine Frage: gibt es eine alternative Rule, die zwar Scripten stoppt, die im Files-Folder liegen, aber andere Scripten zulässt? Habt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
Danke und Viele Grüße
Wolfgang