Sicherheitsmechanismen moderner Browser - Teil 1

Vor einigen Jahren war es noch ohne größere Probleme möglich, JavaScript in Browsern zu deaktivieren. Zwar konnte es auf einigen Seiten dazu kommen, dass Inhalte nicht korrekt angezeigt wurden oder einige Buttons nicht funktionierten, im Großen und Ganzen war dies jedoch nicht allzu störend. Heutzutage ist das jedoch nicht mehr ganz so leicht. Selbst der primär auf Sicherheit bedachte TOR-Browser hat standardmäßig JavaScript nicht komplett deaktiviert.

Mittlerweile ist JavaScript auf fast allen Webseiten vertreten. Das hat nicht zuletzt mit der verbesserten User Experience (UX) zu tun, die JavaScript bietet. Die Standard-Auszeichnungssprache im Internet, HTML, verfügt zwar über Mittel und Wege Content von anderen Seiten zu laden und sogar automatische Weiterleitungen zu veranlassen, das Problem ist allerdings, dass es kaum möglich ist dynamisch auf Nutzereingaben zu reagieren. Stattdessen muss beispielsweise bei einer Formularübermittlung die Seite komplett neu vom Server geladen werden, um die Änderungen sichtbar zu machen.

JavaScript behebt dieses Problem und verfügt noch über viele weitere Vorteile. Einer seiner vermutlich bedeutendsten ist der, dass JavaScript eine Programmiersprache ist, die sehr auf Schnelligkeit und Effizienz bedacht ist. Dies liegt daran, dass der Browsermarkt einst hart umkämpft war. Um möglichst viele Kunden für sich zu gewinnen, zählte vor allem eine Metrik: Geschwindigkeit. Da verwundert es nicht, dass Chrome’s JavaScript Engine den Namen v8 trägt, vgl. V8 Motor (englisch V8 engine). Aufgrund seiner zahlreichen Optimierungen und Vorteile wird diese Engine sogar mittlerweile für serverseitige Programmierung genutzt, beispielsweise in Node.js.

Würde man heutzutage JavaScript deaktivieren, dann würde ein Großteil der Webseiten vermutlich gar nicht mehr funktionieren. So gibt es beispielsweise mittlerweile Websites die komplett in JavaScript geschrieben sind und nur noch auf statische HTML Dateien zurückgreifen, um besagte JavaScript-Dateien korrekt zu laden. Instagram beispielsweise, eine der meistbesuchten Seiten im Netz ist mithilfe der React JavaScript Library geschrieben. Würde man diese Seite mit deaktivierten JavaScript laden, so würde man keinen Inhalt, sondern lediglich dessen Ladesymbol sehen. Offenbar sind Browser ohne JavaScript mittlerweile so weit verbreitet, dass es sich nicht mal mehr lohnt eine Warnmeldung anzuzeigen.

Doch weshalb sollte man JavaScript überhaupt deaktivieren, wenn es doch so viele Vorteile bietet? Die simple Antwort ist: Sicherheit. Cross-Site-Scripting Schwachstellen sind die vermutlich schwerwiegendsten clientseitigen Sicherheitslücken die Entwickler versehentlich zu verantworten haben. Ohne JavaScript können diese effektiv verhindert werden. Das Gleiche gilt für Schwachstellen im Browser, welche es beispielsweise erlauben könnten, mithilfe von JavaScript den Inhalt anderer Seiten auslesen zu können. Das gleiche trifft auf unsichere JSONP Endpunkte und zahllose andere Sicherheitslücken zu.

Gegen andere (teilweise weniger schwerwiegende) Sicherheitslücken wie CSRF oder Clickjacking hilft diese Maßnahme allerdings nicht. Wie kommt es dazu, dass trotz dieser Sicherheitsbedenken mittlerweile die überwältigende Mehrheit der Nutzer JavaScript aktiviert haben, obwohl gefühlt das Bedürfnis nach Sicherheit im Netz eher zugenommen als abgenommen hat. Die Antwort ist, dass Nutzer ihren Webbrowsern mehr Vertrauen schenken. Automatische Updates, stetige Verbesserungen und die Einführung moderner Sicherheitsmechanismen, haben das Risiko Opfer eines Angriffes über den Browser zu werden, allmählich minimiert. Nichtsdestotrotz kommt es immer wieder zu Schwachstellen in Webanwendungen, die Aufgrund von Programmierfehlern der Webentwickler verursacht werden.

Doch die Entwickler von Webbrowsern haben immer dafür gesorgt, dass auf stetig steigende Anforderungen an die Sicherheit adäquat reagiert wird. Eine der bekanntesten Sicherheitsfeatures moderner Browser ist die Same Origin Policy (SOP). Sie bildet die Grundlage sicheren Surfens im Internet und begegnete so gut wie jedem Webentwickler mindestens einmal im Leben in Form einer nervigen Fehlermeldung. Denn so gut einzelne Sicherheitsmechanismen auch sein mögen, sie kommen fast immer mit einer Einbuße bezüglich der Nutzbarkeit. In diesem Fall überwiegen die Vorteile allerdings sämtliche Nachteile, denn ohne SOP wäre JavaScript in seiner jetzigen Form im Browser nicht nutzbar.

Doch was tut die Same-Origin-Policy? Kurz gesagt verhindert sie, dass Websites wild Daten voneinander auslesen können. Möchte man beispielsweise auf bank.de eine Überweisung tätigen, würde angreifer.de nichts davon abhalten, den eigenen Kontostand auszulesen und an einen Angreifer zu übermitteln. Wäre dies die Norm, wären vertrauliche Geschäfte im Internet nicht möglich. Kurzum, das Internet wie wir es heute kennen, würde es ohne die Same Origin Policy nicht geben.

Im Detail betrachtet funktioniert SOP folgendermaßen: Wann immer JavaScript einen Request sendet oder auf eine Ressource zugreift, wie beispielsweise das window Object eines iframes, überprüft der Browser ob sowohl Protokoll als auch Port und der Domainname übereinstimmen. Ist dies der Fall, so wird dem Nutzer gestattet, die Anfrage auszuführen und es werden erfolgreich Daten zur Verfügung gestellt.

Anders sieht das hingegen aus, wenn beispielsweise der Domainname nicht übereinstimmt. In diesem Fall blockt der Browser entweder die Anfrage oder sorgt dafür, dass die zurückgesendeten Daten nicht dem Nutzer zur Verfügung gestellt werden. Die Same Origin Policy verhindert also zuverlässig, dass Daten empfangen werden, jedoch nicht immer dass Daten an andere Websites geschickt werden. Auf diesen Punkt gehen wir später genauer ein, er betrifft vor allem Cross Site Request Forgery (CSRF).

Nicht same origin (unterschiedliches Protokoll und port) https://example.com 

Nicht same origin (unterschiedlicher Port)
http://example.com:123
http://example.com:456

Nicht same origin (unterschiedlicher Domainname)
http://example.com
http://attacker.com

http://example.com
http://www.example.com

Same Origin
http://example.com:456
http://example.com:456

Durch diesen Schutzmechanismus ist es JavaScript, welches auf einer Angreiferwebsite ausgeführt wird, nicht möglich Daten von einer anderen Website auszuführen. Ein Angreifer müsste den fraglichen Scriptcode folglich auf der anzugreifenden Website ausführen, um auf entsprechende Daten zuzugreifen. Anders ausgedrückt, er müsste einen Cross-Site-Scripting ausführen, um sein Ziel zu erreichen.

Das Problem dabei ist, dass XSS-Schwachstellen leider sehr häufig anzutreffen sind. Wer bereits Webanwendungen programmiert hat, hat mit Sicherheit auch schon einmal unwissentlich eine solche Sicherheitslücke verursacht. Doch auch hier wissen Browser mittlerweile Abhilfe, wenn auch nicht einhundertprozentig effektiv.

Die Rede ist hier von XSS Filtern. Diese überprüfen in der Regel Anfragen auf HTML Tags und Eigenschaften, welche benutzt werden können um JavaScript Code auszuführen. Jedoch blocken sie solche Anfragen nicht sofort. Stattdessen überprüfen sie zuerst, ob die Antwort auf solch eine Anfrage den selben, ungefilterten Code enthält. Ist dies der Fall, wird die Antwort entweder nicht angezeigt oder der entsprechende Scriptcode entfernt. Letzteres kann auch eine Schwachstelle darstellen und unter Umständen unerwünschte Nebenwirkungen haben. Um das Verhalten des XSS-Filters auf seiner eigenen Seite einzustellen, muss man nur den X-XSS-Protection HTTP Response Header setzen.

// XSS-Filter deaktiviert:
X-XSS-Protection: 0

// XSS-Filter aktiviert, XSS-Scripte werden entfernt:
X-XSS-Protection: 1

// XSS-Filter aktiviert, Seite wird nicht gerendert:
X-XSS-Protection: 1; mode=block

Um das unerwünschte Entfernen valider Scripts zu verhindern, sollte man den block mode aktivieren. Leider hat dieser in der Vergangenheit auch unerwünschte Nebeneffekte gehabt, beispielsweise Informationslecks, welche das Auslesen von Teilen der Website ermöglichen. Es ist daher sorgsam abzuwägen, welche der möglichen Filtereinstellungen für Ihre Seite von Vorteil sind. 

Im nächsten Teil dieser Reihe werden wir uns eingehend mit den Themen CORS und JSONP beschäftigen.
 
We use cookies to deliver you the best experience. By browsing our website you agree to our use of cookies. Learn More Wir benutzen Cookies um dir beim Besuchen unserer Website die bestmögliche Erfahrung zu bieten. Beim Besuchen unserer Website erlaubst du uns die Nutzung dieser Cookies. Learn More