Sicherheit und Privatsphäre im Web. Client-Server-Kommunikation mittels Browser, HTTP-Header und Proxys

Aktuelle Forschungsansatze zu Sicherheit und Privatsphare im Web - eine kritische Betrachtung der Client/Server Kommunikation mittels Browsern, HTTP-Header und Proxys

Abstract. Sicherheit und die Privatsphare im World Wide Web wird von Nutzern als sehr wichtig angesehen. Jedoch bietet die Kommunikation zwischen Client und Server im Internet viele Angriffsmoglichkeiten und Risiken. Innerhalb dieser Arbeit werden unterschiedliche Aspekte des HTTP-Protokolls mittels HTTP­Header, sowie die Interpretation des Protokolls durch den Browser und die Kom- munikation uber kostenlose Proxys untersucht. Dabei werden diese anhand von Studien und realen Beispielen erortert und bewertet.

Keywords: Web Security, Web Application Attacks, MITM, HTTP Headers, Proxies, Free Proxies, Proxy Security Issues, Private Browsing, Web Browser privacy, Private Browsing Mode.

1 Einleitung

Die Digitalisierung durchdringt immer mehr Unternehmen, Prozesse und den Alltag eines jeden Einzelnen. Sie bietet neue Moglichkeiten. Uberall durch soziale Medien vernetzt zu sein, Haushaltsgerate oder das eigene Zuhause auch von unterwegs steuern zu konnen, sind dabei nur einige Beispiele. Aber naturlich entstehen dadurch auch neue Risiken. Die Sicherheit und Privatsphare des Nutzers im Internet haben sich dabei zu den groBten Herausforderungen der letzten Jahre entwickelt.

„[Fur] 97 Prozent der Internetnutzer in Deutschland [ist] Sicherheit bei der Nutzung des Internets von groBer Bedeutung [...]. Allerdings stehen das Informationsverhalten und die tatsachlich genutzten SchutzmaBnahmen diesem hohen Sicherheitsbedurfnis teils diametral entgegen.”¹

Trotz des hohen Bewusstseins dieses Problems im Internet zeigen Ergebnisse einer Umfrage des Bundesamtes fur Sicherheit in der Informationstechnik, dass sich nur knapp jeder Dritte mit dem Thema IT-Sicherheit auseinandersetzt. Zudem ist die Offenlegung uber Risiken und Moglichkeiten zum Schutz nicht fur jeden ausreichend transparent und omniprasent. So beachten gerade einmal 45 Prozent der Befragten, ob die Daten verschlusselt zwischen Browser und Server ausgetauscht werden.¹ Dies liegt unter anderem an der Aufklarung, da der Otto-Normalverbraucher meist kein tieferes Wissen uber SSL/TLS-Kommunikation, Zertifikate oder ahnliches hat, beziehungs- weise weiB, worauf geachtet werden sollte.

Vor allem ist das Interesse, moglichst sicher zu sein, nicht in jedem Anwendungsbe- reich von Wert. 71 Prozent der Befragten verhalten sich laut ihrer Aussage sicherheits- bewusst bei finanziellen Transaktionen wie Onlinebanking. 45 Prozent sind es immer- hin noch bei Onlineshopping, bei sozialen Medien und Cloud-Services. Bei der Nut- zung von Internet of Things-Geraten sind es hingegen nur noch weniger als 11 Prozent.¹ Hierbei fallen haufig die Aussagen, dass es einem selbst gar nicht bewusst ist, dass im Hintergrund eine mogliche sicherheitskritische Kommunikation existiert, bei der Pass- worter oder personenbezogene Daten ubermittelt werden. Haufig existieren zudem auch fatale Annahmen des Nutzers uber genutzte Applikationen, wie den Inkognito- Modus bei Browsern:

„when you are in private mode there is no direct link to you or your computer so malware etc. would not be saved onto your computer or in your cookies “²

Eine weitere empirisch ermittelte Aussage der Nutzer von IT-Produkten ist oft, dass der Anbieter auf ausreichend Sicherheit achten muss, bevor er den Dienst oder das Pro- dukt uberhaupt herausgeben darf. Dies ist jedoch nicht immer gegeben, was auch an einem weiteren sicherheitsbedenklichen Problem liegt, was die Friedrich-Alexander- Universitat in Erlangen-Nurnberg wie folgt beschreibt:

„In Deutschland herrscht ein enormer Mangel an akademisch geschulten IT- Sicherheitsfachkraften. Gleichzeitig wachst der Bedarf an sicheren informationstechni- schen Systemen. Immer wieder auftretende Sicherheitsprobleme von im Einsatz be- findlichen Systemen zeigen, dass es haufig an wirksamen Mahnahmen zur Sicherung mangelt.“ ³

Folglich ist oft nicht nur der Endverbraucher mit nicht ausreichend Know-How aus- gebildet, sondern auch bei der Entwicklung neuer Produkte stoht das Fachpersonal an die Grenzen seiner Expertise. Um Abhilfe zu schaffen, werden oft Frameworks fur Si- cherheitsfunktionen genutzt. Dies ist prinzipiell positiv, jedoch werden diese dann eventuell nicht mehr ausreichend gewartet. Zudem kommt es haufig vor, dass das Pro- dukt aufgrund von Kosten nicht intensiv genug auf Sicherheitsrisiken untersucht wird. Es entstehen viele Potentiale, die zu sicherheitskritischen Problemen fuhren konnen.

In dieser Arbeit geht es darum, diese sicherheitskritischen Potentiale in der Kommu- nikation zwischen Client und Server anhand von theoretischen Angriffsszenarien zu untersuchen. Anhand einiger Beispiele soll gezeigt werden, dass diese Sicherheitslu- cken selbst bei grohen Anbietern und Unternehmen aktuell immer noch zum Tragen kommen. Weiter wird die Privatsphare des Nutzers im World Wide Web mittels aktu- eller Browser-Technologien, sowie Mahnahmen zum Schutz von dieser naher betrach- tet. Dazu wird auf die folgenden drei Papiere eingegangen: Misconceptions About Pri­vate Browsing [2], Uncovering HTTP Header [22] und ProxyTorrent [26].

2 Client/Server Kommunikation

Das Client/Server-Modell beschreibt das Prinzip der Kommunikation zwischen zwei Teilnehmern innerhalb eines Netzwerkes. Dabei wird unterschieden zwischen Client, sprich dem Anfragenden nach einer Ressource und dem Server, also dem Anbieter von Informationen. Letzterer stellt die angefragten Informationen fur mehrere Clients zent- ral bereit, weswegen auch von einem zentralisierten System beziehungsweise server- basierten Netzwerk die Rede ist.

Im Detail erfolgt dabei immer eine Anfrage vom Client an den Server (Request), welcher aufgrund der Anfrage-Parameter den Inhalt bereitstellt und an den Client uber- mittelt (Response) - Abbildung 1. Die aufgebaute Verbindung wird in der Regel nach dem Bereitstellen des Inhalts abgebaut. Folglich muss fur eine neue Anfrage bezie- hungsweise eine weitere benotigte Ressource eine neue Verbindung aufgebaut werden. Eine Ausnahme stellen dabei beispielsweise WebSockets dar, da hierbei eine bi-direk- tionale Verbindung aufgebaut wird. Diese Art der Kommunikation wird im Weiteren jedoch nicht tiefer betrachtet, da hier Angriffsszenarien differenzierter zu betrachten sind als in der klassischen Request und Response Kommunikation.

Der Client kann dabei auch ein anderer Server oder eine Anwendung sein, welche eine Ressource von einem anderen Server anfragt. Fur eine ubiquitare Sprache innerhalb dieser Arbeit wird im Weiteren der Client in Form eines Browsers verstanden, um die Sicherheitsrisiken in diesem Gebiet detaillierter betrachten zu konnen. Trotzdem sind spatere sicherheitsbezogene Ansatze, wie die Betrachtung der HTTP-Header, auch auf andere Clients ubertragbar und nicht an die Client-Art gebunden.

Gerade um die HTTP-Header tiefer betrachten zu konnen, gilt es noch zu verstehen, wie Rechner im Netzwerk beziehungsweise Internet kommunizieren. Der abstrakte Ge- danke der Request und Response Kommunikation ist dabei die Basis, jedoch muss dazu noch definiert werden, wie dieser Request aussieht und wie die angefragten Inhalte transportiert werden. Dies erfolgt durch definierte Protokolle, die Regeln fur ein For­mat, einen Inhalt und dessen Bedeutung vorgeben. Fur den Transport in einem Netz- werk wie dem Internet gibt es zwei unterschiedliche Modelle. Auf der einen Seite das OSI-Modell und auf der anderen Seite das TCP/IP-Modell. Wahrend das TCP/IP- Modell bereits in den 1970er Jahren entworfen wurde, kam das OSI-Modell erst uber 10 Jahre spater heraus und definiert sieben Schichten der Kommunikation, dagegen enthalt das TCP/IP-Modell nur vier Schichten. Die Schichten sind ansatzweise uber- tragbar und vergleichbar, wie in Abbildung 2 zu erkennen ist.

Abbildung in dieser Leseprobe nicht enthalten

Fig. 2. Aufbau und Vergleich des OSI- (links) und TCP/IP-Modells (rechts).

Entscheidend ist dabei zu verstehen, wie die Kommunikation uber diese Schichten er- folgt und welche Schnittstellen dabei beteiligt sind, denn nur so lassen sich Bedrohun- gen und mogliche Angriffe identifizieren und entsprechende Sicherheitsvorkehrungen treffen.

Wahrend der Client einen Request an den Server schickt, werden alle Schichten des Protokoll-Stacks der eben erwahnten Modelle von oben nach unten durchlaufen. Dabei erfolgt der Vorgang der Kapselung, wobei jede Schicht Metadaten in Form von Hea- dern an die nachste Schicht ubergibt. Diese sind fur eine spatere Extrahierung und In­terpretation auf der Gegenseite wichtig. Am Ende werden in beiden Modellen Daten- pakete uber eine physische Leitung transportiert. Der Server nimmt alle ubertragenen Pakete an, entpackt und interpretiert diese mittels der Header in umgekehrter Stack- Reihenfolge, sprich von unten nach oben.

An dieser Stelle sei erwahnt, dass das HTTP-Protokoll in der Applikation-Schicht verankert ist und folglich der Server beim Senden der Response auf eine Webseiten- Anfrage den angefragten Inhalt beim Kapseln der Pakete mit HTTP-Headern versieht, bevor diese an die nachste Schicht - wieder von oben nach unten - ubergeben werden. Der Client entpackt die Pakete wieder in umgekehrter Reihenfolge. Dieses Mal von unten nach oben und erhalt so in der letzten Schicht die HTTP-Header des Servers, um diese dann im Browser zu interpretieren.

Mogliche Sicherheits- und Angriffsmoglichkeiten dieser Header werden spater im Detail betrachtet. Jedoch soll vorab ein Beispiel gegeben werden, wofur diese Header gut sein konnen. Mit Hilfe des X-Frame-Options -Header kann der Betreiber einer Webseite verhindern, dass diese von einem anderen Anbieter ohne Wissen daruber in- tegriert wird und so aufgrund der externen Seite ein Imageschaden oder ein mogliches Angriffsszenario wie zum Beispiel Clickjacking entstehen konnte. Mit Hilfe des Hea­ders kann der Server beim Ubertragen der Response angeben, wer den Inhalt anzeigen darf, wie zum Beispiel keiner oder nur der Betreiber einer bestimmten URL. Folglich interpretiert der Browser diese Vorgabe des Servers und im Falle eines nicht erlaubten Zugriffs wird dem Nutzer ein Fehler angezeigt. Dieses setzt jedoch voraus, dass der Client diese Vorgabe des Protokolls richtig interpretiert.

3 Allgemeine Angriffsszenarien

An dieser Stelle soll noch auf einige allgemeine Angriffsszenarien und Definitionen eingegangen werden, um in den folgenden Kapiteln die detaillierten Angriffsvektoren zu verstehen.

Man-in-the-middle-Attacke. Ziel dieser Attacke ist es, dass der Angreifer die Daten- pakete zwischen Client und Server abfangen mochte. Dazu platziert der Angreifer sich, beziehungsweise ein schadliches Programm dazwischen, um den Datenfluss abzufan- gen und manipulieren zu konnen. Er dient folglich als Mittelsmann und kann sowohl dem Client als auch dem Server anderen Inhalt vermitteln.

Cross-Site-Scripting (XSS). Mittels eines Schadprogrammes wird hierbei versucht, an vertrauliche Informationen zu gelangen. Dazu gibt es unterschiedliche Arten. Eines ist dabei aber immer gleich, dass der Angreifer dem Opfer das Schadprogramm injiziert, sei es uber eine Webseite, eine URL oder in den Browser des Opfers direkt. Dadurch konnen vertrauliche Daten des Opfers ausgelesen und an den Angreifer gesendet wer- den.

Cross-Origin-Ressource-Sharing (CORS). Mit dem CORS-Header soll abgesichert werden, dass Inhalte nur von einem bestimmten Ziel-Server geladen werden konnen. Schafft es der Angreifer diesen HTTP-Header zu manipulieren, kann er beim Opfer auch ein Schadprogramm von einem anderen Server ausfuhren lassen.

Social Engineering. Mittels Social Engineering versuchen Angreifer das Opfer zu in- strumentalisieren. Dazu geben sie sich als Bekannte oder vertrauenswurdige Person aus, um das Opfer so dazu zu bewegen, etwas Selbstschadigendes zu tun.

4 Privatsphare mittels Browser-Kommunikation

Bereits vor knapp zehn Jahren ergab eine Umfrage in Deutschland, dass 94 Prozent der befragten Internetnutzer uber 14 Jahren ihre Privatsphare im Internet als kritisch be- trachten oder zumindest sehr darauf achten. Gerade einmal sechs Prozent gaben an, dass sie es als unbedenklich ansehen oder sie nicht interessiert sind an diesem Thema - Abbildung 3. ¹¹

[...]