Sicherheitsrisiken durch JavaScript-Skripte von Drittanbietern

In ihrem Vortrag zur Websicherheit auf der SnykCon 2020 erörterten Liran Tal und Eric Graham Sicherheitsaspekte im Frontend und die dortige Angriffsfläche. Sie veranschaulichten die Risiken durch Sicherheitslücken in Abhängigkeiten von Drittanbietern und zeigten anschließend, wie marketingbezogene Skripte von Drittanbietern, etwa der Google Tag Manager, das potenzielle Sicherheitsrisiko vergrößern.

Dieser Artikel beleuchtet Sicherheitsrisiken durch marketingbezogene Skripte auf Websites, etwa für A/B-Tests, Google Analytics und weitere Dienste, und zeigt Möglichkeiten auf, diese Risiken zu mindern.

Play Video: Securing Front-end Attack Surfaces - Eric Graham and Liran Tal

Welche Sicherheitsbedenken gibt es bei Skripten von Drittanbietern im Bereich Websicherheit?

Um diese Frage zu beantworten, zeigt Eric Graham im Video Schritt für Schritt, wie Code von Drittanbietern in Webanwendungen und statische Websites eingebunden wird. Dabei veranschaulicht er, in welchem Umfang darin Quellcode von verschiedenen Anbietern und Open-Source-Maintainern enthalten ist.

Wie Sie sehen, macht der von Ihrem Team entwickelte Code nur einen kleinen Teil des gesamten Codes aus, der an Ihre Kunden ausgeliefert wird. Daneben finden Sie Skripte für A/B- oder Usability-Tests sowie für Marketing- und Vertriebsaufgaben wie die Segmentierung von Nutzern oder die Optimierung des Sales-Funnels.

Wie und warum werden Skripte von Drittanbietern in eine Website eingebunden?

Erschwerend kommt hinzu, dass diese Skripte meist von Marketing- und Webmanagern außerhalb des Softwareentwicklungszyklus und der CI/CD-Pipeline eingebunden werden. So umgehen sie vollständig die Code-Reviews und Tests der Entwickler. Die dafür verwendete Software heißt Tag-Manager. Bekannte Anbieter sind Google (GTM) und Adobe mit Launch, dem Nachfolger des Dynamic Tag Manager (DTM).

Diese Tag-Manager laden wiederum weitere Skripte, wodurch noch mehr HTTP-Verbindungen zu verschiedenen Domains geöffnet werden. Diese Domains könnten gehackt werden, sodass Malware eingeschleust wird. Damit bewegen wir uns im Bereich Malvertising.

Marketingfachleute und Analytics Engineers verwenden regelmäßig JavaScript-Skripte von Drittanbietern, um eine Website für Growth Hacking und die Segmentierung von Nutzern zu erweitern und den Sales-Funnel zu optimieren. Ein bekanntes Beispiel dafür ist der viel genutzte GTM oder Adobes Launch, der eine deutliche Verbesserung gegenüber seinem Vorgänger Dynamic Tag Manager (DTM) darstellt.

Angesichts der geschäftlichen Bedeutung dieser Skripte für die Marketing-Pipeline bevorzugen Produktmarketing- und Analytics-Teams schnelle Experimente und das Einbinden solcher Zusatzskripte in eine Website oder Webanwendung.

Werden diese Marketing-Skripte von Drittanbietern einer Sicherheitsprüfung unterzogen?

Denken diese Teams daran, Skripte von Drittanbietern aus der Webanwendung zu entfernen, sobald sie nicht mehr benötigt werden? Das ist oft nicht sichergestellt und kann durchs Raster fallen. So führen Sie möglicherweise nicht vertrauenswürdigen Code aus, ohne es überhaupt zu wissen!

Diese Aktivitäten rund um JavaScript-Skripte von Drittanbietern, die in eine Webseite eingebunden werden, umgehen die DevOps-Pipeline und sämtliche Sicherheitsprozesse oder -richtlinien, die während der Entwicklung eingeführt wurden.

Da diese Skripte direkt in das DOM eingefügt werden, erhalten Dritte außerdem Zugriff auf alle Funktionen, die auch Ihren Entwicklern zur Verfügung stehen. Das kann Ihren Kunden erheblichen Schaden zufügen.

Die Medien haben über mehrere Sicherheitsvorfälle berichtet, bei denen JavaScript-Skripte von Drittanbietern böswillig in Webanwendungen eingeschleust wurden. Auch darüber, wie Hacker einen Web-Skimmer in den CSS-Dateien einer Website verstecken, wurde berichtet. Zuvor hatte es bereits Sicherheitsvorfälle mit Magecart-Skripten gegeben, die in Favicons, Live-Chat-Nachrichten und Social-Media-Buttons eingebettet waren.

Lassen sich Sicherheitsrisiken durch JavaScript von Drittanbietern beheben?

Um unsere Bedenken hinsichtlich der JavaScript-Sicherheit auszuräumen, sehen wir uns bessere Möglichkeiten an, JavaScript von Drittanbietern in eine Website-Codebasis einzubinden und so Sicherheitsrisiken zu mindern oder zu reduzieren.

Technische Ansätze

Eine Möglichkeit ist, JavaScript von Drittanbietern in einem iFrame einzubinden und diesen anschließend mithilfe von Allow- und/oder Sandbox-Attributen einzuschränken. Beachten Sie, dass dadurch die vorgesehene Funktionalität beeinträchtigt werden kann.

Eine weitere Möglichkeit ist die Anwendung von Subresource Integrity (SRI). Dafür muss der Anbieter der Skripte jedoch Hash-Werte für die bereitgestellten Bibliotheken zur Verfügung stellen. Leider sind die Inhalte oft personalisiert und daher dynamisch.

Die W3C-Arbeitsgruppe hat im folgenden Dokument einen Standard für die Erfassung von Kennzahlen zum Nutzerverhalten und weiteren Anforderungen vorgeschlagen: Customer Experience Digital Data Layer 1.0. In Abschnitt 6.11 wird festgelegt, welche Gruppen von Skripten Dritter auf welche Datentypen zugreifen dürfen. Die Durchsetzung dieser Vorgaben bleibt jedoch der für die Datenebene verantwortlichen Stelle überlassen.

Kulturelle Ansätze

Da technische Ansätze nicht ausreichen, sehen wir uns kulturelle Maßnahmen an.

Sollte Marketing Teil des Softwareentwicklungsprozesses werden und Änderungen über eine DevOps-Pipeline bereitstellen müssen? Die Zusammenarbeit mit Entwicklern ist ideal, lässt sich aber in Bezug auf geschäftliche Prioritäten und die abteilungsübergreifende Kommunikation nicht einfach umsetzen.

Überwachen Sie aktiv alle HTTP-Anfragen Ihrer Webanwendung oder Domain? Sie können Tools wie Akamais Page Integrity Manager oder das kostenlose Open-Source-Webtool WebPageTest verwenden, um HTTP-Anfragen zu überwachen und die Überwachung sogar in Ihre Continuous-Integration-Pipeline (CI) einzubinden.

Schließlich kann die Unternehmenskultur dazu beitragen, bei Entwicklern und Marketingfachleuten ein stärkeres Bewusstsein für den Datenschutz zu fördern, wenn sie Analytics und andere JavaScript-Widgets von Drittanbietern einsetzen.

Fazit

Die Angriffsfläche im Frontend ist groß. Sie beginnt beim Quellcode Ihrer eigenen Webanwendung und ihren Abhängigkeiten und reicht bis zu Skripten von Drittanbietern, die außerhalb des Entwicklungsprozesses eingebunden werden.

Neben technischen Ansätzen sollten Sie auch einen Kulturwandel anstreben, um im Internet sicher zu bleiben.

Weitere Informationen finden Sie in diesen Ressourcen:

1. Erfahren Sie mehr über den Trend zur ereignisgesteuerten Architektur in Jim Gordons Blogbeitrag: https://jimalytics.com/tag-management/the-event-driven-data-layer.

2. Lesen Sie Jan Exners Blog unter https://webanalyticsfordevelopers.com. Dort erklärt er Webanalysen für Entwickler auf eine Weise, die für Engineers verständlich ist.

3. Sehen Sie sich den Vortrag Securing Frontend Attack Surfaces von der SnykCon an, der das Ausmaß dieses Sicherheitsrisikos erläutert.