IIS | Ausführung von Dateien im Verzeichnis blockieren

IIS | Ausführung von Dateien im Verzeichnis blockieren

Ich beschäftige mich mit Benutzer-Uploads über eine PHP-Anwendung.

Ich möchte den Server sichern, sodass dem Benutzer keine Exploits zur Verfügung stehen, wie etwa das Hochladen und Ausführen einer PHP-Shell.

Ich habe es so eingestellt, dass alle Uploads außerhalb des Webroots in einen separaten Ordner verschoben werden. Als zusätzliche Sicherheit habe ich alle Rechte außer „Lesen“ aus dem IUSR für den bestimmten Ordner entfernt.

Um noch einen Schritt weiter zu gehen, wurde mir gesagt, ich solle die Skriptausführung für den Ordner über IIS deaktivieren.

Ist dies angesichts meiner Situation und der Dinge, die ich bereits getan habe, notwendig? Wenn ja, wie würde ich dies mit IIS 8 erreichen?

Danke

Antwort1

Die Antwort auf die Frage „Ist dies notwendig?“ lautet, dass wir das erforderliche Sicherheitsniveau für diese Anwendung und Ihre Organisation prüfen müssen.

Best Practices für die Sicherheit befürworten den Ansatz „Defense in Depth“, was bedeutet, dass Sicherheit aus mehreren Schichten von Sicherheitskontrollen besteht, um Informationen (oder andere) Vermögenswerte zu schützen.

Um zu bestimmen, ob diese Daten zusätzliche Kontrolle benötigen, bewerten Sie das Risiko – wie wahrscheinlich ist es, dass eine Bedrohung besteht, die ausgenutzt werden könnte, und welche Auswirkungen hat es, wenn diese Daten/dieses System kompromittiert werden? Denken Sie dabei nicht nur an die Vertraulichkeit der Daten, sondern auch daran, dass ein böswilliger Benutzer die Daten ändert, das System zum Absturz bringt oder die Daten löscht. Bestimmen Sie dann, ob die Kosten der Kontrolle den Nutzen der Implementierung der Kontrolle übersteigen. Wenn dies nicht der Fall ist, implementieren Sie die Kontrolle. Wenn die Implementierung der Kontrolle „teurer“ ist, akzeptieren Sie das Risiko.

Den Skriptzugriff auf ein virtuelles Verzeichnis zu verweigern, ist relativ einfach umzusetzen und wäre eine Verteidigungsebene gegen einen böswilligen Benutzer, der seine Berechtigungen erhöhen könnte. Es ist üblich, diese Kontrolle zu implementieren, damit in ein Verzeichnis hochgeladene Dateien nicht ausgeführt werden können – beispielsweise um eine Remote-Shell zu erhalten. Wenn also die „Kosten“ gering sind und wir davon ausgehen, dass der Erhalt einer Remote-Shell große Auswirkungen hätte, selbst wenn die Wahrscheinlichkeit gering ist, dann wäre die Antwort, die Skriptausführung für den Ordner zu deaktivieren (wenn Sie mit dieser Einschätzung nicht einverstanden sind, können Sie sich hier gerne Ihre eigene Meinung bilden).

Um den Skriptzugriff auf den Ordner in IIS 8 zu deaktivieren, sollten Sie wie bei IIS 7 vorgehen und Handlerzuordnungen in der Datei web.config konfigurieren.

Unter diesem Link werden die verschiedenen Optionen erläutert:

https://webmasters.stackexchange.com/questions/28733/prevent-iis-from-executing-scripts-in-a-specific-directory

Dies ist wahrscheinlich, was Sie wollen, wodurch der statische Dateihandler erhalten bleibt:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <clear />
            <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
        </handlers>
    </system.webServer>
</configuration>

Beachten Sie auch den letzten Kommentar auf dieser Seite zur erforderlichen Konfiguration:

Ich möchte die gepostete Lösung für andere ergänzen, die möglicherweise auf dasselbe Problem stoßen: Keine davon hat bei mir funktioniert, bis ich herausgefunden habe, dass die Handler auf der obersten Ebene gesperrt waren. Ich bin kein Serveradministrator und auch nicht annähernd so etwas, also hat das eine Weile gedauert. Bis die Datei applicationHost.config bearbeitet wurde, um Überschreibungen zuzulassen, reichte es aus, sogar einen leeren Abschnitt in einer web.config-Datei auf niedrigerer Ebene einzufügen, um alles von dieser Ebene abwärts zu zerstören. Funktioniert jetzt aber einwandfrei.

verwandte Informationen