Wie Drittanbieter-Dienste oft mit Sicherheitsmechanismen von Webseiten kollidieren

Werbung ist im Internet seit Jahren omnipräsent. Für Seitenbetreiber:innen ist sie oft das Mittel der Wahl, um mit ihren Web-Inhalten Geld zu verdienen. Werbeanzeigen und andere Drittanbieterdienste kollidieren allerdings oft mit den Sicherheitsmechanismen der Seiten. Die Betreiber:innen müssen sich dann zwischen nützlichen Features und IT-Sicherheit entscheiden. Das hat CISPA-PHD-Student Marius Steffens zusammen mit Marius Musch und Martin Johns von der TU Braunschweig unter der Leitung von Faculty Ben Stock herausgefunden. Die Ergebnisse ihrer Untersuchung „Who’s hosting the Block Party? Studying Third-Party Blockage of CSP und SRI“ haben die Forscher jüngst auf der Konferenz Network and Distributed System Security (NDSS) vorgestellt, einer der wichtigsten Cybersicherheitskonferenzen weltweit.

Oben ein Werbebanner, am rechten Rand ein Live-Chat-Formular für Fragen und ganz unten noch eine Anfahrtskarte von Google: In fast jeder Seite im Web steckt laut Marius Steffens Code, der nicht von den Seitenbetreiber:innen oder -entwickler:innen selbst, sondern von Dritten stammt. Die Einbindung von Drittanbieter-Diensten ist für die Seitenbetreiber:innen oft essentiell, weil sie einen Großteil ihres Geldes mit Werbung verdienen. Zum anderen können sie ihren Besucher:innen so zusätzliche Funktionen anbieten. Dass im Netz Vieles miteinander verbunden ist, sei für die Endanwender:innen sehr angenehm, erklärt Steffens. Für die Seitenbetreiber:innen stelle die Einbindung von Drittanbieter-Diensten allerdings häufig ein Sicherheitsrisiko dar, sagt der 24-Jährige, der seit 2018 am CISPA im Team von Faculty Ben Stock forscht. 

Über 8000 populäre Seiten haben er und das Forscherteam in einer Verlaufsstudie über einen Zeitraum von zwölf Wochen untersucht. Sie haben festgestellt, dass mehr als 70 Prozent der Seiten Code von Drittanbieter:innen enthält, der die Funktionalität einer sogenannten Content Security Policy (CSP) einschränken würde, auch wenn die Seitenbetreiber:innen selbst ihren Code extra daran anpassten. Das Sicherheitskonzept CSP soll Angriffe wie das sogenannte Cross-Site-Scripting (XSS) verhindern. Beim XSS versuchen Angreifer:innen, Schadcode in den Code vermeintlich vertrauenswürdiger Webseiten, etwa in den einer Bankseite, einzuschleusen und damit vertrauliche Informationen wie Passwörter von Nutzer:innen zu erbeuten. „Solche Angriffe können verheerende Auswirkungen haben“, sagt Steffens. Einer der bekanntesten Fälle ist der des sogenannten MySpace-Wurms Samy aus dem Jahr 2005, mit dem ein junger Hacker sich eine Million Freunde auf der Social-Media-Plattform verschaffte und ebenso viele Konten mit einem vergleichsweise harmlosen Virus verseuchte. MySpace musste den Betrieb vorübergehend komplett einstellen, um die Profile zu reinigen. Eine CSP könne solche Angriffe unterbinden, indem sie festlegt, von welcher Quelle Code ausgeführt werden darf, und von welcher nicht. „Ist die CSP richtig konfiguriert, verhindert der Browser den Angriff“, erklärt Steffens. Soweit die Theorie.

Seit seiner Einführung wurde das Sicherheitskonzept CSP zwar stetig weiterentwickelt und es wurden weitere Funktionen hinzugefügt. Dennoch funktioniere es für die Webseitenbetreiber:innen in der Praxis nicht so, wie sie es brauchen, sagt Steffens. Standardmäßig blockiere der Mechanismus zum Beispiel sogenannte Inline-Skripte, also solche, die sich direkt im Code befinden. Dass Entwickler:innen diese aber oftmals nutzen wollen, führe dazu, dass die Entwickler:innen zu diesem Zweck die Funktionen ihrer CSP einschränken und dadurch Angriffe nicht mehr verhindert werden können, sagt Steffens.

Sicherheitsprobleme gibt es auch beim zweiten im NDSS-Paper untersuchten Mechanismus Subresource Integrity (SRI), der Erstanbieter:innen und ihre Seiten vor ungewollten Änderungen der importierten Skripte schützen soll, falls etwa einer der Drittanbieter:innen angegriffen wurde. Bei mehr als der Hälfte aller untersuchten Seiten ist dies laut der Forscher zumindest nur eingeschränkt möglich. Mit SRI wird festgelegt, dass der von Drittanbieter:innen eingebundene Code nur dann ausgeführt wird, wenn er unverändert in einer gewissen Form vorliegt. In der Praxis ändere sich an den Skripten aber ständig etwas, sagt Steffens. Sie würden fortlaufend aktualisiert, aber schon kleinste Änderungen der Skripte führten dazu, dass SRI ihre Ausführung verhindert. Zudem könnten die Skripte selbst wiederum andere enthalten und aufrufen, die nicht von SRI überprüft wurden und somit deren Funktionalität aushebeln. Auch hier kollidieren also Theorie und Praxis, wodurch sich die Webseitenbetreiber:innen häufig gezwungen sehen, IT-Sicherheit aufzugeben und den gewünschten Features den Vorzug zu geben.

„Drittanbieter müssen sich im Klaren sein, welchen Einfluss sie auf die Sicherheit des Webs haben“, sagt Steffens. Außerdem müsse sich die Sicherheits-Community Gedanken machen, wie die Mechanismen so angepasst werden können, dass sie für die Entwickler:innen auch in der Praxis vernünftig nutzbar sind, so das Fazit des Forschers.