E-mail senden E-Mail Adresse kopieren
2021-11-23
Annabelle Theobald

Zu komplex, zu aufwendig, zu teuer

Eine Content-Security-Policy (CSP) auf Webseiten zu installieren, könnte ein echter Gamechanger in Sachen Websicherheit sein. Könnte – denn noch gibt es damit zu viele Probleme. Oft scheitert ein sinn- und wirkungsvoller Einsatz des Sicherheitsmechanismus bereits daran, dass Webseiten-Entwickler:innen Fehler beim Konfigurieren machen. Wo genau die Fallstricke für Entwickler:innen liegen, haben die CISPA-Forscher:innen Sebastian Roth und Lea Gröber erstmals in einer qualitativen Studie beleuchtet. Ihr Paper „12 Angry Developers – A Qualitative Study on Developers’ Struggles with CSP“ stellen sie auf der renommierten Sicherheitskonferenz CCS vor.

Der 2012 entwickelte Sicherheitsmechanismus CSP, der vor allem die Risiken sogenannter Cross-Site-Scripting-Angriffe verringern soll, erweist sich auch nach vielen Jahren und mehreren Überarbeitungen als stumpfes Schwert im Kampf gegen die Attacken. „Dabei kann CSP funktionieren – und dann ist der Mechanismus super“, erklärt Sebastian Roth. Warum es bislang mehr Probleme als Nutzen gibt, wird seit vielen Jahren erforscht. „Bisher hat aber niemand die Entwickler:innen gefragt, wo für sie eigentlich die Probleme beim Ausrollen einer CSP liegen“, sagt Roth, der in der Forschungsgruppe von CISPA-Faculty Dr. Ben Stock forscht. Zusammen mit Lea Gröber aus der Usable-Security-Gruppe von CISPA-Faculty Dr. Katharina Krombholz hat Roth das nachgeholt und in einer Studie mit zwölf Entwickler:innen einige praktische Probleme aufgedeckt.

Doch zunächst zu Sinn und Funktion des Sicherheitsmechanismus: Eine der häufigsten Angriffsarten im Web und damit ein großes Sicherheitsrisiko für Nutzer:innen ist das sogenannte Cross-Site-Scripting (XSS), bei dem Angreifer:innen Webseiten bösartigen Code unterschieben. Gelingt ihnen das, können sie Zugriff auf sensible Nutzer:innen-Daten wie Passwörter oder Kreditkartennummern erhalten.

Ein Einfallstor für Angriffe entsteht, weil viele Seitenbetreiber:innen Dienste – zum Beispiel Werbung, Karten oder Bezahldienste – und damit fremden Code auf ihren Seiten einbinden. Dieser muss vom Webbrowser immer wieder nachgeladen werden, um ihn aktuell zu halten, erklärt Roth. „Viele Seiten haben allerdings Schwachstellen in ihrem Code oder dem der Drittanbieter:innen, die den Browser denken lassen, nachzuladender Code stamme aus einer legitimen Quelle, während es sich in Wahrheit um Schadcode handelt.“ Mit einer CSP können Entwickler:innen das verhindern und genau festlegen, von welcher Quelle Code geladen werden darf und von welcher nicht.

„Eigentlich müssen Entwickler:innen dazu nur eine Liste erlaubter Quellen anlegen.“ Das hört sich simpel an, ist es aber in der Praxis nicht, wie Roths und Gröbers Studie zeigt. Alleine das Zusammentragen der verschiedenen Quellen, aus denen Code geladen werden soll, sei in den Unternehmen oft komplizierter als gedacht, weil für das Design und den Inhalt der Seiten unterschiedliche Entwickler:innen-Teams zuständig sind und ein reibungsloser Ablauf nur dann gewährleistet ist, wenn alle wichtigen Informationen an einer Stelle zusammenlaufen. Zudem binden Drittanbieter:innen selbst oft Code weiterer Webseiten ein, die ebenfalls in die Liste mitaufgenommen werden müssen, damit alles klappt. Welche das sind ist laut Roth oft gar nicht so klar ersichtlich.

„Verschiedene Webbrowser unterstützen zudem den Sicherheitsmechanismus unterschiedlich. Unsere Studie hat gezeigt, wie problematisch das für die Entwickler:innen sein kann.“ Zum Beispiel hat das Auswirkungen darauf, wie den Entwickler:innen Fehler gemeldet werden und wie nützlich die Informationen sind, die die Meldungen für sie bereithalten. In einigen Browsern produzieren zudem Extensions – sie ermöglichen zusätzliche Funktionen – Fehlermeldungen, denen nachzugehen für Entwickler:innen einen enormen zeitlichen Aufwand darstellt. „Damit wird die CSP auszurollen schnell auch zur finanziellen Frage für die Unternehmen.“

Vielen Entwickler:innen sei zudem nicht klar, welche Funktionen die CSP bereithält und wogegen genau sie schützt. „Wenn Entwickler:innen eine falsche Vorstellung haben, wo und wie die CSP wirkt, machen sie Fehler.“ Es mangelt laut Roth an haltbaren Quellen, die entsprechend aufbereitete Informationen bereithalten. „Eine Art FAQ würde helfen“, sagt Roth. Infos aus schlechten Quellen führten die Entwickler:innen bislang bei ihrer Arbeit immer wieder in die Irre.

Ein weiteres großes, aber bereits bekanntes Problem ist, dass ein reibungsloses Funktionieren der CSP oft erfordert, dass Programmcode von den Entwickler:innen umgebaut werden muss – und das nicht nur auf der eigenen Seite, sondern auch bei den Drittanbieter:innen. „Die haben aber oft gar kein Interesse hier Zeit und Mühe zu investieren“, sagt Roth. „Die Mentalität vieler Unternehmen ist leider oft die: Security ist ein gern genommener Zusatz, aber nichts, was man haben muss.“ Eine Lösung hierfür zu finden, sei eine der größten Herausforderungen, sagt Roth.

Er ist überzeugt, dass CSP künftig einen großen Schritt zu mehr Websicherheit bedeuten kann. „Bisher gibt es aber leider noch zu viele Baustellen.“ Das World Wide Web Consortium, ein Gremium, das neue Techniken im Word Wide Web standardisiert und eine Empfehlung für CSP ausspricht, hatte Roth und Gröber kürzlich zum Gespräch eingeladen, wo die Nachwuchsforscher:innen diese und weitere Ergebnisse ihrer Studie vorstellten. „Die technischen Probleme alle zu beheben, wird wahrscheinlich noch dauern, aber an der Kommunikation kann man jetzt schon arbeiten und damit einen wichtigen Schritt zu mehr Websicherheit machen.“