Show notes
Wir sprachen mit Mario Heiderich über (Web-)SecurityUnser Gast (00:00:00)Mario Heiderich, @0x6D6172696FHat einen Security Talk "Im DOM hört Dich keiner schreien" auf der enterJS gegeben: http://www.enterjs.de/Mario's Security Firma: https://cure53.de/Nutzen wenig Scanner, mehr HandarbeitSecurity Scanner finden keine "logischen Bugs"RIPS: Statische Analyse von PHP Code: http://rips-scanner.sourceforge.net/Terminologie & Methodologie (00:05:51)Sources: Quellen von Input (User Input z.B.)Sink: Stellen im Code, wo Input ankommt bzw. was mit ihm passiertInput: Input :)Getestet wird manchmal in VMs, manchmal auf Test oder Staging Umgebungen oder auch in Produktiondas hängt vom Kunden und Projekt abWAF: Web Application Firewall: https://en.wikipedia.org/wiki/Application_firewallErfolgsquote: 100% - "noch keine leeren Reports"Eine Frage der Einstellung: Die einen Entwickler wollen Features bauen, andere Software kaputt machenScope"Ihr dürft nicht nach DoS suchen!"Abgrenzung, was in der Betrachtung liegt und was nichtVektor: Der Angriff an sich, z.B. ein String bei einer SQL Injection; oder Vektor kann ein ganzer Prozess oder Ablauf seinExploit: Nutzung eines Vektors mit einem Ziel: Beispiel String (Source) für SQL Injection (Vektor) nutzen, um Admin zu werdenPwn2Own: https://en.wikipedia.org/wiki/Pwn2OwnStuxnet: https://en.wikipedia.org/wiki/StuxnetBetätigungsfelder (00:22:20)Marios Firma hat für alle möglichen Bereiche Spezialisten:Binary PentestingDatenbankenWeb/Browser/JavaScript/FlashBruteforcingCold FusionKryptographie, KryptoanalyseJavaNeue und alte Probleme (00:24:30)Es verlagert sich viel in den Browserdaher mehr und mehr Lücken in Richtung XSS, CSRF, …NoSQL wird auch getestetMongoDB führt JS in der Datenbank aus und zwar als eval!Auf der Suche nach XSS und anderen Schwachstellen (00:27:00)"Nennt sich doch mal constructor.constructor"oder "prototype""proto"Handhaben von Benutzerinput (00:28:30)Validieren: Format explizit und strikt prüfenFiltern: z.B. Single Quotes oder Kommata entfernenAber so einfach ist das nichtStrings (Quotes) verboten? was ist mit /i'm a string/.source1..constructor.constructorSanitizing:"Escape den Input und Encode den Output"Es ist wichtig zu unterscheiden zwischen der Information die durch das Sanitizing soll, UNDKontext, wo die Information später verwendet werden sollBack to Frontend Security (00:34:30)Template Expressions Exploit, z.B. bei AngularJS: https://code.google.com/p/mustache-security/wiki/AngularJSDer Browser ist die neue SinkSecurity im Browser ist anders und komplexer als auf dem ServerSehr viel mehr Wissen über konkrete Prozesse bei der Darstellung von HTML/CSS und der Ausführung von Javascript notwendigBrowser ist im Grunde "moving target"Die Vielzahl der Browser bietet sehr viel AngriffsflächeVor allem im Kontext großer Unternehmen sind oft auch sehr alte Browser noch im Einsatz (IE6)Eine Umstellung auf neuere Browser ist u.U. nicht immer möglich => Paradies für PentestingIm DOM hört dich keiner schreien (00:46:50)Talk auf der enter.js (http://www.enterjs.de/abstracts#im-dom-hoert-dich-keiner-schreien-eine-reise-in-die-gruselige-schicht-zwischen-html-und-javascript)Historie des DOMsVerschiedene Probleme aufgezeigt, Bsp.: DOM-ClobberingMit statischem HTML bestehende Variablen, Funktionen o.ä. überschreibenIst im Grunde im Standard sogar definiertes Verhalten oOAm Ende kann man sehr viel Spaß nur mit statischem HTML haben :-)Was ist das DOM überhauptEin API zwischen einem Dokument und einer beliebigen Scripting-SpracheZiel des DOM: Bereitstellung von Feature-Parität, dabei müssen einige Features explizit ausgeschlossen werdenBsp: CSS-History-Stealing (http://jeremiahgrossman.blogspot.de/2006/08/i-know-where-youve-been.html)SVG bringt möglicherweise ganz neue Probleme mitTiming Attacke von Paul Stone mit Hilfe von SVG Filtern: http://www.contextis.com/documents/2/BrowserTimingAttacks.pdfManchmal gibt es auch keinen echten Fix für Lücken, und selbst wenn, es gibt ja jetzt auch CSS Shader ;-)Wie geht man vor um Lücken zu findenViel Kreativität notwendigMan hört von einem Feature und denkt sich, da muss doch was gehen und dann wird halt so lange gebohrt bis man was findet ;-)DOMPurify (https://github.com/cure53/DOMPurify) ist ein Client-seitiger Sanitzer, um verschiedenen Angriffen zu begegnenReaktion auf der Konferenz war vor allem gefasst :-)Krypto im Browser und moderne APIs (01:07:45)Grundsätzlich: Bedarf steigt an, Verbreitung nimmt zuMan hört immer wieder von ProblemenWas kann man machen?Antwort: "Ich habe keine Ahnung"Aussage Mario: Wir sind noch nicht soweit, es zuverlässig einzusetzen.Aber: Es ist auch nicht zum Scheitern verurteilt, aber es braucht noch einiges an ResearchSeiten wie https://keybase.io machen das bereitsKann man machen, wenn die Seite 100% sicher und vor allem beweisbar sicher istErgo: Aufwand ist enorm hochEs gibt auch Bestrebungen vom W3C das Thema voranzutreiben: http://www.w3.org/TR/WebCryptoAPI/Zusätzlich entstehen ganz neue APIs für den Zugriff auf mobile DevicesBsp: Android-Devices haben über nicht hörbare Töne miteinander kommuniziert Exploits mit Sprachsynthese und Spracherkennung (Bsp: Cookies zwischen Tabs übertragen)WebGL klingt kritisch, aber in dem Bereich gibt es in den letzten Jahren viel ForschungWebSockets und WebRTC bietet hingegen auch viele Möglichkeiten