CSRF Attack & Session Hijack Schwachstelle

Question

Aus den 1.8CE Alpha -Versionsnotizen:

Der Magento Web Store verfügt über einen zusätzlichen Schutz für CSRF (Cross Site Request Forgery Forgery), was bedeutet, dass ein Betrüger nicht mehr als neu registrierter Kunde geeignet ist und im Namen des Kunden Maßnahmen ausführen kann.

und:

In früheren Versionen war Magento während des Registrierungsprozesses für einen Sitzungsfixierungsangriff anfällig. Nachdem sich die Sitzungs -ID eines registrierten Benutzers an ihrem Konto angemeldet hatte, änderte sich nicht. Wenn ein Angreifer Kenntnisse über eine nicht autorisierte Sitzungs -ID hatte und dieser Benutzer erfolgreich registriert, konnte der Angreifer das neu registrierte Konto übernehmen. Jetzt ändert sich die Sitzungs -ID nach erfolgreicher Registrierung, wodurch die Verwendung eines Kontos nicht autorisiert wird.

Wenn dies in den Release -Notizen liegt und ich keine Punktveröffentlichung bei früheren Versionen sehe, die sich mit dieser befindet (schaue ich an der falschen Stelle?) - bedeutet das dann das Aktuelle Vorlagen vor 1.8 sind möglicherweise offen für diese Angriffsvektoren?

Quelle: http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes

Answer 1

Kurz gesagt, ja. CE 1.7 ist immer noch anfällig für diese spezifischen Angriffe, da keine Sicherheitsveröffentlichung ausgestellt wurde, die einen Patch enthält.

Bei letzterem, einem Sitzungsangriff für Sitzungen, ist die Änderung ein Upgrade in den Sicherheitspraktiken, mit denen Magento bereits mit den aktuellen Best-Practices der Sicherheits-Bestätigung in Einklang gebracht wurde. Es ist wahrscheinlich, dass Ce 1.7 wahrscheinlich etwas ausgestellt wird, wenn sie einen Patch mit den CSRF -Korrekturen ausgeben.

Die eigentliche Frage ist, was genau diese CSRF -Schwachstellen waren, die festgelegt wurden. Zweifellos eine gute Sache, die sie nicht in den Versionshinweisen aufgenommen haben, um alle früheren Veröffentlichungen weiter zu gefährden, aber es wäre schön, um alte Implementierungen zu patchen.

Update Nr. 1:Als ich mich an Magento wandte, um herauszufinden, wann sie Patches für die oben genannten Schwachstellen herausgeben, erhielt ich die folgende Antwort:

Erlauben Sie mir etwas Zeit, dies weiter zu recherchieren. Ich bin mir nicht sicher, ob für diese beiden Elemente Patches verfügbar sind, da sie in unserem System als Produktverbesserungen und nicht als Fehler aufgeführt sind. Ich werde Sie aktualisieren, wenn ich weitere Informationen bekomme.

Ich werde hier weitere Details zurückposten, sobald ich sie bekomme, und werde mein Bestes geben, um Patches auszustellen, da es anscheinend keine Patches gibt.

Update Nr. 2: Nach dem Hin- und Her mit dem Support -Team konnte ich ein ordnungsgemäßes Patch für Magento EE 1.12.0.2 erhalten. Für Magento CE 1.7.0.2 wurde kein Patch ausgestellt, und was der Techniker, der es intern für mich untersucht hat, weiß, gibt es keine Pläne, einen offiziellen Patch für CE 1.7.x zu veröffentlichen, sondern die Probleme nur im kommenden CE 1.8 zu lösen stabile Version.

Was die ee -spezifische Patch -Datei betrifft, kann ich sie hier (oder das Patch -Anwendungstool) hier nicht direkt veröffentlichen, da sie zweifellos gegen die NDA zwischen Magento und mir persönlich und dem Unternehmen, für das ich arbeite, gegen die NDA verstoßen. Der Name des relevanten Patchs lautet: "patch_supee-1513_ee_1.12.0.2_v1.sh"-Wenn Sie die Enterprise-Edition oder einen Client verwenden, sollten Sie diesen Patch aus dem Magento Support-Team zusammen mit einem Hinweis über Anfrage anfordern können Die CSRF -Schwachstellen, die es beheben soll.

Für CE 1.7.0.2 -Benutzer habe ich die Freiheit genutzt, eine Patch -Datei (basierend auf dem von Magento bereitgestellten Patch) zu generieren, das nur die Codehänge enthält, die Magento CE 1.7.0.2 CORE -Codedateien ändern. Normalerweise enthält es irrelevante Teile von zusätzlichen Kommentaren und angepasste Formatierung sowie die entsprechenden Codeänderungen. Das Erstellen dieses Erstellens des ursprünglichen Patchs erfordert manuell, um es mit dem bereitgestellten Patch -Anwendungswerkzeug anzuwenden, und verwenden Sie dann GIT, um einen Patch basierend auf den angewendeten Änderungen zu generieren.

Die Patch -Datei, die ich erstellt habe, kann von diesem GIST heruntergeladen werden: https://gist.github.com/davidalger/5938568

Um den Patch anzuwenden, wird die erste CD in das Root Ihrer Magento -Installation angewendet und führen Sie den folgenden Befehl aus: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

Das EE -spezifische Patch enthielt die Validierungsprüfungen für Formularschlüssel für Unternehmenspezifische Controller, Änderungen an Unternehmen/Standard- und Enterprise/iPhone -Vorlagendateien, die Formularschlüssel in den Formularen für die gepatcherten Controller -Aktionen sowie zusätzliche Vollbild -Cache -Funktionen einbeziehen können, um ordnungsgemäß zu berücksichtigen Getasten des Formulars auf zwischengespeicherten Seiten hin und her.

HAFTUNGSAUSSCHLUSS: Ich habe weder den von Magento bereitgestellten EE -Patch getestet, noch den Patch, den ich in das verknüpfte Kern hochgeladen habe. Der in der verwiesene GIST bereitgestellte Patch erhält keine Garantie und kann die in den CE 1.8 -Versionshinweise verwiesenen Schwachstellen, die in CE 1.8 verwiesen werden, vollständig beheben oder nicht. Als ungetestete Patch gibt es auch keine Garantie dafür, dass es ganz oder teilweise funktioniert. IE nutzen Sie auf eigenes Risiko und nehmen Sie die Sorgfalt, um vor dem Einsatz in einer Produktionsumgebung zu testen. Wenn Sie Probleme mit dem Patch finden, lassen Sie es mich wissen und ich werde es aktualisieren.

Answer 2

Ich bin mir nicht 100% sicher, weil ich das Problem nicht reproduzieren konnte

was einen Betrüger bedeutet kann nicht mehr einen neu registrierten Kunden ausgeht

bedeutet, dass bisher "ein Betrüger" sich als neu registrierter Kunde ausgeben könnte.
Ich hoffe, es ist nur "Semantik", aber ich denke, es bedeutet, was Sie fürchten, es bedeutet.