Der Autor des Materials, dessen Übersetzung wir heute veröffentlichen, sagt, dass es viele Gründe gibt, sich mit Websicherheit zu befassen. Beispielsweise sind Website-Benutzer, die über den Diebstahl ihrer persönlichen Daten besorgt sind, an Sicherheitsfragen interessiert. Die Sicherheit betrifft Webentwickler, die das Schutzniveau für ihre Projekte erhöhen möchten. Gleiches gilt für Programmieranfänger, die Arbeit suchen und sich auf Interviews vorbereiten. Der Zweck dieses Artikels besteht darin, einige wichtige Web-Sicherheitstechnologien in einer verständlichen Sprache zu verstehen. Bevor wir uns mit diesen Technologien befassen, die normalerweise als Abkürzungen wie CORS, CSP und HSTS bezeichnet werden, werden wir uns einige grundlegende Sicherheitskonzepte ansehen.
Zwei grundlegende Web-Sicherheitskonzepte
100% Schutz ist ein Mythos
In der Sicherheitswelt gibt es keinen "100% igen Schutz vor Hacking". Wenn Ihnen jemals jemand von dieser Schutzstufe erzählt, beachten Sie, dass er falsch liegt.
▍Eine Schutzstufe reicht nicht aus
Angenommen, jemand glaubt, dass er durch die Implementierung von CSP sein Projekt vollständig vor XSS-Angriffen geschützt hat. Vielleicht nimmt jemand wahr, dass absoluter Schutz nicht als gegeben existiert, aber Gedanken wie der oben beschriebene können jeden besuchen. Wenn wir über Programmierer sprechen, die sich entschlossen haben, Sicherheitsprobleme zu verstehen, dann ist der Grund für solche Gedanken vielleicht die Tatsache, dass sie beim Schreiben von Programmcode hauptsächlich mit Konzepten wie „schwarz“ und „weiß“ arbeiten. 1 und 0, "wahr" und "falsch". Sicherheit ist aber nicht so einfach.
Web-Sicherheitstechnologien
Beginnen wir die Diskussion über Websicherheit mit Technologie, auf die Entwickler normalerweise sehr früh achten, etwa zu Beginn ihres beruflichen Werdegangs. Übrigens, wenn Sie diese Schutzmethode umgehen möchten, finden Sie in StackOverflow eine Menge Informationen dazu. Es geht um CORS.
ORSCORS
Haben Sie jemals einen solchen Fehler gesehen:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Angesichts solcher denken Sie, dass Sie sicherlich nicht der erste sind, mit dem dies passiert ist. Wenn Sie googeln, stellen Sie fest, dass es zur Lösung dieses Problems ausreicht, eine Erweiterung zu installieren. Ist es nicht wunderbar? Die CORS-Technologie (Cross-Origin Resource Sharing, gemeinsame Nutzung von Ressourcen zwischen verschiedenen Quellen) ist jedoch nicht vorhanden, um Entwickler zu stören, sondern um ihre Projekte zu schützen.
Um zu verstehen, wie CORS Webprojekte schützt, werden zunächst Cookies behandelt, insbesondere Cookies, mit denen Benutzer authentifiziert werden. Diese Cookies werden bei der Arbeit mit einer bestimmten Webressource verwendet, um den Server darüber zu informieren, dass der Benutzer angemeldet ist. Sie werden automatisch mit Anforderungen an den entsprechenden Server gesendet.
Angenommen, Sie sind in Ihrem Facebook-Konto angemeldet und Facebook verwendet Authentifizierungscookies.
bit.ly/r43nugi Sie im Internet arbeiten, klicken Sie auf den Link
bit.ly/r43nugi . Sie werden zu einer schädlichen Website weitergeleitet, beispielsweise zu
bit.ly/r43nugi . Das zusammen mit der Seite auf dieser Website heruntergeladene Skript führt eine Clientanforderung an
facebook.com mit Ihrem Authentifizierungscookie aus.
In einer Welt ohne CORS könnte ein Skript von
superevilwebsite.rocks heimlich Änderungen an Ihrem FB-Profil vornehmen und einige Informationen stehlen, mit allen daraus resultierenden Konsequenzen. In einer solchen Welt könnte leicht eine "epidemische superevilwebsite.rocks" entstanden sein, wenn ein Skript, das die Kontoverwaltung des Benutzers erfasst, einen Link auf seiner Seite veröffentlicht, auf den die Freunde dieses Benutzers "selbst infiziert werden" und über die auf ihren Seiten veröffentlichten Links eine Epidemie deckt letztendlich ganz Facebook ab.
In einer Welt, in der CORS existiert, würde Facebook jedoch nur Anfragen zum Ändern von Kontodaten von
facebook.com zulassen. Mit anderen Worten, die Verwaltung der Site würde die gemeinsame Nutzung von Ressourcen zwischen verschiedenen Quellen einschränken.
Hier haben Sie möglicherweise die folgende Frage: "Aber superevilwebsite.rocks kann einfach den Quellheader in seinen Anforderungen ändern und sie sehen so aus, als ob sie von facebook.com stammen?"
Eine betrügerische Website versucht dies möglicherweise, ist jedoch nicht erfolgreich, da der Browser einen solchen Header ignoriert und echte Daten verwendet.
"Was ist, wenn superevilwebsite.rocks eine ähnliche Anfrage vom Server ausführt?", Fragen Sie.
In einer ähnlichen Situation kann CORS umgangen werden, dies hat jedoch keine Verwendung, da durch Ausführen einer Anforderung vom Server kein Authentifizierungscookie an Facebook übertragen werden kann. Daher muss das Skript, um eine solche Anforderung erfolgreich abzuschließen, auf der Clientseite ausgeführt werden und Zugriff auf auf dem Client gespeicherte Cookies haben.
▍CSP
Um zu verstehen, was CSP (Content Security Policy, Content Protection Policy) ist, müssen Sie zunächst über eine der häufigsten Web-Schwachstellen sprechen. Es geht um XSS (Cross-Site-Scripting, Cross-Site-Scripting).
Bei einem XSS-Angriff fügt der Angreifer speziellen JavaScript-Code in den Client-Teil einer bestimmten Site ein. Sie könnten denken: „Nun, was wird dieses Skript tun? Farben von Seitenelementen ändern? “
Angenommen, jemand hat sein JS-Skript erfolgreich in die Seiten der Site eingebettet, die Sie besuchen. Was könnte ein ähnliches Skript tun? In der Tat viele Dinge:
- Es kann HTTP-Anforderungen an andere Sites senden und so tun, als würden Sie diese ausführen.
- Er kann Sie zu einer Site weiterleiten, die genau so aussieht wie die, bei der Sie angemeldet sind, die jedoch beispielsweise zum Stehlen von Anmeldeinformationen bestimmt ist.
- Es kann
<script> -Tags zu Seiten hinzufügen, die JavaScript-Code enthalten oder zum Laden von JS-Dateien vorgesehen sind. - Er kann der Seite ein
<iframe> -Element hinzufügen, das beispielsweise genau wie die Felder für die Eingabe des Namens und des Kennworts für die Eingabe der Site aussieht. In diesem Fall werden diese Felder zur Eingabe solcher Daten ausgeblendet.
Tatsächlich gibt es unendlich viele Möglichkeiten für einen Angreifer, einen XSS-Angriff erfolgreich auszuführen.
Die Inhaltsschutzrichtlinie versucht dies zu verhindern, indem die folgenden Einschränkungen angewendet werden:
- Einschränkungen, was in einem
<iframe> geöffnet werden kann. - Einschränkungen, auf die Stylesheets geladen werden können.
- Einschränkungen, welche Abfragen ausgeführt werden können.
Wie funktioniert CSP?
Wenn Sie auf den Link klicken oder die Website-URL in die Adressleiste des Browsers eingeben, führt der Browser eine GET-Anforderung aus. Die Anfrage kommt an den Server, der zusammen mit den HTTP-Headern HTML-Code an den Browser übergibt. Wenn Sie sich diese Überschriften ansehen möchten, öffnen Sie die Registerkarte Netzwerk in den Browser-Entwicklertools und besuchen Sie mehrere Websites. Der Antwortheader könnte ungefähr so aussehen:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Dies ist die Sicherheitsrichtlinie für
facebook.com Inhalte. Konvertieren Sie es in ein besser lesbares Aussehen:
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Beachten Sie die hier vorgestellten CSP-Richtlinien:
default-src - verbietet alles, was nicht explizit festgelegt ist.script-src - führt Einschränkungen für herunterladbare Skripte ein.style-src - legt Einschränkungen für die geladenen Stylesheets fest.connect-src - führt Einschränkungen für URLs ein, von denen Ressourcen mithilfe von Skriptschnittstellen wie fetch , XHR , ajax usw. geladen werden können.
Beachten Sie, dass es tatsächlich viele solcher Richtlinien gibt. Der Browser liest den CSP-Header und wendet die entsprechenden Regeln in der geladenen HTML-Datei an. Richtig konfigurierte Anweisungen erlauben nur die Aktionen, die für den korrekten Betrieb der Seite erforderlich sind.
Wenn die Seite keinen CSP-Header hat, gelten für sie keine Verbote. Die * Zeichen im CSP-Header sind Platzhalter. Ein solches Zeichen kann durch alles ersetzt werden, und was passiert, ist erlaubt.
▍HTTPS
Sicher haben Sie von HTTPS (HTTP Secure) gehört. Vielleicht sind Sie auf so etwas gestoßen: "Warum sollte ich mir Sorgen um HTTPS machen, wenn ich nur ein Spiel auf der Website spiele?" Oder vielleicht haben Sie sich folgende Idee ausgedacht: „Wenn Sie kein HTTPS haben, ist das einfach verrückt. Im Hof 2018 Jahr! Glauben Sie nicht, dass auf jemanden verzichtet werden kann, der HTTPS sagt. “
Möglicherweise haben Sie gehört, dass Chrome die Website jetzt als unsicher markiert, wenn kein HTTPS verwendet wird.
Der Hauptunterschied zwischen HTTPS und HTTP besteht darin, dass Daten bei der Übertragung über HTTPS verschlüsselt werden, bei der Übertragung über HTTP jedoch nicht.
Warum lohnt es sich, bei der Übertragung wertvoller Daten darauf zu achten? Die Sache ist, dass bei der Organisation des Datenaustauschs über einen unsicheren Kommunikationskanal die Möglichkeit eines MITM-Angriffs besteht (Man In The Middle, ein Zwischenangriff oder ein Man in the Middle-Angriff).
Wenn Sie in einem Café sitzen und über einen offenen WLAN-Zugangspunkt auf das Internet zugreifen, kann sich jemand ganz einfach als Router ausgeben, über den alle Ihre Anfragen und Antworten gestellt werden. Wenn Ihre Daten nicht verschlüsselt sind, kann der Vermittler damit machen, was er will. Angenommen, er kann HTML-, CSS- oder JavaScript-Code bearbeiten, bevor er vom Server in Ihrem Browser eingeht. Angesichts dessen, was wir bereits über XSS-Angriffe wissen, können Sie sich vorstellen, welche Konsequenzen dies haben könnte.
"Wie ist das möglich? Mein Computer und mein Server wissen, wie die von uns ausgetauschten Daten verschlüsselt und entschlüsselt werden, der böswillige Vermittler jedoch nicht?", Fragen Sie. Dies ist dank der Verwendung des SSL-Protokolls (Secure Sockets Layer) und des neueren TLS-Protokolls (Transport Layer Security) möglich. TLS ersetzte SSL 1999 als die in HTTPS verwendete Verschlüsselungstechnologie. Eine Diskussion der TLS-Funktionen würde den Rahmen dieses Artikels sprengen.
STHSTS
Die HSTS-Technologie (HTTP Strict-Transport-Security, der Mechanismus der erzwungenen Aktivierung einer sicheren Verbindung über das HTTPS-Protokoll) ist recht einfach. Betrachten Sie als Beispiel noch einmal den entsprechenden Facebook-Header:
strict-transport-security: max-age=15552000; preload
Lassen Sie es uns analysieren:
max-age legt die Zeit fest, in der der Browser den Benutzer zwingen muss, über HTTPS mit der Website zu arbeiten.preload - für unsere Zwecke ist dies nicht wichtig.
Dieser Header gilt nur, wenn Sie über HTTPS auf die Site zugreifen. Wenn Sie mit der Site über HTTP arbeiten, wird dieser Header ignoriert. Der Grund dafür ist ganz einfach: Die HTTP-Kommunikation ist so schwach, dass einem solchen Header nicht vertraut werden kann.
Lassen Sie uns noch einmal das Facebook-Beispiel verwenden, um die praktische Nützlichkeit des HSTS-Mechanismus zu demonstrieren. Angenommen, Sie melden sich zum ersten Mal bei facebook.com an und wissen, dass HTTPS sicherer als HTTP ist. Verwenden Sie daher diesen Link:
https://facebook.com . Wenn Ihr Browser den HTML-Code empfängt, erhält er auch einen Header, der dem Browser mitteilt, dass er Sie zwingen sollte, bei zukünftigen Anforderungen zu HTTPS zu wechseln. Nach einem Monat sendet Ihnen jemand einen HTTP-Link zu Facebook,
http://facebook.com , und Sie klicken darauf. Da der Monat kürzer als der in der
max-age Richtlinie festgelegte Zeitraum von 15552000 Sekunden ist, sendet der Browser eine Anfrage über HTTPS, um einen möglichen MITM-Angriff zu verhindern.
Zusammenfassung
Heute haben wir einige Technologien besprochen, die universell eingesetzt werden, um die Sicherheit von Webprojekten zu gewährleisten. Wir glauben, dass Sicherheitsprobleme sehr wichtig sind, da sie absolut jeden betreffen, der mit dem Internet verbunden ist. Das Thema Websicherheit ist riesig. Sie können also nicht sagen, dass nach dem Lesen mehrerer Artikel jemand Experte auf diesem Gebiet wird oder zumindest genug lernt, um Ihr Webprojekt oder Ihre persönlichen Daten effektiv zu schützen. Aber wie in jedem anderen Bereich wird Wissen auf dem Gebiet der Sicherheit akkumuliert, wenn der Wunsch besteht, es zu erhalten, und ihre Quantität verwandelt sich allmählich in Qualität. Wir hoffen, dass dieses Material zu Ihrem Wissen über Web-Sicherheit beigetragen hat.
Liebe Leser! Haben Sie inkonsistente Sicherheitsbedenken von Webentwicklern festgestellt?
