Nginx - Sicherheitsprobleme und Bugs im JTL-Shop (ger)

2017-08-31

Ein immer wieder heiß diskutiertes Thema ist die Frage “Nginx oder Apache?”. Hierbei werden leider oft die Aspekte “Sicherheit” und “Bug-Resistenz” außen vor gelassen.

Hinweis: Dieser Blog-Eintrag bezieht sich auf den JTL-Shop. Die Problematik betrifft allerdings auch andere Software. Ob das Problem vorhanden ist, hängt unter Anderem davon ab, ob der Software-Root gleich dem Web-Root ist.

Performance

Ohne Zweifel ist Nginx der schnellere Webserver und in manchen Fällen kann der Einsatz durchaus Sinn machen. Wenn man einen Proxy-Server braucht oder höchste Anforderungen an die Performance hat, kann es sinnvoll sein, auf Nginx zu wechseln.

Trotzdem! Nginx wird oftmals eingesetzt, obwohl hierfür keine Notwendigkeit besteht. Bei manchen JTL-Shop-Hostings wird Nginx sogar standardmäßig eingesetzt. Meistens läuft es auf folgende Begründungen hinaus:

Nginx kann statische Inhalte viel schneller ausliefern !!!

Wenn die Auslieferung von statischen Inhalten tatsächlich zu langsam ist, empfehle ich eher den Einsatz eines CDN wie Cloudflare. Dies ist nochmal deutlich schneller, als Nginx einzusetzen.

Nginx kann viel mehr Anfragen schneller verarbeiten !!!

Klar, aber braucht man das wirklich? Ich habe keine JTL-Shop-Installation gesehen, bei der Optimierungen am LAMP-Stack oder dem JTL-Shop nicht ausgereicht hätten, um hervorragende Ergebnisse zu erziehlen.

Doch wo liegt eigentlich das Problem?

Das Hauptproblem liegt darin, dass JTL und die meisten Plugin-Hersteller im JTL-Umfeld .htaccess-Dateien nutzen, um Anweisungen für den Server niederzulegen. Diese Dateien werden allerdings nur von Apache gelesen. Nginx kann mit .htaccess-Dateien nicht umgehen und interpretiert die hinterlegten Anweisungen nicht. Zwar werden die Anweisungen oft initial von Dienstleistern oder Administratoren in die Nginx-Konfiguration übernommen, oft passieren hierbei allerdings Fehler oder Änderungen aus Updates werden später nicht mehr übernommen.

Das kann verheerende Folgen für die Sicherheit haben oder Bugs hervor rufen, wenn Plugin-Hersteller und Administratoren nicht aufpassen. Zum Beispiel nutzen manche Plugins einen schreibbaren Ordner im Plugin-Verzeichnis:

rwx /includes/plugins/gefährdetes_plugin/export

Dieser Ordner beinhaltet in Version 1 nur öffentlich lesbare Dateien. Hierfür legt der Plugin-Hersteller eine .htaccess-Datei in dem Verzeichnis an:


<FilesMatch "*">
    <IfModule mod_authz_core.c>
        Require all granted
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order Deny,Allow
        Allow from all
    </IfModule>
</FilesMatch>

Damit der Ordner auch unter Nginx erreichbar ist, muss nun diese Konfiguration ebenfalls in der Nginx-Konfiguration übernommen werden. Dies wurde vom Administrator ordnungsgemäß getan:


location ~ ^/includes/plugins/gefährdetes_plugin/export {
    try_files $uri $uri/;
    allow all;
}

In Version 2 vom Plugin müssen nun sensible Dateien exportiert werden, die nicht extern abgerufen werden dürfen. Da der Ordner bereits Schreibrechte hat, haben sich die Programmierer(innen) dazu entschieden, den Ordner als Unterordner zu dem bereits existierenden anzulegen. In diesem Unterordner wurden die Zugriffsrechte wieder eingeschränkt:


<FilesMatch "*">
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order Deny,Allow
        Deny from all
    </IfModule>
</FilesMatch>

Leider wurde diese neue .htaccess-Datei nicht vom Administrator berücksichtigt. Die Anweisungen aus der .htaccess-Datei wurden nicht in die Nginx-Konfiguration übernommen. Daher ist nun der Unter-Ordner öffentlich erreichbar, obwohl dies vom Plugin-Hersteller so nicht vorgesehen ist.

Diverse Bugs möglich

Abgesehen von den Sicherheits-Problemen, die durch Nginx auftreten können, sind natürlich auch Bugs vor programmiert. Ich habe bereits einige Male solche Probleme bei Kunden bereinigen dürfen. Auch hört man immer mal wieder von Problemen mit den Cache-Einstellungen oder dem Bilder-Mechanismus bei JTL.

Welche Alternativen existieren?

Wenn man die Performance eines JTL-Shops verbessern möchte, existieren diverse andere Möglichkeiten. Hier nur ein paar Stichwörter. Vielleicht schreibe ich in Zukunft mal zu den einzelnen Möglichkeiten detaillierte Blog-Einträge.

  • CDN oder http2 oder mod_pagespeed
  • redis / memcached für Object-Cache und Sessions
  • Webshop-Einstellungen prüfen
  • Unnötige Plugins deaktivieren
  • Apache Optimierungen
  • MySQL Optimierungen / Query Optimierungen
  • Aktuelle PHP-Version
  • JTL-Shop Session Verhalten
  • Serverskalierung
  • Vieles, vieles mehr…

Fazit

Die Nutzung von Nginx für den JTL-Shop kann die Performance verbessern, allerdings übersteigen meiner Meinung nach die Risiken den Nutzen. Es gibt bessere Möglichkeiten, die Geschwindigkeit eines JTL-Shops zu verbessern.

Back to Posts