Webshops sind ein attraktives Ziel für Hacker. Das Abgreifen von Zahlungsdaten der KundInnen durch z.B. „Magecart“-Attacken ist ein reales Risiko, dem sich HändlerInnen stellen müssen. Eine von mehreren Möglichkeiten, das Risiko zu minimieren, ist eine Content Security Policy (CSP).
Was ist eine Content Security Policy und wie kann sie helfen?
Bei der Content Security Policy (CSP) handelt es sich um ein Sicherheitskonzept welches verhindern soll, dass Menschen mit krimineller Energie einem Webshop ihren Schadcode unterschieben, um zum Beispiel auf der Checkout-Seite Kreditkarten abzugreifen.
Risiko „Cross Site Scripting“
Zuerst zum Problem: potentiell gibt es viele Wege, wie Hacker das umsetzen können. Wir konzentrieren uns hier auf das Hauptproblem, genannt „Cross Site Scripting“ (XSS).
Dabei nutzen Hacker Schwachstellen im Webshop, um eigenen JavaScript-Code im Browser der KundInnen auszuführen, wenn diese den Shop besuchen. Mögliche Einfallstore sind Sicherheitslücken im Magento-Code, im Code von Dritthersteller-Extensions oder schwache Admin-Logins.
CSP zur Eindämmung von Cross Site Scripting
Als Gegenmaßnahme für XSS wurde CSP entwickelt. EntwicklerInnen können in der CSP eine Reihe von Regeln definieren, welche Inhalte der Browser auf der Website laden und ausführen kann. Je strikter die Regeln, desto aufwändiger ist das, aber umso besser ist der Shop geschützt. Wenn klar definiert ist, dass nur – und genau nur – Code von den Domains A, B und C eingebunden werden darf, dann hat der Hacker mit Domain D und E keine Chance.
EntwicklerInnen können die CSP-Richtlinien über HTTP-Header oder über HTML-Meta-Daten implementieren.
Wann CSPs nicht helfen können
Klingt alles toll, oder? Leider muss ich gleich zwei Dinge vorausschicken, wobei vor allem Punkt eins ein reales Problem in vielen Projeken ist:
Erstens, die Komplexität der Einführung von CSPs.
Je umfangreicher und angepasster ein Webshop ist, desto schwerer ist es, eine gute Content Security Policy zu definieren. Die Verwendung von externen Tools (Tracking, Marketing-Automationen, …) und Dritthersteller-Extensions macht den Überblick schwer, welche Domains und Arten von Inhalten in allen möglichen Situationen im Shop eingebunden werden.
Zweitens, auch CSP kann kompromittiert werden.
Wie erwähnt: EntwicklerInnen geben dem Browser die Richtlinien über HTTP-Header oder HTML-Meta-Daten mit. Existieren in einem System oder auf einem Server derart gravierende Sicherheitslücken, dass auch diese Code manipuliert oder unterbunden werden kann, dann hat man ein echtes Problem. Allerdings nicht nur in Sachen CSP, sondern allgemein, denn dann kann man auf dem Server nichts mehr vertrauen.
Offizielle Magento 2 Lösung für CSPs
Mit Magento 2.3.5 gibt es zum ersten Mal eine offizielle Lösung für CSPs in Magento 2. Informationen finden sich in den DevDocs, Abschnitt „Content Security Policy Overview“ und „Content Security Policies„.
Allerdings warnt Max Chadwick davor, dass die aktuelle Implementierung noch einen geringen Nutzen hat. In einem weiteren Post erklärt Max, warum er das neue CSP Feature in Magento 2.3.5 vorerst deaktivieren würde und wie man das tut.
Hilfen zur Einrichtung der CSP
Netcalico_CSP
Mit Netalico_CSP sind leicht die ersten Schritte getan, um die Sicherheit durch Forcierung der Content Security Policy (CSP) erhöhen.
Experius_Csp
Das kostenlose Modul Experius_Csp baut auf der Standard-Funktionalität Magento_Csp auf und erleichtert den Einstieg in das Thema Content Security Policy (CSP), indem es eine Basis-Allowed-Liste implementiert.
Zugleich loggt es, wenn eine Resource aufgrund der CSP blockiert wird und hilft so, schneller zu einer CSP zu kommen welche die Shop-Funktionalität nicht beeinträchtigt.
Flancer32_Csp
Flancer32_Csp schlägt in dieselbe Kerbe und sammelt CSP-Verletzungen, um sie in CSP-Regeln zu konvertieren. Die Extension kann die CSP-Verletzungen bei allen KundInnen sammeln und diese Regeln automatisch aktivieren, wodurch man die CSP-Verletzungen los wird.
Es empfiehlt sich, die automatische Aktivierung der Regeln zu deaktivieren und die Einträge selbst zu überprüfen und freizuschalten, damit man sich nicht unfreiwillig einen Exploit ins Haus holt.
Werfe einen Blick auf den Fork von integer_net – in der originalen Extensions gibt es weniger Aktivität als im Fork.
