Sicherheit im Web

Sicherheit und Privatsphäre sind unterschiedliche, aber eng verwandte Themen. Es lohnt sich, die Unterschiede zwischen den beiden zu kennen und zu verstehen, wie sie zusammenhängen.

• Sicherheit bedeutet, private Daten und Systeme vor unbefugtem Zugriff zu schützen. Dies umfasst sowohl Unternehmensdaten (intern) als auch Benutzerdaten und Partnerdaten (extern).

• Privatsphäre bezieht sich darauf, den Benutzern die Kontrolle darüber zu geben, wie ihre Daten gesammelt, gespeichert und verwendet werden, und sicherzustellen, dass sie nicht unverantwortlich verwendet werden. Beispielsweise sollten Sie Ihren Benutzern mitteilen, welche Daten Sie von ihnen sammeln, mit welchen Parteien sie geteilt werden und wie sie verwendet werden. Benutzer müssen die Möglichkeit haben, Ihrer Datenschutzrichtlinie zuzustimmen, Zugang zu ihren gespeicherten Daten zu haben und diese bei Bedarf zu löschen.

Gute Sicherheit ist entscheidend für gute Privatsphäre. Sie könnten alle Ratschläge in unserem Leitfaden zur Privatsphäre im Web befolgen, aber auch das Handeln mit Integrität und das Vorhandensein einer robusten Datenschutzrichtlinie sind nutzlos, wenn Ihre Website nicht sicher ist und Angreifer dennoch Daten stehlen können.

Webbrowser folgen einem strikten Sicherheitsmodell, das starke Sicherheit für Inhalte, Verbindungen zwischen dem Browser und dem Server und die Datenübertragung erzwingt. Dieser Abschnitt befasst sich mit den Funktionen, die diesem Modell zugrunde liegen.

Die Same-Origin-Policy ist ein grundlegender Sicherheitsmechanismus des Webs, der einschränkt, wie ein Dokument oder ein Skript, das von einem Ursprung geladen wird, mit einer Ressource eines anderen Ursprungs interagieren kann. Sie hilft, möglicherweise schädliche Dokumente zu isolieren und reduziert mögliche Angriffspunkte.

Im Allgemeinen können Dokumente von einem Ursprung keine Anfragen an andere Ursprünge stellen. Dies ist sinnvoll, denn Sie möchten nicht, dass Websites miteinander in Konflikt geraten und unbefugten Zugriff auf Daten erhalten.

Es kann jedoch Situationen geben, in denen Sie diese Einschränkung lockern möchten; Beispielsweise, wenn Sie mehrere Websites haben, die miteinander interagieren, können Sie ihnen erlauben, Ressourcen voneinander anzufordern, indem Sie fetch() verwenden. Dies kann durch Cross-Origin Resource Sharing (CORS) ermöglicht werden, einem mechanismenbasierten HTTP-Header, der es einem Server ermöglicht, beliebige Ursprünge (Domäne, Schema oder Port) als andere als seine eigenen anzugeben, von denen ein Browser das Laden von Ressourcen zulassen sollte.

Das HTTP-Protokoll wird von Webbrowsern und Servern genutzt, um miteinander zu kommunizieren, Ressourcen anzufordern, Antworten bereitzustellen (zum Beispiel eine angeforderte Ressource oder warum eine Anforderung fehlgeschlagen ist) und Sicherheitsfunktionen für diese Kommunikation bereitzustellen.

Transport Layer Security (TLS) bietet Sicherheit und Privatsphäre, indem es Daten während des Transports über das Netzwerk verschlüsselt und ist die Technologie hinter dem HTTPS-Protokoll. TLS ist gut für die Privatsphäre, da es Dritte daran hindert, übermittelte Daten abzufangen und sie missbräuchlich zu verwenden.

Alle Browser bewegen sich in Richtung einer standardmäßigen Anforderung von HTTPS; dies ist praktisch bereits der Fall, da Sie ohne dieses Protokoll kaum etwas im Web tun können.

Verwandte Themen:

Transport Layer Security (TLS)

Das TLS-Protokoll ist der Standard für die sichere und zuverlässige Übertragung von Informationen zwischen zwei vernetzten Anwendungen oder Geräten. Anwendungen, die TLS nutzen, können ihre Sicherheitsparameter wählen, die einen erheblichen Einfluss auf die Sicherheit und Zuverlässigkeit der Daten haben können.

HTTP Strict-Transport-Security

Der Strict-Transport-Security HTTP-Header ermöglicht es einer Website, anzugeben, dass sie nur mit HTTPS erreichbar sein darf.

Certificate Transparency

Certificate Transparency (CT) ist ein offenes Framework, das dazu entwickelt wurde, gegen unrechtmäßige Ausstellung von Zertifikaten zu schützen und diese zu überwachen. Neu ausgestellte Zertifikate werden in öffentlich betriebenen, oft unabhängigen CT-Protokollen protokolliert. Diese bieten nur anhängbare, kryptografisch gesicherte Aufzeichnungen von ausgestellten TLS-Zertifikaten.

Mixed Content

Eine HTTPS-Seite, die Inhalte enthält, die unter Verwendung von Klartext HTTP abgerufen wurden, wird als Mixed Content-Seite bezeichnet. Solche Seiten sind nur teilweise verschlüsselt, was den unverschlüsselten Inhalt für Lauschangriffe und Man-in-the-Middle-Angreifer zugänglich macht.

Schwache Signaturalgorithmen

Die Stärke des Hash-Algorithmus, der bei der Signierung eines digitalen Zertifikats verwendet wird, ist ein kritisches Element für dessen Sicherheit. Einige Signaturalgorithmen sind als schwach bekannt und sollten vermieden werden, wenn dies angebracht ist.

Browser kontrollieren die Nutzung von "leistungsstarken Funktionen" auf verschiedene Weise. Diese "leistungsstarken Funktionen" umfassen das Generieren von Systembenachrichtigungen auf einer Website, die Nutzung der Webcam eines Benutzers zum Zugang zu einem Medienstream, die Manipulation der System-GPU und das Verwenden von Webzahlungen. Wenn ein Website einfach die APIs, die solche Funktionen kontrollieren, ohne jede Einschränkung nutzen könnte, könnten böswillige Entwickler versuchen, folgendes zu tun:

• Benutzer mit unnötigen Benachrichtigungen und anderen UI-Funktionen zu belästigen.
• Ihre Webcam einzuschalten, ohne Vorwarnung, um sie auszuspionieren.
• Ihren Browser / Ihr System zu überlasten, um Denial-of-Service (DoS)-Angriffe zu erzeugen.
• Daten oder Geld zu stehlen.

Diese "leistungsstarken Funktionen" werden auf folgende Weise kontrolliert:

• Die Nutzung solcher Funktionen ist nur in sicheren Kontexte gestattet. Ein sicherer Kontext ist ein window oder ein worker, bei dem mit hinreichender Sicherheit davon ausgegangen wird, dass die Inhalte sicher (über HTTPS/TLS) bereitgestellt wurden. In einem sicheren Kontext gibt es nur begrenzte Möglichkeiten zur Kommunikation mit Kontexten, die nicht sicher sind. Sichere Kontexte helfen auch dabei, Man-in-the-Middle-Angreifer daran zu hindern, auf leistungsstarke Funktionen zuzugreifen.

  Für eine Liste von Web-Plattform-Funktionen, die nur in sicheren Kontexten verfügbar sind, siehe Funktionen, die auf sichere Kontexte beschränkt sind.

• Die Nutzung dieser Funktionen erfordert ein System von Benutzerberechtigungen: Benutzer müssen ausdrücklich zustimmen, Zugriff auf solche Funktionen zu gewähren, was bedeutet, dass sie nicht automatisch genutzt werden können. Berechtigungsanfragen zur Erteilung geschehen automatisch, und Sie können den Status einer API-Berechtigung mittels der Permissions API abfragen.

• Mehrere andere Browser-Funktionen können nur in Reaktion auf eine Benutzeraktion, zum Beispiel einem Klick auf einen Button, verwendet werden, das heißt, sie müssen aus einem geeigneten Ereignishandler aufgerufen werden. Dies wird transiente Aktivierung genannt. Siehe Funktionen, die eine Benutzeraktivierung erfordern für weitere Informationen.

Es gibt viele Aspekte der Websicherheit, die sowohl auf der Server- als auch auf der Clientseite bedacht werden müssen. Dieser Abschnitt konzentriert sich hauptsächlich auf clientseitige Sicherheitsbetrachtungen. Einen nützlichen Überblick über die Sicherheit aus einer serverseitigen Perspektive, der auch Beschreibungen häufiger Angriffe beinhaltet, auf die Sie achten sollten, finden Sie unter Website-Sicherheit (Teil unseres Lernmoduls zur Programmierung von serverseitigen Websites).

Der verantwortungsvolle Umgang mit Daten bezieht sich größtenteils auf die Reduzierung der Verwendung von Drittanbieter-Cookies und die Achtsamkeit bezüglich der Daten, die Sie speichern und mit diesen teilen. Traditionell haben Webentwickler Cookies verwendet, um alle Arten von Daten zu speichern, und es war für Angreifer einfach, diese Tendenz auszunutzen. Daher haben Browser begonnen einzuschränken, was Sie mit domainsübergreifenden Cookies tun können, mit dem Ziel, den Zugriff auf sie in Zukunft ganz zu entfernen.

Sie sollten sich auf die Entfernung von domainsübergreifenden Cookies vorbereiten, indem Sie die Anzahl der Tracking-Aktivitäten, auf die Sie sich verlassen, begrenzen und/oder die Persistenz der gewünschten Informationen auf andere Weise implementieren. Siehe Übergang von Drittanbieter-Cookies und Ersatz von Drittanbieter-Cookies für weitere Informationen.

Wenn Sie eine sichere Lösung implementieren, die Datenerfassung beinhaltet, insbesondere wenn die Daten sensibel sind wie Anmeldedaten, ist es sinnvoll, eine renommierte Lösung zu verwenden. Zum Beispiel hat jedes respektable serverseitige Framework eingebaute Funktionen, um vor gängigen Schwachstellen zu schützen. Sie könnten auch in Erwägung ziehen, ein spezialisiertes Produkt für Ihren Zweck zu nutzen, zum Beispiel eine Identitätsanbieter-Lösung oder einen sicheren Online-Umfrageanbieter.

Wenn Sie eine eigene Lösung zum Sammeln von Benutzerdaten erstellen möchten, stellen Sie sicher, dass Sie alle Aspekte und Anforderungen verstehen. Engagieren Sie einen erfahrenen serverseitigen Entwickler und/oder Sicherheitsingenieur, um das System zu implementieren, und stellen Sie sicher, dass es gründlich getestet wird. Nutzen Sie Multi-Faktor-Authentifizierung (MFA) für besseren Schutz. Erwägen Sie die Verwendung einer dedizierten API wie Web Authentication oder Federated Credential Management, um die clientseitige App zu optimieren.

Hier sind einige weitere Tipps für sichere Logins:

• Beim Sammeln von Benutzeranmeldeinformationen, erzwingen Sie starke Passwörter, damit die Kontodaten Ihrer Benutzer nicht einfach erraten werden können. Schwache Passwörter sind einer der Hauptursachen für Sicherheitsverstöße. Darüber hinaus ermutigen Sie Ihre Benutzer, einen Passwort-Manager zu verwenden, damit sie komplexere Passwörter verwenden können, sich keine Sorgen um das Erinnern machen müssen und kein Sicherheitsrisiko durch das Aufschreiben der Passwörter entsteht. Siehe auch unseren Artikel über Unsichere Passwörter.

• Sie sollten Ihre Benutzer auch über Phishing aufklären. Phishing ist der Vorgang, eine Nachricht an einen Benutzer zu senden (zum Beispiel eine E-Mail oder eine SMS), die einen Link zu einer Website enthält, die wie eine Website aussieht, die sie täglich verwenden, es aber nicht ist. Der Link ist begleitet von einer Nachricht, die darauf abzielt, Benutzer zu täuschen, sodass sie ihren Benutzernamen und ihr Passwort auf der Seite eingeben, damit es gestohlen und dann von einem Angreifer für böswillige Zwecke verwendet werden kann.

  Hinweis: Einige Phishing-Seiten können sehr raffiniert sein und schwer von einer echten Website zu unterscheiden sein. Sie sollten daher Ihre Benutzer aufklären, zufälligen Links in E-Mails und SMS-Nachrichten nicht zu vertrauen. Wenn sie eine Nachricht erhalten, die in etwa lautet "Dringend, Sie müssen sich jetzt anmelden, um ein Problem zu lösen", sollten sie direkt in einem neuen Tab zur Website gehen und versuchen, sich direkt anzumelden, anstatt auf den Link in der Nachricht zu klicken. Oder sie könnten Sie telefonisch oder per E-Mail kontaktieren, um über die empfangene Nachricht zu sprechen.

• Schützen Sie vor Brute-Force-Angriffen auf Anmeldeseiten durch Ratenbegrenzung, Kontosperrungen nach einer bestimmten Anzahl erfolgloser Versuche und CAPTCHA-Herausforderungen.

• Verwalten Sie Benutzersitzungen mit eindeutigen Sitzungs-IDs und melden Sie Benutzer automatisch ab, nachdem sie längere Zeit inaktiv waren.

Als allgemeine Regel sollten Sie keine sensiblen Daten in URL-Query-Strings einfügen, denn wenn eine dritte Partei die URL abfängt (zum Beispiel über den Referer HTTP-Header), könnten diese Informationen gestohlen werden. Noch ernster ist die Tatsache, dass diese URLs von öffentlichen Webcrawlern, HTTP-Proxies und Archivierungs-Tools wie dem Internet-Archiv indexiert werden können, was bedeutet, dass Ihre sensiblen Daten auf öffentlich zugänglichen Ressourcen bestehen könnten.

Nutzen Sie POST-Anfragen anstelle von GET-Anfragen, um diese Probleme zu vermeiden. Unser Artikel Referer-Header-Richtlinie: Datenschutz- und Sicherheitsbedenken beschreibt ausführlicher die Datenschutz- und Sicherheitsrisiken, die mit dem Referer-Header verbunden sind, und bietet Ratschläge zur Minderung dieser Risiken.

Erwägen Sie den Einsatz von Web-Plattform-Funktionen wie der Content Security Policy (CSP) und der Permissions Policy, um eine Reihe von Regeln zur Funktions- und Ressourcennutzung auf Ihrer Website durchzusetzen, die es schwieriger machen, Schwachstellen einzuführen.

CSP ermöglicht es Ihnen, eine Sicherheitsschicht hinzuzufügen, indem Sie beispielsweise nur das Laden von Bildern oder Skripten von bestimmten vertrauenswürdigen Ursprüngen erlauben. Dies hilft, bestimmte Arten von Angriffen zu erkennen und zu mindern, einschließlich Cross-Site Scripting (XSS) und Dateninjektionsangriffen. Diese Angriffe sind mit einer Reihe von böswilligen Aktivitäten verbunden, einschließlich Datendiebstahl, Verunstaltung von Websites und Verteilung von Malware.

Die Berechtigungspolitik funktioniert ähnlich, außer dass sie sich mehr auf das Erlauben oder Blockieren des Zugriffs auf spezifische "leistungsstarke Funktionen" konzentriert (wie bereits erwähnt).

Anknüpfend an den vorherigen Abschnitt sollten Sie, wenn Sie die Nutzung von Funktionen und Ressourcen auf Ihrer Seite erlauben, versuchen sicherzustellen, dass die Ressourcen nicht manipuliert wurden.

Verwandte Themen:

Subresource Integrity

Subresource Integrity (SRI) ist eine Sicherheitsfunktion, die es Browsern ermöglicht, zu überprüfen, dass die von ihnen abgerufenen Ressourcen (z.B. von einem CDN) ohne unvorhergesehene Manipulation ausgeliefert wurden. Sie funktioniert, indem Sie einen kryptografischen Hash angeben, den eine abgerufene Ressource entsprechen muss.

HTTP Access-Control-Allow-Origin

Der Access-Control-Allow-Origin Antwort-Header gibt an, ob die Antwort mit dem anfragenden Code des angegebenen Ursprungs geteilt werden kann.

HTTP X-Content-Type-Options

Der X-Content-Type-Options Antwort-Header ist ein Indikator, der vom Server verwendet wird, um anzugeben, dass die in den Content-Type Headers beworbenen MIME-Typen nicht geändert werden sollten und eingehalten werden müssen. Dieser Header ist eine Möglichkeit, sich von MIME-Typ-Sniffing abzumelden, oder mit anderen Worten, anzugeben, dass die MIME-Typen absichtlich konfiguriert sind.

Als allgemeine Regel gilt: Vertrauen Sie nichts, was Benutzer in Formulare eingeben. Das Ausfüllen von Formularen online ist kompliziert und mühsam, und es ist einfach für Benutzer, falsche Daten oder Daten im falschen Format einzugeben. Darüber hinaus sind böswillige Akteure geschickt darin, spezifische Zeichenfolgen von ausführbarem Code in Formularfelder einzufügen (zum Beispiel SQL oder JavaScript). Wenn Sie beim Umgang mit solchen Eingaben nicht vorsichtig sind, könnten sie entweder schädlichen Code auf Ihrer Website ausführen oder Ihre Datenbanken löschen. Siehe SQL-Injection für ein gutes Beispiel, wie dies passieren könnte.

Um sich davor zu schützen, sollten Sie die in Ihre Formulare eingegebenen Daten gründlich bereinigen:

• Sie sollten eine clientseitige Validierung implementieren, um Benutzer zu informieren, wenn sie Daten im falschen Format eingegeben haben. Sie können dies durch die eingebauten HTML-Formularvalidierungsfunktionen tun oder Ihre eigene Validierung schreiben. Siehe Clientseitige Formularvalidierung für weitere Informationen.
• Sie sollten Ausgabecodierung verwenden, wenn Benutzer-Eingaben in einer Anwendungsoberfläche angezeigt werden, um die Daten sicher genau so anzuzeigen, wie ein Benutzer sie eingegeben hat, und zu verhindern, dass sie als Code ausgeführt werden. Siehe Ausgabecodierung für weitere Informationen.

Sie können sich nicht allein auf clientseitige Validierung für die Sicherheit verlassen – diese sollte mit einer serverseitigen Validierung kombiniert werden. Die clientseitige Validierung verbessert die Benutzererfahrung, indem sie sofortiges Validierungsfeedback bereitstellt, ohne auf eine Rückantwort vom Server warten zu müssen. Allerdings ist die clientseitige Validierung für böswillige Parteien einfach zu umgehen (zum Beispiel durch Deaktivierung von JavaScript im Browser, um eine JavaScript-basierte Validierung zu umgehen).

Jedes angesehene serverseitige Framework wird Funktionalität für die Validierung von Formulareingaben bieten. Darüber hinaus ist es eine gängige Best Practice, alle Sonderzeichen, die Teil der ausführbaren Syntax sind, zu maskieren, wobei eingegebener Code nicht mehr ausführbar und als normaler Text behandelt wird.

Bei einem Clickjacking-Angriff wird ein Benutzer getäuscht, einen UI-Element anzuklicken, das eine andere Aktion ausführt als die, die der Benutzer erwartet, oft mit dem Ergebnis, dass die vertraulichen Informationen des Benutzers an einen böswilligen Dritten weitergegeben werden. Dieses Risiko ist bei eingebettetem Drittanbieterinhalt vorhanden, stellen Sie also sicher, dass Sie dem vertrauen, was in Ihre Site eingebettet wird. Seien Sie sich außerdem bewusst, dass Clickjacking mit Phishing-Techniken kombiniert werden kann. Sie können über Phishing im vorherigen Abschnitt Benutzeridentität schützen und Logins verwalten lesen.

Die folgenden Funktionen können helfen, sich gegen Clickjacking zu schützen:

HTTP X-Frame-Options

Der X-Frame-Options HTTP Antwort-Header kann verwendet werden, um anzugeben, ob ein Browser berechtigt ist, eine Seite in einem <frame>, <iframe>, <embed> oder <object> wiederzugeben. Websites können dies verwenden, um Clickjacking-Angriffe zu vermeiden, indem sie sicherstellen, dass ihre Inhalte nicht in andere Sites eingebettet werden.

CSP: frame-ancestors

Die HTTP Content-Security-Policy (CSP) frame-ancestors Direktive gibt gültige übergeordnete Elemente an, die eine Seite unter Verwendung von <frame>, <iframe>, <object> oder <embed> einbetten dürfen.

Um umfassende Anweisungen zur effektiven Implementierung von Sicherheitsfunktionen auf Websites zu erhalten und sicherzustellen, dass Sie Best Practices befolgen, sehen Sie sich unser Set von Praktischen Anleitungen zur Sicherheitsimplementierung an.

Einige dieser Leitfäden hängen direkt mit dem HTTP Observatory-Tool zusammen. Observatory führt Sicherheitsüberprüfungen auf einer Website durch und liefert zusammen mit Empfehlungen zur Behebung der gefundenen Sicherheitsprobleme eine Bewertung und Punktzahl. Diese Leitfäden erklären, wie man die vom MDN Observatory Test aufgedeckten Problem löst: Das Tool verlinkt den passenden Leitfaden für jedes Problem, um sie effektiv zu einer Lösung zu lenken. Interessanterweise nutzen die internen Entwicklerteams von Mozilla diese Richtlinien beim Erstellen von Websites, um sicherzustellen, dass Sicherheitsbest-Practices angewendet werden.

• Privatsphäre im Web
• Lernen: Website-Sicherheit
• Mozilla Security Blog
• OWASP Cheat Sheet-Serie