Mayflower GmbH, profile picture
Hochgeladen vonMayflower GmbH
3,321 aufrufe

JavaScript Security

Die Präsentation thematisiert Sicherheitsaspekte von JavaScript, insbesondere die Bedrohungen durch Cross-Site-Scripting (XSS), das durch verschiedene Typen wie DOM-basiertes, reflektiertes und persistentes XSS klassifiziert wird. Sie zeigt die Herausforderungen auf, die aus der Ausführung von JavaScript im Browser resultieren, einschließlich der Unsicherheiten bei der Eingabe- und Ausgabeverarbeitung sowie den Auswirkungen auf Single-Page-Anwendungen. Verschiedene Ansätze zur Minderung von XSS, wie Escaping und Blacklisting, werden als unzureichend dargestellt, wobei betont wird, dass das Vertrauen in JavaScript-Kontexte oft grundlegend verloren geht.

11-mal heruntergeladen
1 / 102
2 / 102
3 / 102
4 / 102
5 / 102
6 / 102
7 / 102
8 / 102
9 / 102
10 / 102
11 / 102
12 / 102
13 / 102
14 / 102
15 / 102
16 / 102
17 / 102
18 / 102
19 / 102
20 / 102
21 / 102
22 / 102
23 / 102
24 / 102
25 / 102
26 / 102
27 / 102
28 / 102
29 / 102
30 / 102
31 / 102
32 / 102
33 / 102
34 / 102
35 / 102
36 / 102
37 / 102
38 / 102
39 / 102
40 / 102
41 / 102
42 / 102
43 / 102
44 / 102
45 / 102
46 / 102
47 / 102
48 / 102
49 / 102
50 / 102
51 / 102
52 / 102
53 / 102
54 / 102
55 / 102
56 / 102
57 / 102
58 / 102
59 / 102
60 / 102
61 / 102
62 / 102
63 / 102
64 / 102
65 / 102
66 / 102
67 / 102
68 / 102
69 / 102
70 / 102
71 / 102
72 / 102
73 / 102
74 / 102
75 / 102
76 / 102
77 / 102
78 / 102
79 / 102
80 / 102
81 / 102
82 / 102
83 / 102
84 / 102
85 / 102
86 / 102
87 / 102
88 / 102
89 / 102
90 / 102
91 / 102
92 / 102
93 / 102
94 / 102
95 / 102
96 / 102
97 / 102
98 / 102
99 / 102
100 / 102
101 / 102
102 / 102
JavaScript Security Race against the clock: 102 Slides, 2 Demos Hallo Zusammen und willkommen zum Talk über JavaScript Security.
DISCLAIMER: No JavaScript-God But pretty 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.
Largest Attack Surface Ever •2.5 Milliarden Browser-Clients •1 Milliarde Smartphones •Private Daten im Browser •Bankdaten im Browser •Milliardensummen in Transaktionen •Die Bitcoin-Geldbörse Und die Grafik von eben gibt es nicht nur einmal. Sondern endlos oft. 2.5 Milliarden Clients werden genutzt, inzwischen fast genausoviele Smartphones. Jeder hat inzwischen mehr private Informationen im Browser als im Tagebuch. Mehr Geld über Online-Transaktionen verwaltet als über Unterschriften.
K XSS Erster und wichtigster Kandidat ist XSS. Wer weiss alles, was XSS lang heisst?
K XSS Cross Site Scripting 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.
K XSS JavaScript Injection 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.
K XSS <html> <head> <title>JavaScript-Test</title> <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.
K XSS I WANT MOAR! <html> <head> <title>JavaScript-Test</title> <script src="quadrat.js" type="text/javascript"> </script> </head> 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 ...
K XSS <html><head><title>JavaScript-Test</title> <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 ...
K XSS <a href=“javascript:alert(/Hi!/);“>Click me</a> Einfach URLs nutzen könnte, um JavaScript auszuführen???
K XSS <meta http-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.
K XSS <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.
K XSS <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.
K XSS 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.
K XSS Das ist unpraktisch! Das ist zwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.
K XSS 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.
K XSS 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.
K XSS <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.
K XSS <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.
K XSS <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;
K XSS XSS Type 0: Dom-based XSS Lokal, nur im Client, ohne Server. Deshalb hilft serverside Mitigation nicht. Meist basierend auf location.* 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.
K XSS XSS 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.
K XSS XSS Type 2: Persistent XSS Wie reflektierter 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.
K XSS XSS Type X: Somewhere Else Eingebettetes remote.js Externe JSONPs Handschrift auf der Überweisung Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.
K XSS Rich Internet Applications Bei Single Page Applications ist jeder XSS persistent, weil keine Heilung mehr durch einen URL-Wechsel stattfindet. 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.
K XSS Escaping FTW! Also wurde zunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?
K XSS escapeHtml(“Hartmann<script>alert(1);</script>“); <p>Name: Hartmann&gt;script&lt;alert(1);&gt;/ script&lt;</p> Ich nehme hier mal die Escape-Funktion aus Mustache, vom Jan Lehnhardt. Das klappt tatsächlich, wie cool!
K XSS 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...
K XSS escapeHtml(“80331;alert(1) “); <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.
K XSS Universelles Escaping funktioniert nicht. Fazit: Universelles Escaping funktioniert nicht.
K XSS Blacklists ftw 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?
K XSS <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.
K XSS <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.
K XSS <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.
K XSS <script> plz = 80331; <script> <script> plz = 80331;alert(1); <script> Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....
K XSS <script> plz = 80331; <script> <script> plz = 80331;prompt(1,1); <script> ... da muss man dann prompt(1,1) zum testen nehmen :-).
K XSS Universelles Blacklisting funktionert nicht. Fazit: Universelles Blacklisting funktioniert auch nicht.
K XSS Ok, Escaping geht nicht, Blacklisting geht nicht. Aber richtiges Escaping funktioniert schon noch, oder? Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?
K MXSS 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.
K MXSS 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.
K MXSS Demotime! Idee, Konzept, sonstiges: alles geklaut bei Mario Heiderich Demo! file:///Users/johann/javascript/innerhtml_test.html Siehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse
K MXSS HTML im Browser != geschriebenes HTML •abhängig von Browserversion •abhängig von Browsermode •abhängig von Position 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.
K XSS Are we done yet? Ok, sind wir jetzt endlich mit den ganzen Problemen durch?
K XSS Nope. Klar gibt es noch mehr!
K XSS <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.
K XSS Vorher galt: Attribut mit on* -> Triggert JavaScript 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.
K XSS <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.
K XSS <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.
K XSS <b data-ng-app data-ngstyle="constructor.constructor('alert(1)') ()" /> Und nicht nur direkt im Template-Text wird executed, wie bei Dojo kann ich auch direkt im Attribut JavaScript triggern.
K XSS Und nicht nur da spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)
K XSS Da steht ja nicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.
K XSS $() 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.
K XSS $() Aber das bedeutet auch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.
K XSS 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 SecurityProblem 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.
K XSS $() 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
K XSS Ok, aber ist das wirklich ein Problem? Da stellt sich natürlich die Frage - ist das wirklich ein Problem?
K XSS Wenn JavaScript ausgeführt werden kann, dann ist das vollständige Vertrauen im aktuellen Kontext zerstört. Ja, ist es. Das erste liegt an der Sprache selbst. Die Sprache erlaubt die Manipulation und das Überschreiben von allem, auch von den Browsereigenen Objekten und Methoden.
K XSS Ich brauche bloss window.alert(); auf eine neue Funktion zu binden, und schon passiert etwas ganz anders wenn ich einen alert() triggere. Das gleiche gilt natürlich auch für Objekte wie xmlhttprequest.
K XSS Same Origin Policy Sandbox Seiteneffekte Und das ist nicht das einzige Problem. JavaScript läuft zwar in der Sandbox und kann durch die Same-Origin-Policy bzw. durch Cross-Domain Policies nicht auf alles zugreifen, aber auch ohne Zugriff gibt es Seiteneffekte.
K XSS CSRF Mein JavaScript erbt die Browsrechte anderer Tabs, wenn ich mit Ihrem Host interagiere Der bekannteste Seiteneffekt in JavaScript ist Cross Site Request Forgery, oder auch kurz SeaSurf. Wenn das JavaScript auf meiner Seite URLs auf einer anderen Seite aufruft, wenn es Formulare auf die andere Seite abschickt, dann bekommt dieser Request automatisch die Cookies, die HTTP-Authentifizierung dieses Host verliehen. Die Vorteile sind klar - ich kann auf eine andere Seite verlinken, und wenn ich dort eingeloggt war bleibe ich es auch.
K XSS Intranet 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);“ />
K XSS Intranet Dictionary-Attacken auf das Intranet Url-basierte Erkennung von Devices und Login-Status Drive-By-Pharming auf Hightrafficsites
K XSS Pixel Perfect Timing var handle = window.requestAnimationFrame(callback); damit die Frame Rate auszurechnen Über -moz-element/webkit-box-reflect iframe als vergrösserten Background für ein <div> nutzen teuren Morphology-Filter über einzelne Pixel legen und Frame Rate messen
K XSS 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.
K XSS Pixel Perfect Timing Geht natürlich auch mit view-source: urls im Chrome Iframes-Buster vsFacebook-Comments/Likes wollen embedded werden OCR funktioniert
K XSS Demotime! http://beefproject.com/ 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
XSS Extensions, C & HTML5 & Phonegap Da sind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.
XSS Extensions C Faktisch: HTML5-Applications http://de.slideshare.net/kkotowicz
XSS Extensions C Pro Domain* Sonderrechten: chrome.tabs chrome.bookmarks chrome.history chrome.cookies
XSS Extensions C 40% http://*/* https://*/* Pro Domain* Sonderrechten: chrome.tabs chrome.bookmarks chrome.history chrome.cookies
XSS Extensions C Halten sich inzwischen an Content Security Policy Aber: diverse eval()s in Libraries (mustache, underscore, jQuery template)
XSS Extensions C Resultat: Voller Zugriff auf alle Seiten im Browser Inkl. Cookies und Logins Facebook, GMail, Twitter, ...
C XSS HTML5 Alte Bugs in neuen Variationen: <input onfocus=alert(1) autofocus> <input onblur=alert(1) autofocus><input autofocus> <form id=test onforminput=alert(1)> <button form=test onformchange=alert(2)> <button form=test onformchange=alert(2)> <math href="javascript:alert(1)">CLICKME</math> Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.
C XSS HTML5 <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.
C XSS Phonegap Capabilities über Permissions: Camera, Contacts, Files, Geolocation, Media,... Alle Capabilities der App in XSS nutzbar
C XSS 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.
M Typosquatting XSS 1. Registrier die Domain googlesyndicatio.com 2. Erzeuge ein file http://pagead2.googlesyndicatio.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.
Z XSS How to fix it. Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.
Z XSS Schlicht nicht machen: *.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.
Z XSS Schlicht nicht machen: 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.
Z XSS Schlicht nicht machen: Dynamisch HTML JS-Templates JS-Code(!) genieren 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.
Z XSS Schlicht nicht machen: on-Events statt dessen: Explizit binden: $('#main').bind("click", function(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.
Z XSS Schlicht nicht machen: Alte Libraries (json.js, jquery) nutzen Auch wenn Google sie noch hostet ... 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.
Z XSS Schlicht nicht machen bei JQuery: Niemals untrusted Input in die Sinks... JQuery(), $(), $().html, $().before(), $().after, $().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.
Z XSS Schlicht machen: Korrekt escapen: Urls mit EncodeURI HTML zB mit JsHtmlSanitizer Whitelists wo sie möglich sind
Z XSS Header Content-Security-Policy: script-src ‘self‘ X-Content-Security-Policy: script-src ‘self‘ X-WebKit-CSP: script-src ‘self‘ 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.
Z XSS Header 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)> man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.
Z XSS Header CSP deaktivieren: <meta http-equiv="Content-Security-Policy" content="default-src 'none'"> injecten. Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren ...
Z XSS Header X-XSS-Protection: 1; mode=block X-FRAME-OPTIONS: DENY 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.
Z Node.js Node.js Security
Z Node.js Viele Sinks: eval(),ChildProcess.*, Cluster.*,fs.*, http.*, 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.
Z Node.js 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/'); 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.
Z Node.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.
Z Node.js npms Kommen wir zu einem ganz dunklem Kapitel.
Z Node.js Authenticated 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 SecurityStandpunkt 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.
Z Node.js Support für typische Security-Features: - node-validator für validation & sanitizing 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.
Z Node.js node-validator Sanitizer: Blacklister, also gibt es Workarounds: <!DOCTYPE x[<!ENTITY x SYSTEM "http://html5sec.org/test.xxe">]><y>&x;</y> und in test.xxe: <script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script> 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.
Z Node.js SQL-Injections: nodejsdb solide, inklusive Parameter binding Aber: Whitelisting von Bezeichnern und SQLSyntax 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 SQLInjections möglich. Aber wie gesagt, das sind nur 3 von 30.000 Modulen, und gerade die selten genutzten Module sind nicht wirklich vertrauenswürdig.
Z Node.js ReDOS-Attacken: existierende reguläre Ausdrücke so füttern, dass sie beliebig viel CPU brauchen. Beispiel: var match = /^(a+)+$/.exec('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'); Blockiert den Server > 10 Sekunden.
Z Node.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‘);
Z Node.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);
Z Fazit Danke!

Weitere ähnliche Inhalte

PDF
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
PDF
Let’s groove with Groovy
vonThorsten Kamann
 
ODP
Hacker haben unsere Login-Daten. Was tun wir?
vonSören Laird Sörries
 
PDF
Blockchains erfolgreich angreifen
vonSebastianRitter9
 
PDF
JavaScript Days 2015: Security
vonMayflower GmbH
 
PDF
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 
PDF
Test Automation - Principles and Practices
vonAnand Bagmar
 
PDF
Node.js Security
vonSebastian Springer
 
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
Let’s groove with Groovy
vonThorsten Kamann
 
Hacker haben unsere Login-Daten. Was tun wir?
vonSören Laird Sörries
 
Blockchains erfolgreich angreifen
vonSebastianRitter9
 
JavaScript Days 2015: Security
vonMayflower GmbH
 
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 
Test Automation - Principles and Practices
vonAnand Bagmar
 
Node.js Security
vonSebastian Springer
 

Ähnlich wie JavaScript Security

PDF
Christian heilmann wie javascript die welt eroberte
vonChristian Heilmann
 
PDF
JavaScript Performance
vonSebastian Springer
 
PDF
DOM-based XSS
vonKrassen Deltchev
 
PDF
JavaScript Performance
vonSebastian Springer
 
PDF
Emanzipiertes JavaScript und das Coming Out der Flash Community
vonChristian Heilmann
 
PDF
Von Dinosauriern, Bienen und Wespen
vonTomas Caspers
 
PDF
Von Dinosauriern, Bienen und Wespen
vonJens Grochtdreis
 
ODP
Effiziente Fehlersuche in Web 2.0 Anwendungen
vonMartin Leyrer
 
ODP
Effiziente Fehlersuche In Web 2.0 Anwendungen - Graz Edition
vonMartin Leyrer
 
PDF
Node.js
vonSebastian Springer
 
PDF
Offensive Security – Das Metasploit Framework
vonQAware GmbH
 
PDF
2017 05 16_trend_micro_webinar_wanna_cry1_ppt
vonAndreas Pelka
 
PPTX
Digitallotse
vonFelix Escribano
 
PDF
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
vonNETWAYS
 
PDF
Testgetriebene Entwicklung mit JavaScript - JAX 2011
vonSebastian Sanitz
 
KEY
JSTF-Workshop Teil 1
vonTobias Adam
 
PPTX
Backend-Services mit Rust
vonJens Siebert
 
PDF
Debugging und Profiling
vonSebastian Springer
 
PPTX
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
vonGregor Biswanger
 
PDF
Javascript info Ebook Part 1 The JavaScript language 1st Edition Ilya Kantor
vondjonzoverb
 
Christian heilmann wie javascript die welt eroberte
vonChristian Heilmann
 
JavaScript Performance
vonSebastian Springer
 
DOM-based XSS
vonKrassen Deltchev
 
JavaScript Performance
vonSebastian Springer
 
Emanzipiertes JavaScript und das Coming Out der Flash Community
vonChristian Heilmann
 
Von Dinosauriern, Bienen und Wespen
vonTomas Caspers
 
Von Dinosauriern, Bienen und Wespen
vonJens Grochtdreis
 
Effiziente Fehlersuche in Web 2.0 Anwendungen
vonMartin Leyrer
 
Effiziente Fehlersuche In Web 2.0 Anwendungen - Graz Edition
vonMartin Leyrer
 
Node.js
vonSebastian Springer
 
Offensive Security – Das Metasploit Framework
vonQAware GmbH
 
2017 05 16_trend_micro_webinar_wanna_cry1_ppt
vonAndreas Pelka
 
Digitallotse
vonFelix Escribano
 
OSMC 2011 | Monitoring at large - die Welt ist nicht genug by Thomas Gelf
vonNETWAYS
 
Testgetriebene Entwicklung mit JavaScript - JAX 2011
vonSebastian Sanitz
 
JSTF-Workshop Teil 1
vonTobias Adam
 
Backend-Services mit Rust
vonJens Siebert
 
Debugging und Profiling
vonSebastian Springer
 
Aber schnell! Top HTML5 Performance Tipps für Hybrid- und Web-Apps
vonGregor Biswanger
 
Javascript info Ebook Part 1 The JavaScript language 1st Edition Ilya Kantor
vondjonzoverb
 

Mehr von Mayflower GmbH

PDF
Why and what is go
vonMayflower GmbH
 
PDF
Agile Anti-Patterns
vonMayflower GmbH
 
PDF
Vom Entwickler zur Führungskraft
vonMayflower GmbH
 
PPTX
Produktive teams
vonMayflower GmbH
 
PDF
Salt and pepper — native code in the browser Browser using Google native Client
vonMayflower GmbH
 
PDF
Plugging holes — javascript memory leak debugging
vonMayflower GmbH
 
PDF
Usability im web
vonMayflower GmbH
 
PDF
Rewrites überleben
vonMayflower GmbH
 
PDF
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
PDF
Responsive Webdesign
vonMayflower GmbH
 
PDF
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
vonMayflower GmbH
 
PDF
Pair Programming Mythbusters
vonMayflower GmbH
 
PDF
Shoeism - Frau im Glück
vonMayflower GmbH
 
PDF
Bessere Software schneller liefern
vonMayflower GmbH
 
PDF
Von 0 auf 100 in 2 Sprints
vonMayflower GmbH
 
PDF
Piwik anpassen und skalieren
vonMayflower GmbH
 
PDF
Agilitaet im E-Commerce - E-Commerce Breakfast
vonMayflower GmbH
 
KEY
Mongo DB - Segen oder Fluch
vonMayflower GmbH
 
PDF
Schnelle Geschäfte
vonMayflower GmbH
 
PDF
Test-Driven JavaScript Development IPC
vonMayflower GmbH
 
Why and what is go
vonMayflower GmbH
 
Agile Anti-Patterns
vonMayflower GmbH
 
Vom Entwickler zur Führungskraft
vonMayflower GmbH
 
Produktive teams
vonMayflower GmbH
 
Salt and pepper — native code in the browser Browser using Google native Client
vonMayflower GmbH
 
Plugging holes — javascript memory leak debugging
vonMayflower GmbH
 
Usability im web
vonMayflower GmbH
 
Rewrites überleben
vonMayflower GmbH
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
Responsive Webdesign
vonMayflower GmbH
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
vonMayflower GmbH
 
Pair Programming Mythbusters
vonMayflower GmbH
 
Shoeism - Frau im Glück
vonMayflower GmbH
 
Bessere Software schneller liefern
vonMayflower GmbH
 
Von 0 auf 100 in 2 Sprints
vonMayflower GmbH
 
Piwik anpassen und skalieren
vonMayflower GmbH
 
Agilitaet im E-Commerce - E-Commerce Breakfast
vonMayflower GmbH
 
Mongo DB - Segen oder Fluch
vonMayflower GmbH
 
Schnelle Geschäfte
vonMayflower GmbH
 
Test-Driven JavaScript Development IPC
vonMayflower GmbH
 

Kürzlich hochgeladen

PPTX
DI Mag. Alfried Braumann (Wirtschaftsagentur Wien)
vonPraxistage
 
PPTX
Bernhard Landrichter, BSc. (Codara Group GmbH)
vonPraxistage
 
PPTX
Werner Panhauser, (Helvetia Versicherungen)
vonPraxistage
 
PDF
Mag. Ilkin Temocin (Specific-Group Consulting), Mag. Christoph Helm (Erste Gr...
vonPraxistage
 
PPTX
Martin Kasper (SRB Consulting Team), MSc, Mag. Mario Schick (Europapier)
vonPraxistage
 
PPTX
Mag. Christian Samide (Pure Storage Austria), Mag. Philipp Maurer (LB-systems...
vonPraxistage
 
PDF
Risiken minimieren, Erfolg maximieren: SAP Application Management Services in...
vonIBsolution GmbH
 
PPTX
BM Bernhard Heinl (Marktgemeinde Michelhausen)
vonPraxistage
 
PPTX
Josef Rathmayr (Infotech EDV-Systeme), Dipl.-Ing. (FH) Kay Ernst (Zero Networks)
vonPraxistage
 
PPTX
Mag. Dr. Thomas Petrik (Sphinx IT Consulting)
vonPraxistage
 
PPTX
BM Bernhard Heinl (Marktgemeinde Michelhausen)
vonoffice699914
 
PDF
Einladung zu den Praxistagen 2025 im virtuellen Landhaus
vonPraxistage
 
PPTX
DI Kuno Skach (Control Center Apps), BM Bernhard Heinl (Marktgemeinde Michelh...
vonPraxistage
 
PPTX
Mag. Klaus Schaffer (Avenum Technologie)
vonPraxistage
 
DI Mag. Alfried Braumann (Wirtschaftsagentur Wien)
vonPraxistage
 
Bernhard Landrichter, BSc. (Codara Group GmbH)
vonPraxistage
 
Werner Panhauser, (Helvetia Versicherungen)
vonPraxistage
 
Mag. Ilkin Temocin (Specific-Group Consulting), Mag. Christoph Helm (Erste Gr...
vonPraxistage
 
Martin Kasper (SRB Consulting Team), MSc, Mag. Mario Schick (Europapier)
vonPraxistage
 
Mag. Christian Samide (Pure Storage Austria), Mag. Philipp Maurer (LB-systems...
vonPraxistage
 
Risiken minimieren, Erfolg maximieren: SAP Application Management Services in...
vonIBsolution GmbH
 
BM Bernhard Heinl (Marktgemeinde Michelhausen)
vonPraxistage
 
Josef Rathmayr (Infotech EDV-Systeme), Dipl.-Ing. (FH) Kay Ernst (Zero Networks)
vonPraxistage
 
Mag. Dr. Thomas Petrik (Sphinx IT Consulting)
vonPraxistage
 
BM Bernhard Heinl (Marktgemeinde Michelhausen)
vonoffice699914
 
Einladung zu den Praxistagen 2025 im virtuellen Landhaus
vonPraxistage
 
DI Kuno Skach (Control Center Apps), BM Bernhard Heinl (Marktgemeinde Michelh...
vonPraxistage
 
Mag. Klaus Schaffer (Avenum Technologie)
vonPraxistage
 

JavaScript Security

  • 1.
    JavaScript Security Race againstthe clock: 102 Slides, 2 Demos Hallo Zusammen und willkommen zum Talk über JavaScript Security.
  • 2.
    DISCLAIMER: No JavaScript-God But prettygood 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.
  • 3.
    Largest Attack Surface Ever •2.5Milliarden Browser-Clients •1 Milliarde Smartphones •Private Daten im Browser •Bankdaten im Browser •Milliardensummen in Transaktionen •Die Bitcoin-Geldbörse Und die Grafik von eben gibt es nicht nur einmal. Sondern endlos oft. 2.5 Milliarden Clients werden genutzt, inzwischen fast genausoviele Smartphones. Jeder hat inzwischen mehr private Informationen im Browser als im Tagebuch. Mehr Geld über Online-Transaktionen verwaltet als über Unterschriften.
  • 4.
    K XSS Erster und wichtigsterKandidat ist XSS. Wer weiss alles, was XSS lang heisst?
  • 5.
    K XSS Cross Site Scripting Genau, das sollteauch 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.
  • 6.
    K XSS JavaScript Injection 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.
  • 7.
    K XSS <html> <head> <title>JavaScript-Test</title> <script src="quadrat.js" type="text/javascript"> </script> </head> JavaScriptkann 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.
  • 8.
    K XSS I WANT MOAR! <html> <head> <title>JavaScript-Test</title> <scriptsrc="quadrat.js" type="text/javascript"> </script> </head> 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 ...
  • 9.
    K XSS <html><head><title>JavaScript-Test</title> <script type="text/javascript"> alert(“Hi!“); </script> </head> Wie zumBeispiel 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 ...
  • 10.
    K XSS <a href=“javascript:alert(/Hi!/);“>Click me</a> EinfachURLs nutzen könnte, um JavaScript auszuführen???
  • 11.
    K XSS <meta http-equiv=“refresh“ content=“0;url=“javascript:alert(1);“> Hey, daswäre cool. Schliesslich können wir URLs fast überall nutzen. Und da geht das dann auch.
  • 12.
    K XSS <input value=“12“ onmouseover=“alert(1);“> Dannhaben 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.
  • 13.
    K XSS <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.
  • 14.
    K XSS Und generell, wärees 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.
  • 15.
    K XSS Das ist unpraktisch! Das istzwar auf der einen Seite, irgendwie total cool, dass ich das überall verwenden kann, auf der anderen Seite aber massiv unpraktisch.
  • 16.
    K XSS Für den Browsersind 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.
  • 17.
    K XSS Ich wollte dochnur 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.
  • 18.
    K XSS <p>Name: Hartmann</p> <p>Name: Hartmann<script>alert(1);</ script></p> Dasist 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.
  • 19.
    K XSS <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.
  • 20.
    K XSS <input type=text value=“Hartmann“> <inputtype=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;
  • 21.
    K XSS XSS Type 0: Dom-basedXSS Lokal, nur im Client, ohne Server. Deshalb hilft serverside Mitigation nicht. Meist basierend auf location.* 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.
  • 22.
    K XSS XSS Type 1: ReflectedXSS 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.
  • 23.
    K XSS XSS Type 2: PersistentXSS Wie reflektierter 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.
  • 24.
    K XSS XSS Type X: SomewhereElse Eingebettetes remote.js Externe JSONPs Handschrift auf der Überweisung Und es gibt natürlich beliebige andere Quellen, von denen meine Applikation die Daten bekommt.
  • 25.
    K XSS Rich Internet Applications Bei SinglePage Applications ist jeder XSS persistent, weil keine Heilung mehr durch einen URL-Wechsel stattfindet. 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.
  • 26.
    K XSS Escaping FTW! Also wurdezunächst einmal escaped. Wer setzt hier $.html() in Jquery ein, um Output zu escapen?
  • 27.
    K XSS escapeHtml(“Hartmann<script>alert(1);</script>“); <p>Name: Hartmann&gt;script&lt;alert(1);&gt;/ script&lt;</p> Ich nehme hiermal die Escape-Funktion aus Mustache, vom Jan Lehnhardt. Das klappt tatsächlich, wie cool!
  • 28.
    K XSS 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...
  • 29.
    K XSS escapeHtml(“80331;alert(1) “); <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.
  • 30.
    K XSS Universelles Escaping funktioniert nicht. Fazit:Universelles Escaping funktioniert nicht.
  • 31.
    K XSS Blacklists ftw Also wurdezunächst Blacklisting erfunden. Sprich: ich gucke nach bösen Sachen und filtere sie heraus. Jemand hier, der Blacklists einsetzt? PHPIDS? Validator aus Node.js?
  • 32.
    K XSS <p>Name: Hartmann<script>alert(1);</ script></p> <p>Name: Hartmannalert(1);</p> Blacklistssollten die gefährlichen Ausdrücke entfernen, so dass kein JavaScript mehr ausgeführt werden kann. Also wurden die einfach entfernt.
  • 33.
    K XSS <p>Name: Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name: Hartmann<script>alert(1);</ script></p> Darauf habendie 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.
  • 34.
    K XSS <p>Name: Hartmann<scr<script>ipt>alert(1);</ scri<script>pt></p> <p>Name: Hartmann[removed]alert(1); [removed] </p> Inzwischensind die natürlich auch besser geworden, und im regelfall - zB bei node.js validator - sieht das so aus.
  • 35.
    K XSS <script> plz = 80331; <script> <script> plz= 80331;alert(1); <script> Dieses Ding bleibt trotzdem unangetastet. Ok, bei einigen Blacklists fliegt alert raus ....
  • 36.
    K XSS <script> plz = 80331; <script> <script> plz= 80331;prompt(1,1); <script> ... da muss man dann prompt(1,1) zum testen nehmen :-).
  • 37.
  • 38.
    K XSS Ok, Escaping gehtnicht, Blacklisting geht nicht. Aber richtiges Escaping funktioniert schon noch, oder? Das ist ja schon mal nicht so gut. Aber sind wir damit schon am Ende?
  • 39.
    K MXSS 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.
  • 40.
    K MXSS Es steht dasdrin, 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.
  • 41.
    K MXSS Demotime! Idee, Konzept, sonstiges: allesgeklaut bei Mario Heiderich Demo! file:///Users/johann/javascript/innerhtml_test.html Siehe http://de.slideshare.net/x00mario/the-innerhtml-apocalypse
  • 42.
    K MXSS HTML im Browser!= geschriebenes HTML •abhängig von Browserversion •abhängig von Browsermode •abhängig von Position 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.
  • 43.
    K XSS Are we done yet? Ok,sind wir jetzt endlich mit den ganzen Problemen durch?
  • 44.
  • 45.
    K XSS <div data-dojo-type="dojox/calendar/Calendar" data-dojo-props="startDate: newDate(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.
  • 46.
    K XSS Vorher galt: Attribut miton* -> Triggert JavaScript 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.
  • 47.
    K XSS <div class="ng-app"> {{constructor.constructor('alert(1)')()}} </div> Ähnliche Problemegibt 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.
  • 48.
    K XSS <div class="ng-app"> &#x7b;&#x7b;constructor.constructor('alert(1) ')()&#x7d;&#x7d; </div> Jetzt könnteman natürlich sagen: hej, dann filtern wir einfach auf {{ .. aber leider geht auch das in die execution.
  • 49.
    K XSS <b data-ng-app data-ngstyle="constructor.constructor('alert(1)') ()"/> Und nicht nur direkt im Template-Text wird executed, wie bei Dojo kann ich auch direkt im Attribut JavaScript triggern.
  • 50.
    K XSS Und nicht nurda spielen die Libraries eine Rolle. Wer setzt alles Jquery ein? (Jetzt sollten sich alle melden)
  • 51.
    K XSS Da steht janicht umsonst „write less, do more“ drunter. Das passiert tatsächlich.
  • 52.
    K XSS $() Das wird zumBeispiel 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.
  • 53.
    K XSS $() Aber das bedeutetauch, dass man nicht immer weiss, was passiert. Und das ist ein Problem.
  • 54.
    K XSS 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 SecurityProblem 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.
  • 55.
    K XSS $() ist eineSink $("<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
  • 56.
    K XSS Ok, aber ist daswirklich ein Problem? Da stellt sich natürlich die Frage - ist das wirklich ein Problem?
  • 57.
    K XSS Wenn JavaScript ausgeführt werdenkann, dann ist das vollständige Vertrauen im aktuellen Kontext zerstört. Ja, ist es. Das erste liegt an der Sprache selbst. Die Sprache erlaubt die Manipulation und das Überschreiben von allem, auch von den Browsereigenen Objekten und Methoden.
  • 58.
    K XSS Ich brauche blosswindow.alert(); auf eine neue Funktion zu binden, und schon passiert etwas ganz anders wenn ich einen alert() triggere. Das gleiche gilt natürlich auch für Objekte wie xmlhttprequest.
  • 59.
    K XSS Same Origin Policy Sandbox Seiteneffekte Unddas ist nicht das einzige Problem. JavaScript läuft zwar in der Sandbox und kann durch die Same-Origin-Policy bzw. durch Cross-Domain Policies nicht auf alles zugreifen, aber auch ohne Zugriff gibt es Seiteneffekte.
  • 60.
    K XSS CSRF Mein JavaScript erbtdie Browsrechte anderer Tabs, wenn ich mit Ihrem Host interagiere Der bekannteste Seiteneffekt in JavaScript ist Cross Site Request Forgery, oder auch kurz SeaSurf. Wenn das JavaScript auf meiner Seite URLs auf einer anderen Seite aufruft, wenn es Formulare auf die andere Seite abschickt, dann bekommt dieser Request automatisch die Cookies, die HTTP-Authentifizierung dieses Host verliehen. Die Vorteile sind klar - ich kann auf eine andere Seite verlinken, und wenn ich dort eingeloggt war bleibe ich es auch.
  • 61.
    K XSS Intranet Erkennung der Browser-IPper 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);“ />
  • 62.
    K XSS Intranet Dictionary-Attacken auf dasIntranet Url-basierte Erkennung von Devices und Login-Status Drive-By-Pharming auf Hightrafficsites
  • 63.
    K XSS Pixel PerfectTiming var handle = window.requestAnimationFrame(callback); damit die Frame Rate auszurechnen Über -moz-element/webkit-box-reflect iframe als vergrösserten Background für ein <div> nutzen teuren Morphology-Filter über einzelne Pixel legen und Frame Rate messen
  • 64.
    K XSS Pixel Perfect Timing http://www.contextis.com/files/Browser_Timing_Attacks.pdf Hiersehen 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.
  • 65.
    K XSS Pixel Perfect Timing Gehtnatürlich auch mit view-source: urls im Chrome Iframes-Buster vsFacebook-Comments/Likes wollen embedded werden OCR funktioniert
  • 66.
    K XSS Demotime! http://beefproject.com/ 1. Neuer Browser http://whatismyipaddress.com IPnotieren 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
  • 67.
    XSS Extensions, C & HTML5 & Phonegap Dasind wir auch gleich beim nächsten Thema - HTML / XSS jenseits des Browsers.
  • 68.
  • 69.
  • 70.
  • 71.
    XSS Extensions C Halten sich inzwischenan Content Security Policy Aber: diverse eval()s in Libraries (mustache, underscore, jQuery template)
  • 72.
    XSS Extensions C Resultat: Voller Zugriff aufalle Seiten im Browser Inkl. Cookies und Logins Facebook, GMail, Twitter, ...
  • 73.
    C XSS HTML5 Alte Bugs inneuen Variationen: <input onfocus=alert(1) autofocus> <input onblur=alert(1) autofocus><input autofocus> <form id=test onforminput=alert(1)> <button form=test onformchange=alert(2)> <button form=test onformchange=alert(2)> <math href="javascript:alert(1)">CLICKME</math> Und natürlich werden alle alten Blacklistfilter durch neue Attribute und Tags ausgetrickst.
  • 74.
    C XSS HTML5 <input type=file directory> Dasneue 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.
  • 75.
    C XSS Phonegap Capabilities über Permissions: Camera,Contacts, Files, Geolocation, Media,... Alle Capabilities der App in XSS nutzbar
  • 76.
    C XSS 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.
  • 77.
    M Typosquatting XSS 1. Registrier dieDomain googlesyndicatio.com 2. Erzeuge ein file http://pagead2.googlesyndicatio.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.
  • 78.
    Z XSS How to fixit. Ok, so langsam können wir ja auch mal schauen, wie man das ganze Repariert.
  • 79.
    Z XSS Schlicht nicht machen: *.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.
  • 80.
    Z XSS Schlicht nicht machen: 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.
  • 81.
    Z XSS Schlicht nicht machen: DynamischHTML JS-Templates JS-Code(!) genieren 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.
  • 82.
    Z XSS Schlicht nicht machen: on-Events stattdessen: Explizit binden: $('#main').bind("click", function(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.
  • 83.
    Z XSS Schlicht nicht machen: AlteLibraries (json.js, jquery) nutzen Auch wenn Google sie noch hostet ... 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.
  • 84.
    Z XSS Schlicht nicht machenbei JQuery: Niemals untrusted Input in die Sinks... JQuery(), $(), $().html, $().before(), $().after, $().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.
  • 85.
    Z XSS Schlicht machen: Korrekt escapen: Urlsmit EncodeURI HTML zB mit JsHtmlSanitizer Whitelists wo sie möglich sind
  • 86.
    Z XSS Header Content-Security-Policy: script-src ‘self‘ X-Content-Security-Policy:script-src ‘self‘ X-WebKit-CSP: script-src ‘self‘ 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.
  • 87.
    Z XSS Header Content-Security-Policy: default-src ‘self‘ <imgsrc=“bla“ onerror=alert(1)> Content-Security-Policy: default-src ‘self‘ ‘unsafe-inline‘ <img src=“bla“ onerror=alert(1)> man kann es aber gezielt, etwa für die eigenen Domain oder den JS-CDN seines vertrauens wieder aktivieren.
  • 88.
    Z XSS Header CSP deaktivieren: <meta http-equiv="Content-Security-Policy" content="default-src'none'"> injecten. Und mit einer HTML-Injection kann ich das ganze dann doch wieder aktivieren ...
  • 89.
    Z XSS Header X-XSS-Protection: 1; mode=block X-FRAME-OPTIONS:DENY 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.
  • 90.
  • 91.
    Z Node.js Viele Sinks: eval(),ChildProcess.*, Cluster.*,fs.*, http.*,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.
  • 92.
    Z Node.js 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/'); 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.
  • 93.
    Z Node.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.
  • 94.
    Z Node.js npms Kommen wir zueinem ganz dunklem Kapitel.
  • 95.
    Z Node.js Authenticated only byE-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 SecurityStandpunkt 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.
  • 96.
    Z Node.js Support für typischeSecurity-Features: - node-validator für validation & sanitizing 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.
  • 97.
    Z Node.js node-validator Sanitizer: Blacklister, alsogibt 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.
  • 98.
    Z Node.js SQL-Injections: nodejsdb solide, inklusiveParameter binding Aber: Whitelisting von Bezeichnern und SQLSyntax 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 SQLInjections möglich. Aber wie gesagt, das sind nur 3 von 30.000 Modulen, und gerade die selten genutzten Module sind nicht wirklich vertrauenswürdig.
  • 99.
    Z Node.js ReDOS-Attacken: existierende reguläre Ausdrückeso füttern, dass sie beliebig viel CPU brauchen. Beispiel: var match = /^(a+)+$/.exec('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'); Blockiert den Server > 10 Sekunden.
  • 100.
    Z Node.js Wenn ich eineval() im Server habe ... process.kill(process.id); require(‘fs‘).writeFileSync(‘/tmp/rootkit‘, data, ‘base64); require(‘child_process‘).spawn(‘/tmp/rootkit‘);
  • 101.
    Z Node.js Node.js auch aufPort 80 nicht als Root! per sudo starten und dann ... var uid = parseInt(process.env.SUDO_UID); if (uid) process.setuid(uid);
  • 102.