<\/p>\n
In den letzten Wochen haben wir in diesem Blog eine ganze Reihe von sicherheitsrelevanten HTTP-Headern behandelt, aber der Chef von allen ist die Content-Security-Policy<\/a>(CSP). Der Chef, sowohl wegen des Schutzniveaus, das er bietet, aber leider auch wegen der Schwierigkeit, ihn auf Anhieb richtig zu implementieren. Wie bei allen flightPATH-Verkehrsmanagementregeln, die wir k\u00fcrzlich besprochen haben, verwenden wir sie selbst, um die edgeNEXUS-Website und ihre Besucher zu sch\u00fctzen. <\/p>\n Wir haben die harte Arbeit gemacht und den Schmerz gesp\u00fcrt, damit Sie es nicht tun m\u00fcssen, aber es ist nicht zu leugnen, dass vor der Umsetzung einige \u00dcberlegungen und Planungen erforderlich sind. Aber das ist es wert. Das Konzept hinter dieser Kopfzeile ist ziemlich einfach<\/a> und ebenso leistungsstark. Kurz gesagt, Sie verwenden ihn, um die zul\u00e4ssige Herkunft von Inhalten festzulegen, die auf Ihrer Website geladen werden d\u00fcrfen. Dies bietet einen starken Schutz gegen eine Reihe von Code-Injection-Angriffen, die im immer dynamischeren Internet heutzutage weit verbreitet sind, wie Cross Site Scripting (XSS) und Clickjacking. <\/p>\n Zu den kontrollierbaren Inhaltstypen geh\u00f6ren: JavaScript, CSS (ja, CSS kann gef\u00e4hrlich sein), HTML-Frames, Schriftarten, Bilder und einbettbare Objekte wie Java-Applets. Es ist gro\u00dfartig, so viele Optionen zu haben, aber genau hier liegt auch die Schwierigkeit. Die heutigen Websites (einschlie\u00dflich unserer) enthalten eine Vielzahl dieser Inhaltstypen aus vielen Quellen, und sie alle in einer Richtlinie zu identifizieren und zu ber\u00fccksichtigen, kann ein ziemliches Unterfangen sein. <\/p>\n Bevor wir uns damit befassen, lassen Sie uns einen Blick auf die Elemente des Header-Wertes werfen und darauf, wie eine Richtlinie aussieht. Wie Sie sehen werden, handelt es sich im Wesentlichen um eine lange Liste von Inhaltstypen (die in diesem Beispiel alle mit -src enden) und den zul\u00e4ssigen Quellen f\u00fcr jeden Typ. Zusammen werden diese als Richtlinien bekannt. <\/p>\n default-src \u201eself\u201c data:; script-src \u201eself\u201c \u201eunsafe-inline\u201c; connect-src \u201eself\u201c; img-src \u201eself\u201c data:; style-src \u201eself\u201c \u201eunsafe-inline\u201c data:; font-src \u201eself\u201c data:; child-src \u201eself\u201c<\/strong><\/p>\n Es gibt noch weitere Inhaltstypen, die wir ber\u00fccksichtigen k\u00f6nnen, aber die oben genannten sind unserer Meinung nach die wichtigsten Richtlinien (basierend auf Risiko und Verbreitung). Hier finden Sie die Details zu den Inhalten, auf die sich jede Richtlinie bezieht; <\/p>\n Diese Inhaltstypen und ihre Werte werden durch ein Semikolon voneinander getrennt (abgegrenzt). Jeder Typ kann einen oder mehrere der folgenden Werte haben; <\/p>\n Jeder Wert wird durch ein einfaches Leerzeichen abgegrenzt. Die einfachen Anf\u00fchrungszeichen ‚ sind erforderlich, es sei denn, der Wert ist ein Dom\u00e4nenname. Beachten Sie, dass Browsererweiterungen und Plugins ausgenommen sind, da diese als sicher gelten, weil der Benutzer ihnen vertraut (er hat sie ja schlie\u00dflich installiert). <\/p>\n Das sieht alles ziemlich technisch und komplex aus, aber wenn wir es Schritt f\u00fcr Schritt angehen, k\u00f6nnen wir ziemlich schnell eine Strategie entwickeln. Lassen Sie uns schnell zwei Beispiele durchgehen. Versuchen wir es zun\u00e4chst mit einer einfachen internen Website, die \u00fcber HTTP bedient wird. Das brauchen wir; <\/p>\n Der vollst\u00e4ndige Header-Wert ist relativ kurz:<\/p>\n default-src \u201eself\u201c data:; script-src \u201eself\u201c \u201eunsafe-inline\u201c; connect-src \u201eself\u201c; img-src \u201eself\u201c data:; style-src \u201eself\u201c \u201eunsafe-inline\u201c data:; font-src \u201eself\u201c data:<\/strong><\/p>\n Zweitens, eine SSL\/TLS-gesch\u00fctzte Website, die Google Analytics (GA), Inline-CSS, Schriftarten und Bilder, CSS von Ihrer Website und Bilder von verschiedenen anderen Websites verwendet. Lassen Sie uns St\u00fcck f\u00fcr St\u00fcck durchgehen, was wir brauchen (es ist nicht sehr unterschiedlich); <\/p>\n Wenn Sie das alles zusammenz\u00e4hlen, erhalten Sie diese etwas l\u00e4ngere Police:<\/p>\n default-src \u201eself\u201c data: https:; script-src \u201eself\u201c \u201eunsafe-inline\u201c *.google-analytics.com https:; img-src \u201eself\u201c \u201eunsafe-inline\u201c * https:; style-src \u201eself\u201c \u201eunsafe-inline\u201c https:; font-src \u201eself\u201c \u201eunsafe-inline\u201c https:<\/strong><\/p>\n Ziemlich einfach, w\u00fcrde ich sagen. Google war in der Vergangenheit nicht so CSP-freundlich (dieser Header-Wert war fr\u00fcher mindestens doppelt so lang), aber gl\u00fccklicherweise haben sie in letzter Zeit gro\u00dfe Fortschritte gemacht. Sie werden feststellen, dass wir die Dom\u00e4ne *.google-analytics.com nicht als Content-Type-Wert zum script-src hinzuf\u00fcgen mussten, da ihr Code als Inline-Skript ausgef\u00fchrt wird.<\/p>\n Idealerweise w\u00fcrden Sie eine Richtlinie f\u00fcr jede Seite Ihrer Website erstellen, da die geladenen Ressourcen zweifellos von Seite zu Seite unterschiedlich sind. Dies ist jedoch ziemlich m\u00fchsam und es ist viel einfacher, aber dennoch effektiv, eine Richtlinie zu erstellen, die alle m\u00f6glichen Quellen abdeckt. Die meisten der Beispiele auf unserer GitHub-Seite verfolgen diesen Ansatz, aber es gibt auch eines, wenn Sie bestimmte Seiten st\u00e4rker sch\u00fctzen m\u00f6chten. <\/p>\n Zum Testen und zur Fehlerbehebung empfehle ich Ihnen, die Google Chrome Developer Tools zu verwenden. Rufen Sie die betreffende Website auf, dr\u00fccken Sie F12, klicken Sie auf Netzwerk, stellen Sie sicher, dass Cache deaktivieren aktiviert ist und laden Sie die Seite erneut. Alle Fehler werden deutlich hervorgehoben. Unten in diesem Blog finden Sie einen Bildschirm, der zeigt, was Sie sehen k\u00f6nnten, wenn Ihre Richtlinie unsafe-inline<\/strong> blockiert und Sie Google Analytics verwenden; die Fehlermeldungen sind sehr hilfreich. <\/p>\n Passen Sie Ihre Richtlinie nach Bedarf an und sp\u00fclen Sie sie aus und wiederholen Sie sie. Idealerweise verwenden Sie dazu einen dedizierten virtuellen Testdienst, auf den die zu testende flightPATH-Regel angewendet wird, der aber ansonsten dieselbe Website bedient, nur \u00fcber eine andere virtuelle IP, damit Sie w\u00e4hrend des Tests keine echten Kunden und Klienten beeintr\u00e4chtigen. <\/p>\n Wie immer liegt der gro\u00dfe Vorteil des Einsatzes eines Load Balancer darin, dass wir dies nur an einer zentralen Stelle tun m\u00fcssen, um alle unsere Server (und Websites) zu sch\u00fctzen. Wir m\u00fcssen uns nicht auf Entwickler oder Webserver-Neukonfigurationen verlassen. Auf dem edgeNEXUS Load Balancer importieren wir einfach eine automatische jetPACK-Konfigurationsvorlage und weisen dem oder den virtuellen Diensten, die wir sch\u00fctzen m\u00f6chten, eine flightPATH-Verkehrsregel zu (nach entsprechenden \u00c4nderungen). <\/p>\n Die Regel f\u00fcgt die Kopfzeile nur hinzu, wenn sie nicht vorhanden ist. Sie funktioniert also auch dann, wenn unsere Webserver sie bereits einf\u00fcgen oder vielleicht nur f\u00fcr bestimmte Seiten einf\u00fcgen. Diese Regel sollte Teil Ihrer Standardkonfiguration f\u00fcr virtuelle Dienste sein – Sie haben nichts zu verlieren, egal wie die Seite aussieht. Sie k\u00f6nnen dieses jetPACK und viele andere auf der edgeNEXUS Github-Website<\/a> herunterladen. <\/p>\n flightPATH ist eine dynamische, ereignisbasierte Regel-Engine, die von edgeNEXUS entwickelt wurde, um IP-, HTTP- und HTTPS-Verkehr mit Lastverteilung intelligent zu manipulieren und zu routen. Sie ist hochgradig konfigurierbar und leistungsstark, aber dennoch sehr einfach zu bedienen. <\/p>\n Diese weiterf\u00fchrenden Links sind es wert, gelesen zu werden, wenn Sie mehr wissen m\u00f6chten;<\/p>\n http:\/\/www.html5rocks.com\/en\/tutorials\/security\/content-security-policy\/<\/a><\/p>\n https:\/\/developer.mozilla.org\/en\/docs\/Web\/Security\/CSP\/CSP_policy_directives<\/a><\/p>\n\n
\n
\n
\n