Web-Sicherheit

Januar 9, 2012

Shreeraj Shah präsentiert Angriffstechniken auf aktuelle Webtechnologien

Filed under: Allgemein — sebastiankuebeck @ 22:34
Tags: , , , , , , , , ,

Shreeraj Shahs Präsentation von der AppSecUS 2011 (die er auch auf der Blackhat- und OWASP-Konferenz gehalten hat) über Angriffstechniken auf aktuelle Webtechnologien HTML5, XHR and DOM Security ist nun online verfügbar, zusammen mit seinem Paper Reverse Engineering Browser Components – Dissecting and Hacking Silverlight, HTML 5 and Flex.

Wie der Titel schon andeutet, geht es dabei nicht um HTML 5 alleine sondern auch umd das Zusammenspiel von Browsern und Plugins wie Flash und Silverlight. Er beschreibt darin detailliert, wie man aktuelle Webanwendungen gezielt auf Schwachstellen untersucht und diese dann ausnutzt.

Es werden dabei kaum  grundsätzlich neue Angriffstechniken vorgestellt, sondern gezeigt, wie bestehende Angriffstechniken (Cross-Site Scripting, Cross-Site Request Forgery, Clickjacking) mit aktuellen Browsern und Plugins noch wirksamer eingesetzt werden können.

September 16, 2011

Wie man den Cross-Site-Scripting-Filter von Googles Chrome umgeht

Filed under: Allgemein — sebastiankuebeck @ 15:53
Tags: , , , , , , ,

Googles aktueller Chrome Browser hat standardmäßig einen Filter gegen Cross-Site-Scripting-Angriffe eingebaut. Nick Nikiforakis zeigt auf seinem Blog, wie einfach man diese Schutzfunktion umgehen kann.

Damit man die geschilderte Angriffstechnik gleich ausprobieren kann, hat er folgendes PHP-Skripft veröffentlicht, dass die Parameter a und b in der URL entgegennimmt und ohne weitere Kodierung ausgibt:  http://securitee.org/files/chrome_xss.php.

Um zu testen, ob überhaupt eine Cross-Site-Scripting-Schwachstelle vorliegt, probieren wir erst einmal aus, ob der Überschrift-Tag in der folgenden Anfrage vom Browser ausgeführt wird (die meisten Filter reagieren lediglich auf Inhalte, die JavaScript enthalten oder nachladen. Begnügt man sich erst einmal mit einem harmlosen Tag, kann man einfach herausfinden, ob sich ein Angriff prinzipiell möglich ist):

http://securitee.org/files/chrome_xss.php?a=<h1>HTML_INJECTION<h1>&b=bar

Das funktioniert augenscheinlich ohne Probleme:

Der „naive“ Versuch, einfach einen Script-Tag einzuschleusen, funktioniert hingegen nicht:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);</script>&b=bar

Chrome entfernt den Inhalt des Script-Tags bevor er die Seite anzeigt:

Als nächstes untersuchte Nick Nikiforakis was passiert, wenn man den Script-Tag nicht abschließt:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);&b=bar

Dabei zeigte sich, dass der Browser den Script-Tag nicht entfernte sondern automatisch schloss. Da allerdings alles, was nach dem Script-Tag kommt nun im JavaScript-Context ausgeführt wird, gibt der JavaScript-Interpreter auf und führt den Code nicht aus:

Was wir nun erreichen müssen ist, dass der Browser den HTML-Code zwischen den beiden Parametern ignoriert, die wir übergeben und das funktioniert, indem wir ihn in einen JavaScript-Kommentar einschließen:

http://securitee.org/files/chrome_xss.php?a=<script>alert(1);/*&b=*/</script>

Und das funkioniert auch, wovon man sich leicht überzeugen kann…

Nick hat das Problem dem Chrome-Team gemeldet, allerdings haben die Chrome-Entwickler noch keinen Weg gefunden, solche Angriffe zu verhindern. Dabei hat Nick nur an der Oberfläche gekratzt und bei weitem nicht alle bekannten Tricks, mit denen man solche Schwachstellen ausnutzen kann, ausprobiert (das „Standardwerk“ zu diesem Thema ist übrigens das XSS Cheat Sheet auf ha.ckers.org).

Es zeigt sich also einmal mehr, dass man um das Absichern der Webanwendung selbst nicht herumkommt. Auch nicht mit noch so gut gemeinten Technologien auf Client- und Serverseite. Microsoft hat sich bei diesem Thema voriges Jahr auch die Finger verbrannt, denn eine Schwachstelle im Cross-Site-Scripting-Filter des Internet Explorer 9 führte dazu, dass Seiten, die bislang nicht verwundbar waren, durch den Filter plötzlich verwundbar wurden.

August 24, 2011

Das Innenleben von Webbrowsern

Filed under: Allgemein — sebastiankuebeck @ 06:54
Tags: , , , , , ,

Tali Garsiel hat jahrelang das Innenleben von Webbrowsern analysiert, hat über dieses Thema in dieser Zeit alle verfügbaren Veröffentlichungen gelesen und die Millionen Quellcodezeilen C++ von WebKit (die Basis von Safari) und Gecko (die Basis von Firefox) analysiert, aus denen diese Software letztlich besteht. Die Ergebnisse dieser Arbeit hat Sie im Artikel How Browsers Work: Behind the Scenes of Modern Web Browsers veröffentlicht.

Der Artikel ist im Gegensatz zu fast allem, was ich bisher über dieses Thema gelesen habe, äußerst verständlich geschrieben, sodass ihn auch Leser, die sich noch nie mit diesem Thema beschäftigt haben, ohne Probleme verstehen können. Ein besseres Verständnis sollte Programmierern helfen, Kodierungsprobleme, die zu Sicherheitsproblemen (Cross-Site Scripting Schwachstellen) führen können, künftig zu vermeiden.

Juni 26, 2011

Geistreiches im Namen des Datenschutzes

Filed under: Allgemein — sebastiankuebeck @ 15:57
Tags: , , , , , , ,

Natürlich gibt es im Internet – wie auch sonst im Leben – nichts gratis, allerdings bezahlt man im Internet meist nicht direkt für die Leistungen, die man erhält, sondern indirekt, indem man den Anbietern Daten zur Verfügung stellt. Leider wird man in der Regel weder gefragt, welche Daten man zur Verfügung stellen will, noch wer diese Daten letztendlich bekommen soll. Schließlich hat man möglicherweise keine Probleme damit, beispielsweise seiner Lieblingszeitung zu gestatten, die eigenen Daten für alles mögliche zu verwenden, verkauft diese Zeitung diese Daten allerdings an alle möglichen dubiosen Firmen weiter, sind die meisten von uns weniger begeistert. Wenn man beispielsweise die Finacial Times Deutschland besucht, werden gleich sieben Dienste automatisch darüber informiert, die mit dem Herausgeber überhaupt nichts zu tun haben (wie man das ermittelt, werde ich später erörtern).

Oft werden Daten auch „abgegriffen“, ohne das es dem Seitenbetreiber bewußt ist. Facebooks „Gefällt mir“-Button ist ein solches Beispiel. Der Seitenbetreiber fügt etwas Code von Facebook in seine Seite ein und schon erscheint der „Gefällt mir“-Button auf der Homepage. Damit weiß Facebook dann allerdings auch, welche Facebook-Benutzer diese Seite besucht haben – dazu ist es gar nicht erst nötig, dass die Benutzer den Button auch klicken, denn Facebook wird schon beim Laden der Seite kontaktiert. Das ganze dient natürlich dazu, ein Profil für jede/jeden Facebook-Benutzerin/Facebook-Benutzer zu erstellen, damit man ihr/ihm möglichst zielgerichtet Werbung einblenden kann. So kann ein Link in einem Online-Shop für Schuhe Mitbewerbern dieses Shops dazu dienen, beispielsweise vergleichbare Produkte zu günstigeren Preisen anzubieten. Natürlich lassen sich so auch politische und sexuelle Neigungen, sowie gesundheitliche Probleme ermitteln, was sicher nicht jeder/jedem Betroffenen recht ist.

Eine (vorgebliche)  Möglichkeit, dieses Verhalten zu unterbinden, ist die Einstellung „Webseiten mitteilen, dass ich nicht verfolgt werden möchte“, auch bekannt als Do-Not-Track-Header im Firefox 4 und höher. Ist diese Einstellung aktiviert, schickt Firefox bei jedem Seitenaufruf einen entsprechenden HTTP-Header mit. Ob nun wirklich keine Daten mehr zu Werbezwecken gesammelt werden, bleibt allerdings dem Seitenbetreiber überlassen.

Eine wirksamere Methode, etwas mehr Kontrolle darüber zu haben, wer welche Daten bekommt, stellt das Browser-Plugin Ghostry dar, dass für die gängigsten Browser erhältlich ist. Ghostry verwendet eine Liste von Diensten, deren einzige Aufgabe es ist, Daten über Benutzer zu Werbezwecken zu sammeln. Findet Ghostry nun einen Link auf einen oder mehrere dieser Dienste, informiert es den Benutzer. Auf Wunsch kann Ghostry diese Dienste auch blockieren.

Ghostry für Firefox in Aktion: Im violetten Feld werden die Trittbrettfahrer angezeigt

Ghostry kann natürlich nicht verhindern, dass Daten serverseitig weitergegeben werden, dennoch kann es in der Praxis die Anzahl der „Trittbrettfahrer“ deutlich reduzieren, wovon man sich beim Surfen mit Ghostry selbst überzeugen kann. Ein weiterer positiver Effekt von Ghostry ist, dass der Surfer etwas mehr Einblick darin bekommt, was beim unbedachten Surfen so alles nebenher passiert.

Ach ja, wärend Sie das lesen, werden Sie von WordPress Stats und Quantcast erfasst…

März 18, 2011

Rezension

Filed under: Allgemein — sebastiankuebeck @ 07:20
Tags: , , , , , ,

Nette Rezension meines Buches von Mark Buzinkay. Der zweite Teil meines Buches ist in der Tat etwas anspruchsvoller, da nicht alle Angriffstechniken ganz einfach zu erklären sind. Aus den bisherigen Workshops weiß ich, dass besonders Cross-Site Request Forgery für die Teilnehmer anfangs nicht ganz leicht zu durchschauen ist. Das hängt wahrscheinlich damit zusammen, das so wenig HTML-Code notwendig ist, um sie auszunutzen.
Um das Verständnis der Angriffstechniken, die im Buch beschrieben sind, zu erleichtern, habe ich eine kleine Demoanwendung in Java entwickelt, die die Schwachstellen, die im Buch beschrieben werden, demonstriert. Sie ist auf der Seite des Verlages unter „Quelltexte“ zu finden.

Demo-Anwendung zur Demonstration von CSRF-Angriffen

Es gibt auch zahlreiche Videos im Netz (wie beispielsweise dieses), in denen das Ausnützen von Cross-Site-Request-Forgery-Schwachstellen demonstriert wird.

Februar 20, 2011

Was passiert, wenn was passiert

Filed under: Allgemein — sebastiankuebeck @ 17:53
Tags: , , , , ,

Das zweite Kapitel meines Buches beschäftigt sich mit den Auswirkungen von Sicherheitsvorfällen auf Unternehmen und Organisationen. Dabei beschreibe ich die häufigsten Sicherheitsvorfälle, die im Zusammenhang mit Webapplikationen auftreten.

Natürlich weise ich in diesem Zusammenhang auch auf Angriffe hin, die durchgeführt werden, um Webseiten mit Schadcode zu infizieren. Dabei fängt sich nicht der Webserver den Virus ein, sondern dient lediglich als „Zwischenwirt“. Er verbreitet den Virus, indem er die Browser der Besucher infiziert, die Schadroutine – also jener Teil, der wirklich etwas böses macht, wie das Ausspähen von Passwörtern zum Beispiel – läuft allerdings nicht am Server.

Beispiele von Angriffen dieser Art gibt es zuhauf. Ein aktieller, prominenter Fall ist die Infektion der Webseite von ThoughWorks, von der ich bereits berichtete. Obwohl die Infektion der Webseite bereits seit dem Jahreswechsel bekannt ist, hat sich die Situation noch nicht gebessert, wie Martin Fowler (leitender Wissenschaftler bei ThoughtWorks) kürzlich berichtete. Inzwischen müssen die Kunden von ThoughtWorks mit einer stark eingeschränkten, statischen Version der Webseite Vorlieb nehmen.

Eine verkürzte Chronologie der Ereignisse:

  • Anfang Jänner: Googles Suchroboter meldet, dass er Schadsoftware auf ThoughtWorks.com gefunden hatte. Bei ThoughtWorks war man „besorgt“, man wusste aber nicht, was man jetzt machen sollte.
  • Ende Jänner: Googles Suchroboter meldet erneut, dass er Schadsoftware gefunden hat. Nun entschließt man sich bei ThoughtWorks, die Homepage durch eine stark eingeschränkten, statischen Version zu ersetzen.
  • Vorletzte Woche: Googles Suchroboter meldet, das nun die Seite von Martin Fowler selbst (martinfowler.com) infiziert sei. Da diese Seite nur aus statischen Seiten besteht und offenbar am selben Server beheimatet war, wie die Homepage von ThoughtWorks, schloss man bei ThoughtWorks, dass der Webserver wahrscheinlich selbst befallen war. Daher wurde diese Seite auf einen anderen Server verlegt.
  • 12., 13. Februar: Über das Wochenende wurde die Homepage von ThoughtWorks auf einem neuen Server aufgesetzt. Daraufhin fand sich wieder Schadsoftware auf diesem Server, also wurde wieder die statische Seite in Betrieb genommen. Nachträglich stellte sich heraus, dass sich offenbar doch keine Schadsoftware auf dem neuen Server befand.

Sie werden sich jetzt wahrscheinlich genauso wie ich fragen, warum die nicht gleich bei der ersten Warnung die Homepage aus den Quellen auf einem frisch aufgesetzten Server aufspielen und in Betrieb setzten.
Die Antwort hierzu laute wie folgt:

Wir müssen auch unsere dynamische Seite [von ThoughtWorks.com] neu aufspielen und in Betrieb setzten. Das ist allerdings schwierig, da Bibliotheken involviert sind, die wir erst überprüfen müssen. Unser letzter Versuch, die Seite in Betrieb zu setzten scheiterte, also müssen wir erst feststellen, was da wirklich passiert.

Mit anderen Worten: Die hatten überhaupt keinen Notfallplan und der Vorfall erwischte ThoughtWorks völlig unvorbereitet (es handelt sich hier immerhin um ein multinationales Technologieunternehmen)! Vor diesem Hintergrund scheinen meine Anmerkungen in Abschnitt 2.2 geradezu prophetisch:

Generell ist es ratsam, auf einen Sicherheitsvorfall vorbereitet zu sein. Es gibt
nämlich – wie wir noch sehen werden – keine hundertprozentige Möglichkeit,
Ihre Infrastruktur gegen alle möglichen Angriffe zu schützen. Deshalb ist es sinnvoll,
sich schon vorher mit der beschriebenen Situation vertraut zu machen und
einen Notfallplan zu erstellen, der alle Aktivitäten beim Eintreten eines Sicherheitsvorfalls
festlegt.

Dazu sollte natürlich auch gehören, dass man seine Homepage jederzeit auf einem neuen Server in Betrieb nehmen kann. Genau so verhält es sich mit jeder Art von Backup: Ist man nicht in der Lage, ein Backup auch wieder einzuspielen, ist es nutzlos. Weiterhin hat es sich gezeigt, dass man praktisch nie in der Lage ist, Backups einzuspielen, wenn man das nicht zuvor trainiert hat.

Abschließend empfehle ich Ihnen, sich regelmäßig selbst die Frage zu stellen, ob Sie in der Lage sind, Ihre Homepage, Ihre Webserver und andere IT-Infrastruktur jederzeit wieder in annehmbarer Zeit zum Laufen zu bringen, sollte ein ähnlicher Vorfall bei Ihnen eintreten…

Januar 21, 2011

Sicherheitsprobleme von Browsern

Filed under: Allgemein — sebastiankuebeck @ 15:16
Tags: , , , , ,

Interessante Präsentation über Browser(un)sicherheit von Collin Jackson, Dozent am Carnegie Mellon University Silicon Valley Campus.


Er behandelt speziell die Themen Cross-Site Request Forgery (CSRF) und Probleme beim Session-Management und geht dabei über die Themen hinaus, die ich in meinem Buch beschrieben habe. Das Problem „Login CSRF“ ist dabei eine Kombination von unsicherem Session-Management und mangelhaftem Schutz vor CSRF.

Ich habe auch ausschließlich die Verteidigung mittels Token beschrieben, da das nach Meinung der OWASP und meiner Meinung die Sicherste Lösung darstellt. Die Idee, die Restriktionen beim Setzten von HTTP-Headern durch die Same Origin Policy zu verwenden, um Ajax-Anwendungen vor CSRF-Angriffen zu schützen, war mir neu, ist aber eine interessante und vor allem innovative Idee! Lediglich die Überprüfung des Referrers scheint mir etwas gefährlich zu sein.

Auf der Homepage der Universität stehen übrigens zahlreiche interessante Papers zur freien Verfügung. Unter anderem auch das Busting-Frame-Busting-Paper (an dem Collin Jackson auch beteiligt war) auf dessen Inhalt ich in Kapitel 10 mit einem konkreten Beispiel eingehe.

Bloggen auf WordPress.com.