Sicherheit im Web

Sicherheit und Privatsphäre sind unterschiedliche, aber eng verwandte Themen. Es lohnt sich, die Unterschiede zwischen beiden und ihre Beziehung zueinander zu kennen.

• Sicherheit ist der Akt, private Daten und Systeme vor unbefugtem Zugriff zu schützen. Dies umfasst sowohl Unternehmensdaten (intern) als auch Benutzer- und Partnerdaten (extern).

• Privatsphäre bezieht sich darauf, den Nutzern die Kontrolle darüber zu geben, wie ihre Daten gesammelt, gespeichert und verwendet werden, und sicherzustellen, dass sie nicht unverantwortlich genutzt werden. Beispielsweise sollten Sie den Nutzern mitteilen, welche Daten Sie von ihnen sammeln, mit welchen Parteien sie geteilt werden und wie sie verwendet werden. Nutzern muss die Möglichkeit gegeben werden, Ihrer Datenschutzerklärung zuzustimmen, auf ihre gespeicherten Daten zuzugreifen und diese bei Bedarf zu löschen.

Gute Sicherheit ist für gute Privatsphäre unerlässlich. Sie könnten allen Rat befolgen, der in unserem Privatsphäre im Web Leitfaden aufgeführt ist, aber das Handeln mit Integrität und eine robuste Datenschutzrichtlinie sind vergeblich, wenn Ihre Seite nicht sicher ist und Angreifer einfach Daten stehlen können.

Webbrowser befolgen ein striktes Sicherheitsmodell, das starke Sicherheit für Inhalte, Verbindungen zwischen Browser und Server sowie den Datentransport durchsetzt. In diesem Abschnitt werden die Funktionen behandelt, die diesem Modell zugrunde liegen.

Richtlinien für denselben Ursprung sind ein grundlegender Sicherheitsmechanismus des Webs, der beschränkt, wie ein Dokument oder ein Skript, das von einem Ursprung geladen wurde, mit einer Ressource eines anderen Ursprungs interagieren kann. Es hilft, potenziell bösartige Dokumente zu isolieren und mögliche Angriffsvektoren zu reduzieren.

Im Allgemeinen können Dokumente eines Ursprungs keine Anfragen an andere Ursprünge stellen. Das macht Sinn, weil man nicht möchte, dass Seiten einander stören und unbefugte Datenzugriffe erhalten.

Jedoch könnten Sie in einigen Fällen diese Einschränkung lockern wollen; zum Beispiel, wenn Sie mehrere Websites haben, die miteinander interagieren, könnten Sie ihnen erlauben, untereinander Ressourcen mit fetch() anzufordern. Dies kann durch Cross-Origin Resource Sharing (CORS) erlaubt werden, einen HTTP-Header-basierenden Mechanismus, der einem Server ermöglicht, anzugeben, von welchen Ursprüngen (Domain, Schema oder Port) außer dem eigenen ein Browser laden darf.

Das HTTP Protokoll wird von Webbrowsern und Servern verwendet, um miteinander zu kommunizieren, Ressourcen anzufordern, Antworten bereitzustellen (zum Beispiel eine angeforderte Ressource bereitzustellen oder zu erklären, warum eine Anfrage fehlgeschlagen ist) und Sicherheitsfunktionen für diese Kommunikation zu bieten.

Transport Layer Security (TLS) bietet Sicherheit und Privatsphäre, indem Daten während des Transports über das Netzwerk verschlüsselt werden. Es ist die Technologie hinter dem HTTPS Protokoll. TLS ist gut für die Privatsphäre, da es Dritten verhindert, übertragene Daten abzufangen und böswillig zu verwenden.

Alle Browser bewegen sich in Richtung einer Standardanforderung von HTTPS; dies ist bereits praktisch der Fall, da man ohne dieses Protokoll im Web nicht viel tun kann.

Verwandte Themen:

Transportschichtsicherheit (TLS)

Das TLS-Protokoll ist der Standard für die sichere und robuste Übertragung von Informationen zwischen zwei vernetzten Anwendungen oder Geräten. Anwendungen, die TLS verwenden, können ihre Sicherheitsparameter wählen, was erhebliche Auswirkungen auf die Sicherheit und Zuverlässigkeit der Daten haben kann.

HTTP Strict-Transport-Security

Der Strict-Transport-Security HTTP Header ermöglicht es einer Website, anzugeben, dass sie nur über HTTPS zugänglich sein darf.

Certificate Transparency

Certificate Transparency (CT) ist ein offenes Framework, das dazu entwickelt wurde, um gegen fehlerhafte Zertifikatsausstellung zu schützen und diese zu überwachen. Neu ausgestellte Zertifikate werden in öffentlich betriebenen, oft unabhängigen CT-Logs "protokolliert". Diese bieten nur hinzufügbare, kryptografisch gesicherte Berichte über ausgestellte TLS-Zertifikate.

Gemischte Inhalte

Eine HTTPS-Seite, die Inhalte enthält, die über Klartext HTTP abgerufen werden, wird als gemischte Inhalte-Seite bezeichnet. Solche Seiten sind nur teilweise verschlüsselt, was bedeutet, dass der unverschlüsselte Inhalt für Abhörer und Man-in-the-Middle-Angreifer zugänglich ist.

Schwache Signaturalgorithmen

Die Stärke des zur Signierung eines digitalen Zertifikats verwendeten Hash-Algorithmus ist ein kritisches Element der Sicherheit des Zertifikats. Einige Signaturalgorithmen sind als schwach bekannt und sollten vermieden werden, wenn angebracht.

Browser steuern die Nutzung von "leistungsstarken Funktionen" auf verschiedene Weise. Diese "leistungsstarken Funktionen" umfassen das Generieren von Systembenachrichtigungen auf einer Website, das Verwenden der Webcam eines Nutzers zum Zugriff auf einen Medienstream, das Manipulieren der System-GPU und die Nutzung von Web-Zahlungen. Wenn eine Seite solche Funktionen ohne Einschränkung nutzen könnte, könnten böswillige Entwickler versuchen Folgendes zu tun:

• Nutzer mit unnötigen Benachrichtigungen und anderen UI-Features belästigen.
• Ihre Webcam ohne Vorwarnung einschalten, um sie zu bespitzeln.
• Ihren Browser/Ihr System verstopfen, um Denial of Service (DoS) Attacken zu erzeugen.
• Daten oder Geld stehlen.

Diese "leistungsstarken Funktionen" werden auf folgende Arten gesteuert:

• Die Verwendung solcher Funktionen ist nur in sicheren Kontexten erlaubt. Ein sicherer Kontext ist ein window oder ein worker, für den ein angemessenes Maß an Vertrauen besteht, dass der Inhalt sicher (über HTTPS/TLS) geliefert wurde. In einem sicheren Kontext ist das Potenzial für die Kommunikation mit Kontexten, die nicht sicher sind, begrenzt. Sichere Kontexte tragen auch dazu bei, zu verhindern, dass Man-in-the-Middle-Angreifer Zugriff auf leistungsstarke Funktionen erhalten.

  Eine Liste der Web-Plattform-Funktionen, die nur in sicheren Kontexten verfügbar sind, finden Sie unter Funktionen, die auf sichere Kontexte beschränkt sind.

• Die Nutzung dieser Funktionen ist hinter einem System von Nutzerberechtigungen abgesichert: Nutzer müssen ausdrücklich zustimmen, Zugang zu solchen Funktionen zu gewähren, was bedeutet, dass sie nicht automatisch genutzt werden können. Anfragen für Nutzerberechtigungen erfolgen automatisch, und Sie können den Status einer API-Berechtigung mit der Permissions API abfragen.

• Mehrere andere Browser-Funktionen können nur als Reaktion auf eine Benutzeraktion wie das Klicken eines Buttons genutzt werden, was bedeutet, dass sie innerhalb eines geeigneten Ereignishandlers aufgerufen werden müssen. Dies wird als vorübergehende Aktivierung bezeichnet. Weitere Informationen finden Sie unter Funktionen, die durch Benutzeraktivierung gesteuert werden.

Es gibt viele Aspekte der Web-Sicherheit, die auf der Server- und Client-Seite berücksichtigt werden müssen. Dieser Abschnitt konzentriert sich hauptsächlich auf sicherheitsrelevante Überlegungen auf der Client-Seite. Eine nützliche Zusammenfassung der Sicherheit aus einer serverseitigen Perspektive, die auch Beschreibungen häufig vorkommender Angriffe enthält, auf die Sie achten sollten, finden Sie unter Website-Sicherheit (Teil unseres Lernmoduls für Serverseitige Website-Programmierung).

Ein verantwortungsvoller Umgang mit Daten besteht hauptsächlich darin, den Einsatz von Drittanbieter-Cookies zu reduzieren und darauf zu achten, welche Daten Sie speichern und mit diesen teilen. Traditionell haben Webentwickler Cookies benutzt, um alle Arten von Daten zu speichern, und es war einfach für Angreifer, diese Neigung auszunutzen. Infolgedessen haben Browser begonnen, einzuschränken, was man mit Cross-Site-Cookies machen kann, mit dem Ziel, den Zugriff darauf in Zukunft vollständig zu entfernen.

Sie sollten sich auf die Entfernung von Cross-Site-Cookies vorbereiten, indem Sie die Anzahl der Tracking-Aktivitäten reduzieren, auf die Sie angewiesen sind, und/oder die Beibehaltung der gewünschten Informationen auf andere Weise implementieren. Siehe Übergang von Drittanbieter-Cookies und Ersetzen von Drittanbieter-Cookies für weitere Informationen.

Wenn Sie eine sichere Lösung implementieren, die Datenerfassung beinhaltet, insbesondere wenn es sich um sensible Daten handelt, wie z.B. Anmeldedaten, macht es Sinn, eine seriöse Lösung zu verwenden. Zum Beispiel wird jedes respektable serverseitige Framework über integrierte Funktionen zum Schutz vor häufigen Schwachstellen verfügen. Sie könnten auch in Erwägung ziehen, ein spezialisiertes Produkt für Ihren Zweck zu verwenden, zum Beispiel eine Identitätsanbieterlösung oder einen sicheren Online-Umfrageanbieter.

Wenn Sie Ihre eigene Lösung zur Datenerfassung gewähren wollen, stellen Sie sicher, dass Sie alle Aspekte und Anforderungen verstehen. Heuern Sie einen erfahrenen Entwickler für die Server-Seite und/oder einen Sicherheitsingenieur an, um das System zu implementieren, und sorgen Sie dafür, dass es umfassend getestet wird. Nutzen Sie Mehrfaktor-Authentifizierung (MFA) für besseren Schutz. Ziehen Sie die Verwendung einer dedizierten API wie Web Authentication oder Federated Credential Management in Betracht, um die Client-Seite der App zu optimieren.

Hier sind einige weitere Tipps für sichere Anmeldungen:

• Wenn Sie Anmeldeinformationen von Benutzern sammeln, setzen Sie starke Passwörter durch, damit die Kontodetails Ihrer Nutzer nicht leicht erraten werden können. Schwache Passwörter sind eine der Hauptursachen für Sicherheitsverletzungen. Ermutigen Sie Ihre Nutzer zudem, einen Passwortmanager zu verwenden, damit sie komplexere Passwörter nutzen können, sich keine Gedanken über das Merken machen müssen und kein Sicherheitsrisiko durch Notizen mit ihren Passwörtern schaffen. Siehe auch unseren Artikel über Unsichere Passwörter.

• Sie sollten Ihre Nutzer auch über Phishing aufklären. Phishing ist der Akt, eine Nachricht an einen Benutzer zu senden (beispielsweise eine E-Mail oder eine SMS), die einen Link zu einer Website enthält, die wie eine täglich benutzte Website aussieht, es aber nicht ist. Der Link ist mit einer Nachricht versehen, die darauf abzielt, Nutzer dazu zu verleiten, ihren Benutzernamen und ihr Passwort auf der Seite einzugeben, sodass diese gestohlen und dann von einem Angreifer für böswillige Zwecke genutzt werden können.

  Hinweis: Einige Phishing-Seiten können sehr raffiniert und schwer von einer echten Website zu unterscheiden sein. Sie sollten daher Ihre Nutzer darauf hinweisen, Links in zufälligen E-Mails und SMS-Nachrichten zu misstrauen. Wenn sie eine Nachricht in der Art "Dringend, Sie müssen sich jetzt anmelden, um ein Problem zu lösen" erhalten, sollten sie die Seite in einem neuen Tab direkt besuchen und versuchen, sich direkt anzumelden, anstatt den Link in der Nachricht zu klicken. Oder sie könnten Sie anrufen oder per E-Mail kontaktieren, um die erhaltene Nachricht zu besprechen.

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

• Verwalten Sie Benutzersessions mit einzigartigen Session-IDs und melden Sie Benutzer nach Phasen der Inaktivität automatisch ab.

Generell sollten Sie keine sensiblen Daten in URL-Abfragezeichenfolgen einfügen, denn wenn ein Dritter die URL abfängt (zum Beispiel über den Referer HTTP-Header), könnte er diese Informationen stehlen. Noch ernster ist die Tatsache, dass diese URLs von öffentlichen Web-Crawlern, HTTP-Proxies und Archivierungstools wie dem Internet Archive indexiert werden können, was bedeutet, dass Ihre sensiblen Daten auf öffentlich zugänglichen Ressourcen fortbestehen könnten.

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

Überlegen Sie, webplattformbezogene Funktionen wie die Content Security Policy (CSP) und die Permissions Policy zu nutzen, um auf Ihrer Website eine Reihe von Regeln für die Nutzung von Funktionen und Ressourcen durchzusetzen, die es schwieriger machen, Schwachstellen einzuführen.

CSP erlaubt Ihnen, eine Sicherheitsschicht hinzuzufügen, indem Sie beispielsweise erlauben, dass Bilder oder Skripte nur von bestimmten vertrauenswürdigen Ursprüngen geladen werden. Das hilft, bestimmte Arten von Angriffen zu erkennen und abzuwehren, einschließlich Cross-Site-Scripting (XSS) und Dateninjektionsangriffe. Diese Angriffe umfassen eine Reihe bösartiger Aktivitäten, einschließlich Datendiebstahl, Verunstaltung von Webseiten und Verbreitung von Malware.

Die Berechtigungspolitik funktioniert auf ähnliche Weise, ist jedoch mehr darauf fokussiert, den Zugriff auf spezifische "leistungsstarke Funktionen" zu erlauben oder zu blockieren (wie zuvor erwähnt).

In Anlehnung an den vorherigen Abschnitt sollten Sie, wenn Sie die Nutzung von Funktionen und Ressourcen auf Ihrer Seite erlauben, sicherstellen, dass die Ressourcen nicht manipuliert wurden.

Verwandte Themen:

Subressourcen-Integrität

Die Subressource-Integrität (SRI) ist eine Sicherheitsfunktion, die es Browsern ermöglicht, zu überprüfen, ob Ressourcen, die sie abrufen (zum Beispiel von einem CDN), ohne unerwartete Manipulationen geliefert werden. Es funktioniert, indem Sie einen kryptografischen Hash bereitstellen, den eine abgerufene Ressource erfüllen muss.

HTTP Access-Control-Allow-Origin

Der Access-Control-Allow-Origin Antwort-Header zeigt an, ob die Antwort mit dem anfordernden Code von dem angegebenen Ursprung geteilt werden kann.

HTTP X-Content-Type-Options

Der X-Content-Type-Options Antwort-Header ist ein Marker, der vom Server verwendet wird, um anzuzeigen, dass die MIME-Typen, die in den Content-Type-Headern beworben werden, nicht geändert werden sollten und befolgt werden müssen. Dieser Header ist ein Weg, um sich gegen MIME-Typ-Sniffing zu entscheiden, oder mit anderen Worten, um anzugeben, dass die MIME-Typen absichtlich konfiguriert sind.

Als allgemeine Regel gilt, dass Sie nichts vertrauen sollten, was Benutzer in Formulare eingeben. Das Ausfüllen von Formularen online ist kompliziert und lästig, und es ist einfach für Nutzer, falsche Daten oder Daten im falschen Format einzugeben. Darüber hinaus sind böswillige Personen darin geschickt, spezifische Zeichenfolgen ausführbaren Codes in Formularfelder einzugeben (zum Beispiel SQL oder JavaScript). Wenn Sie nicht aufpassen, wie solche Eingaben gehandhabt werden, könnten sie entweder schädlichen Code auf Ihrer Seite ausführen oder Ihre Datenbanken löschen. Siehe SQL-Injektion 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 desinfizieren:

• Sie sollten clientseitige Validierung implementieren, um Nutzer darüber zu informieren, wann sie Daten im falschen Format eingegeben haben. Sie können dies mit eingebauten HTML-Formularvalidierungsfunktionen tun oder Ihre eigene Validierung schreiben. Siehe Clientseitige Formularvalidierung für mehr Informationen.
• Sie sollten Ausgabecodierung verwenden, wenn Sie Benutzereingaben in einer Anwendungs-UI anzeigen, um Daten sicher genau so anzuzeigen, wie ein Benutzer sie eingegeben hat, und zu vermeiden, dass sie als Code ausgeführt werden. Siehe Output Encoding für mehr Informationen.

Sie können sich nicht allein auf die clientseitige Validierung für die Sicherheit verlassen — sie sollte mit serverseitiger Validierung kombiniert werden. Clientseitige Validierung verbessert die Benutzererfahrung, indem sie sofortiges Validierungsfeedback bietet, ohne auf eine Runde zum Server warten zu müssen. Jedoch ist es für eine böswillige Partei einfach, die clientseitige Validierung zu umgehen (zum Beispiel durch das Abschalten von JavaScript im Browser, um JavaScript-basierte Validierung zu umgehen).

Jedes seriöse serverseitige Framework wird Funktionalität zur Validierung von Formularübermittlungen bereitstellen. Darüber hinaus ist eine weitverbreitete Best Practice, alle speziellen Zeichen, die Teil von ausführbarem Syntax-Code sind, zu "escapen", um eingegebenen Code nicht mehr als ausführbaren und als einfachen Text zu behandeln.

Bei einem Clickjacking-Angriff wird ein Benutzer dazu verleitet, ein UI-Element zu klicken, das eine andere Aktion ausführt als die, die der Benutzer erwartet, was oft dazu führt, dass die vertraulichen Informationen des Benutzers an einen böswilligen Dritten weitergegeben werden. Dieses Risiko ist in eingebettetem Drittanbieterinhalt inhärent, daher stellen Sie sicher, dass Sie den eingebetteten Inhalt auf Ihrer Website vertrauen. Seien Sie sich auch bewusst, dass Clickjacking mit Phishing-Techniken kombiniert werden kann. Sie können über Phishing im vorherigen Abschnitt lesen: Benutzeridentität und Logins verwalten.

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

HTTP X-Frame-Options

Der X-Frame-Options HTTP-Antwort-Header kann verwendet werden, um anzugeben, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern darf. Seiten können dies nutzen, um Clickjacking-Angriffe zu vermeiden, indem sichergestellt wird, dass ihre Inhalte nicht auf andere Seiten eingebettet werden.

CSP: frame-ancestors

Die HTTP Content-Security-Policy (CSP) frame-ancestors Direktive legt gültige Eltern fest, die eine Seite mithilfe von <frame>, <iframe>, <object> oder <embed> einbetten dürfen.

Um umfassende Anleitungen zur effektiven Implementierung von Sicherheitsfunktionen auf Websites zu erhalten und sicherzustellen, dass Sie bewährte Praktiken befolgen, sehen Sie sich unsere Praktischen Sicherheitsimplementierungsguides an.

Einige dieser Guides stehen in direktem Zusammenhang mit dem HTTP Observatory Tool. Observatory führt Sicherheitsüberprüfungen einer Website durch und stellt eine Bewertung und einen Score zusammen mit Empfehlungen zur Behebung der festgestellten Sicherheitsprobleme zur Verfügung. Diese Guides erklären, wie man Probleme löst, die in den MDN Observatory-Tests festgestellt wurden: Das Tool verlinkt auf den relevanten Leitfaden für jedes Problem, um Sie bei einer effektiven Lösung zu unterstützen. Interessanterweise verwenden auch die internen Entwicklerteams von Mozilla diese Anleitungen beim Implementieren von Websites, um sicherzustellen, dass Sicherheitsbestpraktiken angewendet werden.

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