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.
Der 2012 entwickelte Sicherheitsmechanismus CSP, der vor allem die Risiken sogenannter Cross-Site-Scripting-Angriffe verringern soll, erweist sich trotz mehrerer Überarbeitungen noch immer als stumpfes Schwert im Kampf gegen Cyber-Attacken. „Dabei kann eine CSP sehr wohl funktionieren – und dann ist der Mechanismus super“, erklärt Sebastian Roth. Drängt sich die Frage auf, warum es bislang noch mehr Probleme als Nutzen gibt. „Das wird schon seit vielen Jahren erforscht. Bisher hat aber niemand die Entwickler:innen gefragt, wo für sie eigentlich die Hindernisse 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 dieses Versäumnis nachgeholt und in einer Studie mit zwölf Entwickler:innen einige praktische Probleme aufgedeckt.
Doch zunächst zu Sinn und Funktion des Sicherheitsmechanismus CSP: 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 solche Angriffe entsteht, weil viele Seitenbetreiber:innen externe 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 welchen Quellen Code geladen werden darf und von welcher nicht.
„Eigentlich müssen Entwickler:innen dazu nur eine Liste aller erlaubten 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 oft in ihren Code den Code weiterer Webseiten ein, die ebenfalls in die Liste mitaufgenommen werden müssen, damit alles reibungslos klappt. Welche das sind ist laut Roth für Entwickler:innen oft gar nicht so klar ersichtlich.
„Verschiedene Webbrowser unterstützen zudem den Sicherheitsmechanismus auch 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 gemeldeten Informationen sind. 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 außerdem 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 in der Forschung schon bekanntes Problem ist: Ein reibungsloses Funktionieren der CSP erfordert oft, 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 für dieses grundsätzliche Problem 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, hat 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 hin zu mehr Websicherheit machen.“
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.“
