Das Web sicherer machen (Ausblick)

Wir haben uns daran gewöhnt, bei der Nutzung von Webdiensten und webbasierten Anwendungen ein angemessenes Maß an Datenschutz und Sicherheit zu erwarten. Denn diese Dienste betreffen alle Bereiche unseres täglichen Lebens – von Geld und Finanzen über die Nutzung staatlicher Angebote und unsere eigene Bildung oder die unserer Kinder bis hin zur Kommunikation mit Freunden und Familie, zur Gesundheitsversorgung und ganz einfach zum Kauf unserer Lebensmittel. Die gravierenden Folgen fehlender Sicherheit haben wir bereits erlebt: von massiven Passwortlecks bis zur Verbreitung von Malware, Spyware und Ransomware. In den vergangenen Jahren habe ich viel Zeit mit dem Thema Datenschutz für Nutzer verbracht. Wenn wir mit all diesen Diensten interagieren, müssen wir darauf vertrauen können, dass geeignete Datenschutz- und Sicherheitskontrollen zum Einsatz kommen. Grundsätzlich bedeutet das verschlüsselte Verbindungen (zum Beispiel mit HTTPS). Dazu gehören auch der angemessene Schutz ruhender Daten sowie der korrekte Einsatz von Sicherheits- und Kryptografiealgorithmen.

2014 veranstaltete ich einen Branchenworkshop zur Stärkung des Internets gegen die Bedrohung durch umfassende Überwachung. Zu den Forderungen gehörte unter anderem der Umstieg auf HTTPS. Dank der Bemühungen von Unternehmen, Organisationen und vielen Einzelpersonen wird heute der weitaus größte Teil des Webs über HTTPS genutzt. Diese gemeinsame Brancheninitiative trägt der Tatsache Rechnung, dass Sicherheit eine Voraussetzung für Datenschutz ist. Sie können eine datenschutzfreundliche Anwendung entwerfen. Wird sie jedoch nicht in einer sicheren Umgebung entwickelt und bereitgestellt und sind ihre Kommunikationskanäle nicht bis hin zur Benutzeroberfläche angemessen geschützt, ist sie angreifbar. Diese Angriffsfläche wird zunehmend von böswilligen Akteuren ausgenutzt. Ein Blick auf die jüngste Welle von Phishing-, Malware- und Ransomware-Angriffen genügt, um zu erkennen, dass wir ein Problem haben.

Mehr als sichere Datenübertragung

Nachdem wir das Problem der sicheren Datenübertragung nun „gelöst“ haben (oder auf dem Weg dorthin sind), stellt sich die Frage: Wo liegen die anderen Angriffsflächen? Auf Serverseite gibt es Schwachstellen wie log4j, die böswillige Akteure für Angriffe auf Java-API-Endpunkte genutzt haben. Clientseitige Schwachstellen (zum Beispiel Cross-Site-Scripting-Schwachstellen) gefährden Interaktionen mit Webanwendungen, die Nutzern angezeigt werden. Cross-Site-Scripting-Schwachstellen nutzen die Interaktion zwischen der JavaScript-Umgebung und dem Document Object Model im Webbrowser (oder in der Webansicht einer verpackten Anwendung) aus. Solche clientseitigen Angriffe können private Daten eines Nutzers für Angreifer zugänglich machen oder, schlimmer noch, in seinem Namen Aktionen ausführen. Dieses Muster ist der Funktionsweise des Webs (und vieler Apps) inhärent. Ob es uns gefällt oder nicht: Mit einem Fingertipp können wir Code von beliebigen Drittanbietern herunterladen und ausführen. Selbst wenn Sie den betreffenden Drittanbieter kennen und ihm vertrauen, kann sein Code Schwachstellen enthalten – insbesondere, wenn er in der Praxis neben dem Code vieler anderer Anbieter ausgeführt wird. Und bei Phishing-Angriffen können böswillige Akteure das Vertrauen der Nutzer leicht missbrauchen.

Software-Lieferkette

Die meisten Softwareprojekte sind auf Abhängigkeiten angewiesen. Paketmanager wie npm sollen den Umgang damit erleichtern. In NPM beschreibt die Datei package.json Ihr Projekt einschließlich seiner Abhängigkeiten. Da sie jedoch nur direkte Abhängigkeiten aufführt, hilft sie nur bedingt bei der Analyse der gesamten Software-Lieferkette. Entwickler denken möglicherweise nicht gerne in Begriffen der Lieferkette über die Softwareentwicklung nach – schließlich stammt dieses Konzept eigentlich aus der Wirtschaft. (Und wie ich bereits geschrieben habe, können sich manche Entwickler an dieser Terminologie stören.) Vielleicht fragen Sie sich: „Muss jetzt jeder Softwareentwickler zum Sicherheitsexperten werden?“ Die Antwort lautet: Ja, irgendwie schon. Zumindest müssen Entwickler, die mit verschiedenen Programmiersprachen und auf unterschiedlichen Ebenen des Stacks arbeiten, die Grundlagen der Sicherheit kennen und sich damit vertraut machen.

Wer sich mit der Sicherheit von Open-Source-Abhängigkeiten befassen möchte, findet einen guten Einstieg im kompakten Leitfaden für die Entwicklung sichererer Software der OpenSSF. Diese Checkliste enthält grundlegende Sicherheitsmaßnahmen, etwa sicherzustellen, dass alle Entwickler beim Committen von Code eine Multi-Faktor-Authentifizierung verwenden, sowie Tools für die Schwachstellensuche und -überwachung einzusetzen, die Lösungsvorschläge bieten (wie das Tool von Snyk).

Fortgeschrittene Sicherheitsspezifikationen

Ein weiterer Entwicklungsbereich der Webanwendungssicherheit sind Web-APIs, die erweiterte Funktionen mit zusätzlichen Sicherheitsvorkehrungen ermöglichen. Die Schwachstelle „Spectre“ etwa setzte Webanwendungen, die einen SharedArrayBuffer verwendeten, Angriffen auf Prozessorebene aus. Dadurch konnten Daten zwischen Kontexten offengelegt werden, die normalerweise als sicher gelten (Cross-Origin). Als Reaktion darauf entwickelte die Webstandards-Community cross-origin-opener-policy und cross-origin-embedder-policy. Dies ist nur ein Beispiel für zahlreiche neue Spezifikationen und APIs, die an verschiedenen Stellen entwickelt wurden, um die Sicherheit fortgeschrittener Web-APIs zu verbessern und solche Angriffe einzudämmen. Aufgrund der Komplexität des Problems und der Feinheiten mancher Ansätze (zum Beispiel der Konfiguration von HTTP-Headern für COOP und COEP) ist es jedoch nach wie vor schwierig, Entwickler mit diesen Spezifikationen vertraut zu machen.

Ein Zitat eines Entwicklers aus der MDN-Web-DNA-Umfrage von 2020 bringt es auf den Punkt:

Auch wenn ich noch am Anfang meiner Programmierreise stehe, ist Sicherheit … im Internet weiterhin meine größte Sorge. Ich persönlich finde, dass die komplizierte Fachsprache, mit der die Funktionsweise der Websicherheit in der modernen Welt beschrieben wird, es neuen Programmierern besonders schwer macht, sich mit den bewährten Sicherheitspraktiken vertraut zu machen und sie umzusetzen – selbst wenn man auf Lösungen von Drittanbietern zurückgreift.

Wir müssen Webentwickler besser dabei unterstützen, bewährte Sicherheitspraktiken umzusetzen.

Was wir hier haben …

Wer sich sowohl in der Webentwickler-Community als auch in der DevSecOps-Community bewegt, erkennt schnell, wie dringend wir mehr Austausch brauchen. Webentwickler müssen die Botschaft und Denkweise rund um die Software-Lieferkette (Abhängigkeiten) verinnerlichen und Sicherheitsanalysen stärker in den Mittelpunkt rücken. Die Entwickler-Community, die sich bereits mit Sicherheitsthemen befasst, muss diese Botschaft an weitere Entwickler herantragen und die Risiken für Endnutzer im Zusammenhang mit Sicherheit (etwa den Datenschutz) stärker berücksichtigen. So wird deutlich, warum DevSecOps so wichtig ist.

Webentwickler sollten sich aktiv mit dem Thema Sicherheit befassen – nicht nur als Anwender. Ich würde mir wünschen, dass mehr Webentwickler mit uns in der OpenSSF zusammenarbeiten. In der Arbeitsgruppe für Best Practices der OpenSSF erstellen wir beispielsweise Richtlinien zu bewährten Konfigurationen für Plattformen zur Verwaltung von Quellcode (z. B. Github, Gitlab) und behandeln weitere Themen. Ein weiteres Beispiel sind die OpeSSF-Scorecards, mit denen sicherheitsbezogene Aspekte von Open-Source-Repositories bewertet werden. In diesen Diskussionen haben uns bisher die Stimmen aus der Webentwickler-Community gefehlt. Da sich diese Community tendenziell stärker auf Fragen des Datenschutzes für Nutzer konzentriert, hatten diese Themen bei der Arbeit der OpenSSF weniger Gewicht, als meiner Meinung nach angemessen wäre. Deshalb habe ich einen Branchenworkshop ins Leben gerufen, der diese Communities zusammenbringen soll, um „das Web sicherer zu machen“.

Der offene Branchenworkshop findet am 7. und 8. Juni in London statt. Er soll einige dieser Stimmen zusammenbringen und hoffentlich neue Arbeit anstoßen. Die Frist für die Einreichung von Beiträgen (CfP) endet am 24. April. Der Workshop steht auch sicherheitsbewussten Webentwicklern offen.