Neuer Patch supee-6788 zum Anwenden von Patches

Nach wochenlangem Warten auf den Patch heute (27.10.2015) wurde er veröffentlicht: SUPEE-6788

Viele Dinge wurden gepatcht und es wird empfohlen, installierte Module auf mögliche Schwachstellen zu überprüfen.

Ich öffne diesen Beitrag, um einige Einblicke in die Anwendung des Patches zu erhalten. Was sind die Schritte, um den Patch anzuwenden? Nach meinem Verständnis sind dies die Schritte:

1. Korrigieren Sie Module mit Administratorfunktionen, die sich nicht unter der Administrator-URL befinden
2. Korrigieren Sie Module, die SQL-Anweisungen als Feldnamen oder Escape-Felder verwenden
3. Whitelist-Blöcke oder Direktiven, die Variablen wie {{config path=”web/unsecure/base_url”}}und verwenden{{bloc type=rss/order_new}}
4. Potenzielle Exploits mit dem Dateityp "Benutzerdefinierte Option" ansprechen (keine Ahnung, wie das geht)
5. Wenden Sie den Patch an

Ist das die richtige Vorgehensweise?

Im Allgemeinen können Sie den Patch wie alle vorherigen anwenden. Schauen Sie sich die offiziellen Unterlagen an und überprüfen Sie diesen SE-Beitrag . Aber ja, es gibt einige zusätzliche Punkte, die Sie überprüfen sollten, wenn Sie diesen Patch anwenden. Byte / Hypernode hat einen schönen Beitrag dazu.

1. Überprüfen Sie, ob Ihr Thema eine benutzerdefinierte template/customer/form/register.phtmloder benutzerdefinierte hat template/persistent/customer/form/register.phtml. Wenn dies der Fall ist, stellen Sie sicher, dass a form_key.
2. Überprüfen Sie, ob Ihr Thema eine benutzerdefinierte hat layout/customer.xml. Stellen Sie in diesem Fall sicher, dass Sie die erforderlichen Änderungen aus dem Patch ( customer_account_resetpasswordgeändert in customer_account_changeforgotten) übernehmen.
3. Verwenden Sie nicht standardmäßige Variablen in CMS-Seiten, statischen Blöcken oder E-Mail-Vorlagen? Stellen Sie dann sicher, dass Sie sie auf die Whitelist setzen. In dieser SE-Frage erfahren Sie, wie Sie Variablen / Blöcke auf die Positivliste setzen.
4. Führen Sie die cron.phpüber HTTP? Stellen Sie sicher, dass Sie besser verwenden cron.sh. Wenn dies nicht möglich ist, stellen Sie sicher, dass Sie cron.php über CLI PHP aufrufen. Wenn Sie aus irgendeinem Grund keinen richtigen Cronjob konfigurieren können und ihn über HTTP ausführen müssen, lesen Sie diese SE-Frage
5. Stellen Sie sicher, dass alle Ihre Erweiterungen das "neue" Admin-Routing verwenden. Sie können dieses n98-magerun- Plugin verwenden, um dies zu überprüfen. Sie können dieses CLI-Skript auch verwenden . Sie können sich auch diese verwandte SE-Frage ansehen .
   6. Wenn alle Ihre Erweiterungen das richtige Admin-Routing verwenden, müssen Sie unter System - Konfiguration - Admin - Sicherheit die Option "Kompatibilitätsmodus für Admin-Routing aktivieren" deaktivieren.
6. Wenn Sie M2ePro verwenden, aktualisieren Sie es auf die neueste Version, da alte Versionen mit dem neuen Patch nicht funktionieren.

Stellen Sie beim Aktualisieren sicher, dass Sie die Datei löschen dev/tests/functional/.htaccess. Es ist in Magento 1.9.2.2 nicht mehr vorhanden. Wenn Sie es behalten, sind Sie immer noch verwundbar.

Überprüfen Sie in jedem Fall Ihre Seite nach dem Update mit MageReport , um festzustellen , ob alles gut gelaufen ist .

Es gibt auch einen technischen Blogbeitrag von Piotr , der die kritischen Änderungen beschreibt.

Es gibt eine Überprüfungsdatei, mit deren Hilfe Sie Probleme identifizieren können: https://github.com/gaiterjones/magento-appsec-file-check

Ich habe ein CLI-Skript daraus gemacht. https://github.com/Schrank/magento-appsec-file-check

Stellen Sie für Nginx sicher, dass Sie den Zugriff auf cron.php und den dev-Ordner blockieren. Wir benutzen diesen Block:

location ~ ^/(app|includes|media/downloadable|pkginfo|report/config.xml|var|magmi|cron.php|dev)/? { deny all; }

Ich habe den Patch gerade auf meinen 1.10.1 EE angewendet und dies verursacht Nebenwirkungen auf nativen Bildschirmen, da der Core nicht APPSEC-1063-kompatibel ist:

Beispiel:

Im app/code/core/Mage/Customer/Model/Entity/Attribute/Collection.php

Sie finden 2 addFieldToFilterAnrufe, die nicht APPSEC-1063-konform sind.

Dies ist ein Verstoß gegen die Raster "Kunde"> "Attribut". Daher müssen Sie den Patch mit dem im PDF "SUPEE-6788-Technical% 20Details% 20.pdf" im Abschnitt "APPSEC-1063" empfohlenen Trick patchen

Ändern der mehreren

    $this->addFieldToFilter($field, 0);

(wobei das $ -Feld komplexe (CASE .. WHEN THEN ...) SQL-Anweisungen enthält)

in

    $resultCondition = $this->_getConditionSql($field, 0);
    $this->_select->where($resultCondition);

Sowohl die supee-6788-Toolbox von rhoerr als auch die gaiterjones haben diese Art von Problemen nicht erkannt. Ich habe alle anderen überprüft -> addFieldToFilter ($ und keine scheinen das Problem zu verursachen.

Andere betroffene 1.10-Kerndateien: (gefunden von Rhoerrs supee-6788-Toolbox)

app/code/core/Mage/Bundle/Model/Mysql4/Option/Collection.php 

Es kann mehr geben.