Sicherheitspatch SUPEE-6285 Nebenwirkungen

supee-6285

Der Shoplift-Bug hat Wirkung gezeigt. Magento scheint nun Sicherheitsproblemen mehr Beachtung zu schenken und häufiger Patches bereitzustellen.
Das ist auch gut soweit. Wie immer kam die Patch-Meldung in einer für deutsche Verhältnisse ungünstigen Zeit gegen 19 Uhr Abends.
Das heisst für Entwickler die Agenturen tätig sind immer, dass am nächsten Tag entsprechend alle Kundensysteme mit einem Patch zeitnah versorgt werden müssen (Kunden mit Supportvertrag natürlich bevorzugt).

Das eine oder andere mal (je nach Größe des Patches) kann das auch zu Problemen in Kundensystemen führen.
Wenn der Shopbetrieb nicht direkt betrofffen ist, dann finde ich sollte aber der Sicherheitsaspekt im Vordergrund stehen und zuerst der Patch ausgerollt werden und im Nachgang die Krankheiten die der Patch für das Systme mirbringt behoben werden.

Was gibt es bei dem Patch SUPEE-6285 zu beachten?

Admin-Controller

Controller Actions werden nun case-sensitive geprüft.
Im Bereich der Adminhtml-Controller wurde an vielen Stellen die _isAllowed methode eingeführt die für die Prüfung der Berechtigungen zuständig ist.

Interessant ist auch die diese Änderung:

Was bedeutet das? Wenn ihr vorher keine Berechtigungen explizit definiert hattet, konnte jeder angemeldete Benutzer im Adminbereich euren Controller nutzen.
Das ist natürlich eine nicht besonders defensive Voreinstellung von Magento gewesen die nun angepasst wurde.
Ab sofort sind Controlle ohne eigenen _isAllowed Methode nur noch von Benutzern mit Admin-Rechten aufrufbar.
Das finde ich soweit korrekt. Die Logik ist auch schon seit einer Weile in der Entwicklungsversion von Magento 2 so enthalten.

Wenn ihr also einen 404 Fehler im Adminbereich für bestimmte Bereiche bekommt, sollte man sich den entsprechenden Controller vornehmen und prüfen ob die _isAllowed Methode fehlt und am besten eine eigenen ACL-Resource definieren die dann im Controller geprüft wird.
Danach müssen alle Rollen die Zugriff auf die Resource erhalten sollen entsprechend über die Berechtigungsverwaltung anzupassen (Häckchen setzen).

Frontend Templates

Dazu schaut man sich am besten geänderte Dateien an. So wurden z.B. Frontend Templates überarbeitet da dort nicht immer ordentlich „escaped“ wurde.

Betroffen sind die folgenden Dateien:

Verzeichnisrechte

Beim der Anlage der Log-Verzeichnisse „var/log“ und „var/reports“ sind die Default-Berechtigungen nun nicht mehr „777“ sondern „775“.
Ebenso wurden ein paar .htaccess Dateien für den Apache-Webserver nachgezogen. Diese Konfiugrationen greifen z.B. bei Nginx nicht dort über eine entsprechende Einstellung berücksichtig werden.
Das betrifft auch Apache-Server die keine .htaccess Dateien verarbeiten.

Downloader

Der Downloader wurde auch an ein paar Stellen angepasst.
Ich empfehle den Downloader aus jeder Produktivumgebung zu entfernen da es keinen Grund gibt in einem Produktivsystem, dass z.B. automatisch deployed wird, mit einer Möglichkeit der manuellen Modulinstallation auszustatten.

Problem bekommt ihr dann allerdings beim Einspielen des Patches der sogar einen bereits über einen vorherigen Patch veränderten Downloader erwartet.
Wir haben in diesme Fall einfach die Patch „.sh“ Datei angepasst und alle Downloader-Relevanten Zeilen entfernt.

Fazit

Wir sehen also, dass es doch einiges beim Einspielen von Sicherheitspatches zu beachten gilt.
Einfach nur Installieren und gut ist…. gibt es nicht.
Kunden sollten sich also auch nicht wundern, wenn eben nicht nur 10 Minuten in der Rechnung stehen werden.

One Pingback/Trackback

    28 July 2015 at 6:07pm
    […] das Sicherheitslücken in Magento stopft. Phillip Jackson erläuterte, was die ...
  • Magento-Neuigkeiten #42