Seite 3: Einsatz eines Privacy Proxy

Inhaltsverzeichnis

Ein Privacy Proxy ist eine relativ junge Technik, die sich am Markt noch nicht vollständig durchgesetzt hat. Primär liegt das daran, dass die meisten Cloud-Tool-Anbieter Entwicklern ausschließlich Ressourcen von ihren eigenen Servern anbieten wollen, die sie auch selbst kontrollieren. Die Motivation für dieses Vorgehen ist nachvollziehbar, wenn die Anbieter damit sicherstellen wollen, dass sie so kurze Releasezyklen einhalten und schnelle Updates der Ressourcen vornehmen können. Sind hingegen die Metadaten der Verbindung der Endkunden wie IP-Adresse, Browserversion oder Fingerprint das eigentliche Ziel dieser Vorgehensweise, wird die Abneigung der Anbieter gegenüber Privacy Proxys nachvollziehbar.

Ein Privacy Proxy setzt auf das altbewährte Konzept einer Server-zu-Server-Verbindung. Daten der Endkunden gehen ausschließlich an einen vertrauenswürdigen Server des Webanwendungsbetreibers, der dann die Daten filtert und kontrolliert weiterleitet. Eine direkte Kommunikation zwischen Endkunden und 3rd-Party-Provider findet nur in absoluten Ausnahmefällen statt. Alle weitergeleiteten Daten sind durch die Betreiber der Webanwendung kontrollierbar und revisionssicher nachweisbar.

Ein dafür geeignetes Tool auf Basis von Java und Spring Boot hat beispielsweise die Techniker Krankenkasse als Open-Source-Projekt auf GitHub bereitgestellt. Eine Beispielkonfiguration, die die Basis-Library verwendet und für eigene Projekte dienen kann, findet sich ebenfalls auf GitHub. Java-Kenntnisse sind nicht zwingend erforderlich. Das Konzept sollte sich relativ einfach auch auf anderen Plattformen wie Node.js umsetzen lassen, sofern sie Scheduling- beziehungsweise Cron-Support anbieten.

Der Privacy Proxy stellt darüber hinaus beliebige Ressourcen von 3rd-Party-Providern lokal bereit und aktualisiert diese regelmäßig automatisch. Die Aktualität der Ressourcen ist damit auch ohne die direkte CDN-Einbindung gegeben. Somit bleibt auch die Auslieferung von 3rd-Party-Ressourcen ein Teil der originären Domain. 3rd-Party-Cookies bieten damit keine Möglichkeit, Daten unkontrolliert abfließen zu lassen. Sämtliche Daten werden als 1st-Party-Cookies gesetzt und sind nur durch Requests über den Privacy Proxy zugänglich.

Der Rückkanal zum 3rd-Party-Provider erfolgt ebenfalls über den Privacy Proxy, vorausgesetzt der Anbieter stellt die Möglichkeit zur Verfügung, die Domain für Tracking- und Analytics-Requests zu verändern. Das ist zwar nicht selbstverständlich, Unternehmen können schlimmstenfalls jedoch immer eine Anpassung der 3rd-Party-Ressourcen selbstständig vornehmen. In der Praxis ist davon jedoch abzuraten, eine Konfiguration von außen ist generell vorzuziehen. Gerade nicht in der EU ansässige Anbieter sind dabei häufig unkooperativ, da sie keinen Bedarf für einen solchen Anwendungsfall sehen oder dieser den Unternehmenszielen widerspricht.

Sicherheit und Stabilität steigern mit Privacy Proxys

Ein Privacy Proxy bietet eine Reihe von Vorteilen, die jedoch erst die Grundlage für weitreichendere Maßnahmen wie Content Security Policies, Audits oder Qualitäts- und Sicherheitschecks sind, und die im Folgenden näher betrachtet werden sollen.

Content Security Policies (CSPs)

Erfolgt das Einbinden sämtlicher Ressourcen von der eigenen Domain (also lokal) und läuft die komplette Kommunikation zu den Drittanbietern über die lokale Domain, lassen sich CSPs relativ einfach konfigurieren. Die häufig aufwendige und lästige Arbeit der Analyse aller externen Quellen und Domains entfällt. Die einzig freizugebende Domain ist die eigene (= "self"). Jegliche Kommunikation mit anderen Domains sollten Entwickler vollständig unterbinden. Selbst bei Kompromittierung externer Ressourcen ist ein Datenabfluss erheblich erschwert und nahezu ausgeschlossen. Breit angelegte Angriffe auf einen globalen Anbieter haben bei der eigenen Webanwendung dann kaum Erfolg. Einzig maßgeschneiderte und gezielte Angriffe vermögen noch einen Weg vorbei an den CSPs zu finden.

Dennoch verbleiben nach wie vor Ressourcen, die ein externes Whitelisting erforderlich machen – darunter Karten- beziehungsweise Navigationsanwendungen und andere komplexe Funktionen mit zahlreichen externen Includes. Ist ein Privacy Proxy implementiert, betrifft dies nur noch wenige Ressourcen. Darüber hinaus unterbinden strikte CSPs auch das Nachladen (Piggy Backing) weiterer Skripte effizient. Wenn ein 3rd-Party-Provider nicht sauber und transparent arbeitet, ist sein Produkt in einer strikt konfigurierten CSP-Umgebung zum Scheitern verurteilt. Whitelisting ist gegenüber Blacklisting stets als sicherer zu bevorzugen.

Audits und Nachvollziehbarkeit

Legt man lokale Kopien von externen Ressourcen an, lassen sie sich versionieren und revisionssicher archivieren. In einem typischen 3rd-Party-CDN-Szenario ist es hingegen unmöglich nachzuweisen, welcher Code-Stand zu welchem Zeitpunkt deployt war. Ein lokales Archiv ist dabei eine große Hilfe.

Qualitäts- und Sicherheitschecks

Auch Drittanbieter machen Fehler. Liefern sie Ressourcen aus, die für den Betrieb der Webanwendung notwendig, jedoch fehlerhaft sind, erweist sich das in den meisten Fällen als Blocker mit externer Abhängigkeit – ein Worst-Case-Szenario. Liegen die vorangegangenen Versionen der Ressourcen jedoch in einem lokalen Archiv vor, lässt sich ein Rollback wie mit eigenem Code vergleichsweise einfach umsetzen – in der Regel sogar ohne, dass der externe Dienstleister reagieren muss.

Etwaige Fehler oder anderweitig negative Auswirkungen durch 3rd-Party-Provider lassen sich auf diese Weise auch einfach dokumentieren und nachweisen, ohne dass der Anbieter potenzielle Beweise durch ein Update seiner CDN-Ressourcen entfernen könnte.

Theoretisch lassen sich durch lokale Kopien auch kompromittierte Skriptversionen scannen und vor dem Ausspielen herausfiltern. Leider gibt es bislang kein dem Autor bekanntes Tool, das zuverlässig Webressourcen wie JavaScript und Web Fonts heuristisch auf Schadsoftware scannen kann. Der „klassische Virenscanner“ für Webressourcen existiert leider noch nicht. NPM-Pakete auf Basis ihrer Versionen auf bekannte Schwachstellen zu scannen, ist zwar möglich, basiert jedoch lediglich auf der Pflege einer zentralen Datenbank sowie Versionsabgleichen. Einen zielgerichteten Angreifer hält das nicht davon ab, kompromittierten Code aufzuspielen.

Herausforderungen beim Einsatz eines Privacy Proxy

Besteht dennoch die Notwendigkeit Daten zurück zu den Anbietern übertragen zu müssen, beispielsweise zum Zwecke des Trackings und der Analyse, sollte zumindest die URL des Rückkanals konfigurierbar sein. Darüber hinaus muss klar festgeschrieben sein, welche Metadaten der Anbieter benötigt. Neben den Query-Parametern muss definiert sein, ob Methoden wie GET, POST, PUT oder andere notwendig sind. Darüber hinaus sind Header und Cookies festzulegen, die man übergeben muss.

Alle weiteren Metadaten müssen manuell im Privacy Proxy konfiguriert sein. Dieses formale Whitelisting stellt sicher, dass auch in Zukunft nicht stillschweigend zusätzliche Daten erhoben und ausgewertet werden können. Auffällige Daten können Entwickler darüber hinaus blacklisten oder manipulieren. Als Beispiel sei eine anonymisierte IP-Adresse genannt, die das Werkzeug zumindest mit zwei Oktetten (1.2.xxx.xxx) DSGVO-konform übermittelt, oder die es vollständig unterdrücken kann.