German OWASP Day 2012/Programm

[zurück]

Downloads

 * Volkmar Lotz Hoff [[Media:Security-Ausbildung_in_einem_Grossunternehmen_-_Volkmar_Lotz.pdf‎|Security-Ausbildung in einem Großunternehmen der Softwareindustrie - Erfahrungen und Herausforderungen ]]
 * Jim Manico, Jerry Hoff [[Media:OWASP_Germany_-_Jim_Manico+Jerry_Hoff.pdf|OWASP Introduction]]
 * Mario Heiderich {missing}
 * Bruce Sams  [[Media:Code_Review_Prinzipien_Grenzen_und_Organisation_-_Bruce_Sams.pdf|Code Review: Prinzipien, Grenzen und Organisation]]
 * Sebastian Schinzel [[Media:Lost_in_Translation_Missverstaendnisse_zwischen_Mensch_und_Maschine_-_Sebastian_Schinzel.pdf|Lost in Translation]]
 * Juraj Somorovsky, Christian_Mainka [[Media:Breaking_SAML_Be_Whoever_You_Want_to_Be_-_Juraj_Somorovsky%2BChristian_Mainka.pdf|On Breaking SAML: Be Whoever You Want to Be ]]
 * Ruediger Bachmann, Achim Brucker [[Media:1000_Projects_later_Security_Code_Scans_at_SAP_-_Ruediger_Bachmann%2BAchim_Brucker.pdf|1000 Projekte später: Statische Codeanalyse Sicherheitscode-Scans in der SAP]]
 * Simon Bennetts [[Media:Zed_Attack_Proxy_-_Simon_Bennetts.pdf|OWASP Zed Attack Proxy]]
 * Matthias Rohr [[Media:Threat_Modeling_von_Webanwendungen_Mythen_und_Best_Practices_-_Matthias_Rohr.pdf|Threat Modeling von Webanwendungen: Mythen und Best Practices]]
 * Jim Manico [[Media:Top_Ten_Defenses_-Jim_Manico.pdf|Sheet Cheats - Top Ten Defenses]]
 * Sachar Paulus [[Media:Sicherheitsanforderungen_oft_vernachlaessigt_dabei_sehr_nuetzlich_-_Sachar_Paulus.pdf|Sicherheitsanforderungen: oft vernachlässigt, dabei sehr nützlich!]]
 * Sven Vetsch [[Media:Node.js_Security_Old_vulnerabilities_in_new_bottles_-_Sven_Vetsch.pdf|Node.js Security - Old vulnerabilities in new bottles]]
 * Andreas Kurtz [[Media:Laufzeitanalyse_von_iOS_Apps_-_Andreas_Kurtz.pdf|Laufzeitanalyse & Manipulation von Apple iOS Apps]]
 * Tal Beery [[Media:OWASP-CAPTCHA_modified_ah_-_Tal_Beery.pdf‎|A CAPTCHA in the Rye]]
 * Sebastian Lekies, Martin Johns [[Media:Lightweight_Integrity_Protection_for_Web_Storage-driven_Content_Caching_-_Sebastian_Lekies%2BMartin_Johns.pdf|Lightweight Integrity Protection for Web Storage-driven Content Caching]]
 * Michael Spreitzenbarth [[Media:The_Dark_Side_of_Android_Applications_-_Michael_Spreitzenbarth.pdf|The Dark Side of Android Applications]]
 * Florian Stahl [[Media:Privacy_by_Design_-_Florian_stahl.pdf‎|Privacy by Design am Beispiel Facebook]]
 * Bastian Braun, Patrick Gemein, Hans Reiser [[Media:Der_Weg_ist_das_Ziel_Kontrollfluss-Integritaet_in_Web-Applikationen_sichern_-_Bastian_Braun%2bPatrick_Gemein%2BHans_Reiser.pdf|Der Weg ist das Ziel: Kontrollfluss-Integritaet in Web-Applikationen sichern]]
 * Marcus Niemietz [[Media:UI-Redressing-Angriffe-auf-Android_-_Marcus_Niemietz.pdf|UI-Redressing-Angriffe auf Android]]
 * Angela Sasse [[Media:Making_systems_secure_and_usable_-_Angela_Sasse.pdf‎|Making systems secure and usable - what can software developers do]]

Mario Heiderich — XSS von 1999 bis 2013: Die Doctrine Classique der Websicherheit
Cross-Site Scripting Angriffe wurden erstmals vor circa 14 Jahren dokumentiert. Seitdem hat diese Angriffstechnik eine Evolution durchzogen, die klassischen Dramentheorie ähnelt - inklusive Katastase, Heldentum und Peripetie.

Nun hält HTML Einzug in die Welt der Betriebssysteme, und das Drama XSS befindet sich an der Baumgrenze zur Katastrophe - der harmlose "Alert" hat sich zum schwarzen Schwan beliebiger Code-Ausführung im Betriebssystem gewandelt.

Dieser Vortrag zeigt die Evolution der Angriffstechnik XSS, untersucht unser aller Fehler in der bisherig angewandten Bekämpfung, bietet konsequente Ausblicke und schließt mit Denkanstößen für das Jahr 2013 und fortfolgend.

Bruce Sams — Code Review: Prinzipien, Grenzen und Organisation
Code Review ist ein immer beliebteres Mittel, um Schwachstellen im Code während der Entwicklung zu entdecken. Dieser Vortrag zeigt wie ein effektiver Code Review gestaltet und durchgeführt wird. Zuerst werden die Prinzipien von Code Review anhand von aktuellen Beispielen in Java/JEE erläutert: Cross-Site-Scripting, SQL-Injection, Command-Injection und die Validierung von Eingabedaten werden besprochen und Lösungen gezeigt, wie derartige Schwachstellen identifiziert werden können. Danach werden problematische Fälle wie z.B. HashMaps und dynamisch geladene Klassen untersucht. Im Allgemeinen wird das Thema Tracing über mehrere Aufrufe hinweg erklärt, und das Verhältnis False Positive zu False Negative angesprochen.

Zur Verdeutlichung der Beispiele wird das Open Source Tool FindBugs verwendet. Darüber hinaus wird ein neuer Satz von über 30 Detektoren für Findbugs vorgestellt. Diese Detektoren identifizieren Schwachstellen, die standardmäßig unentdeckt bleiben. Zum Abschluss wird die Organisation eines Reviews besprochen und die Integration von Code Review in dem sicheren SDLC vorgestellt. Diese Diskussion basiert auf eingehende Erfahrung in mehreren deutschen Großunternehmen.

Am Ende hat der Teilnehmer einen Überblick über die Vorteile und auch die Grenzen von Code Review und weiß, wie ein effektiver Review gestalten werden soll.

Sebastian Schinzel — Lost in Translation: Missverständnisse zwischen Mensch/Mensch und Mensch/Maschine und deren Auswirkungen auf Web-Security
Wir schreiben das Jahr 2012 und in vielen Web-Entwicklungsprojekten wird das Thema "Sicherheit" noch immer als notwendiges Übel angesehen. Gerade erfahrene Entwickler sind oft zu sehr überzeugt von ihrer eigenen Codequalität, als dass sie offen für Feedback und konstruktive Kritik sind. Wenn es hart-auf-hart kommt, und Sie sich als Sicherheitsexperte gegen solche Entwickler behaupten wollen, dann benötigen Sie gute Argumente.

In diesem interaktiven Vortrag stelle ich einige scheinbar trivial verständliche Quellcodebeispiele vor, die selbst von erfahrenen Programmierern (und wahrscheinlich auch vom OWASP Publikum) falsch verstanden werden. Weiterhin untersuche ich einige öffentlich gewordene Backdoors, die von Angreifern in den Quellcode der Web-Anwendungen eingeschleust wurden. Aus den Beispielen wird klar, dass viele Backdoors auf den ersten Blick (und auch auf den zweiten) harmlos aussehen, und die Schadroutine nur bei sehr genauem Hinsehen klar wird.

Die vorgestellten Beispiele verwende ich regelmäßig in Workshops, um übermäßig selbstbewussten Web-Entwicklern zu veranschaulichen, dass auch sie in ihrem Verständnis von Quellcode nicht unfehlbar sind. Das ist eine wichtige Erkenntnis, um einzusehen, dass niemand vor Sicherheitsschwachstellen gefeit ist und dass selbst erfahrene Web-Entwickler regelmäßig in sicherer Softwareentwicklung geschult werden müssen.

Juraj Somorovsky and Christian Mainka — On Breaking SAML: Be Whoever You Want to Be
The Security Assertion Markup Language (SAML) is a widely adopted language for making security statements about subjects. It is a critical component for the development of federated identity deployments and Single Sign- On scenarios. In order to protect integrity and authenticity of the exchanged SAML assertions, the XML Signature standard is applied. However, the signature verification algorithm is much more complex than in traditional signature formats like PKCS#7. The integrity protection can thus be successfully circumvented by application of different XML Signature specific attacks, under a weak adversarial model.

In this talk we describe an in-depth analysis of 14 major SAML frameworks and show that 11 of them, including Salesforce, Shibboleth, and IBM XS40, have critical XML Signature wrapping vulnerabilities. We present efficient and practical countermeasures to thwart these attacks. Moreover, based on our analysis, we developed an automated penetration testing tool for XML Signature Wrapping called WS-Attacker. We discuss its main features and its application to SAML-based frameworks.

Rüdiger Bachmann and Achim D. Brucker — 1000 Projekte später: Statische Codeanalyse Sicherheitscodesans in der SAP
Statische Code Analyse (SCA) spielt in einem sicheren Softwareentwicklungsprozess (SDL) eine wichtige Rolle um mögliche Sicherheitsschwachstellen bereits zur Entwicklungszeit zu finden und zu beheben.

Die großflächige Einführung statischer Code Analyse bei einem großen Softwarehersteller stellt eine große Herausforderung dar. Neben den technischen Schwierigkeiten durch die schiere Anzahl und Größe der Softwareprojekte, der Vielzahl unterschiedlicher Programmiersprachen (ABAP, C, Objective-C, ...) oder die Verwendung dynamischer Programmiermodelle wie sie z.B. bei HTML5/JavaScript üblich sind, ergeben sich auch nicht-technische Probleme wie die Schaffung des notwendigen Problembewusstseins, Schulung der Mitarbeiter im Umgang der verwendeten Tools, Einbindung der Analyse in vorhandene Entwicklungs- und Wartungsprozesse.

In diesem Vortrag berichten wir von unseren Erfahrungen in der großflächigen Einführung von statischer Code Analyse innerhalb der SAP AG.

Simon Bennetts — OWASP Zed Attack Proxy
The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is community project, being maintained by a worldwide group of volunteers and is completely free, open source and cross platform. Since its release in 2010 ZAP has gone from strength to strength and is now a flagship OWASP project.

Simon (the ZAP project lead) will:
 * Introduce ZAP to those who have not encountered it before
 * Detail the new features in the most recent releases
 * Explain the 3 ZAP related Google Summer of Code projects
 * Talk about the future plans

Matthias Rohr — Threat Modeling von Webanwendungen: Mythen and Best Practices
Mittels einer Bedrohungsmodellierung (engl. Threat Modelling) lassen sich Risiken, wie etwa potentielle Schwachstellen, bereits frühzeitig im Rahmen der Entwicklung einer Webanwendung identifizieren und mit entsprechenden Maßnahmen entgegenwirken. Auch können Penetrationstests und andere Testmethoden auf Basis eines bestehenden Bedrohungsmodells in der Regel deutlich effektiver geplant und durchgeführt werden.

In der Praxis ist die konkrete Durchführung allerdings häufig mit zahlreichen Schwierigkeiten verbunden. So existieren zwar einige konkrete Vorgehensweisen (z.B. Microsoft, PASTA, T-MAP, TRIKE sowie gleich mehrere auf der OWASP-Webseite selbst), doch verfolgen diese teilweise recht unterschiedliche Ansätze und eignen sich gewöhnlich auch nur für bestimmte Anwendungsszenarios und Zielgruppen. Auch deshalb ist die Verwirrung beim Thema Bedrohungsmodellierung häufig recht groß.

Im Rahmen dieses Vortrages, der auf mehrjährigen Erfahrungen mit der der Erstellung von Bedrohungsmodellen von Webanwendungen basiert, werden zahlreiche geläufige Mythen aufgeklärt und entsprechende Best Practices erläutert. Weiterhin wird eine praxisbezogene Vorgehensweise vorgestellt, mit der sich die Durchführung von Bedrohungsmodellierungen leicht skalieren, in unterschiedlichen Szenarien einbinden und effektiv in bestehende Entwicklungsprozesse integrieren lässt.

Jim Manico — Sheet Cheats
We cannot hack or firewall our way secure. Application programmers need to learn to code in a secure fashion if we have any chance of providing organizations with proper defenses in the current threatscape. This talk will discuss the 10 most important security-centric computer programming techniques necessary to build low-risk web-based applications. This talk is best suited for technical web application development professionals at any stage of the software development lifecycle.

Sachar Paulus — Sicherheitsanforderungen: oft vernachlässigt, dabei sehr nützlich!
Die Formulierung von Sicherheitsanforderungen findet in vielen Projekten so gut wie nie statt - doch wie soll eine Software "sicher" sein, wenn noch nicht einmal klar ist, was "sicher" bedeuten soll.

Dieser Vortrag gibt einen Überblick wie Kunden und Nutzer von Software und Software-Entwicklungsprojekten durch recht schlanke Prozesse zur Erstellung von Sicherheitsanforderungen die Sicherheit der verwendeten Applikationen deutlich verbessern können.

Für das Testen auf Sicherheit, also die Untersuchung von Software auf Schwachstellen werden meist Prüfkataloge und Best Practices herangezogen, die die Erfahrungen und das Know-How der testenden Organisation widerspiegeln, und leider nicht die Aspekte, die ein gezielter Angriff mit entsprechender Vorab-Analyse ausnutzen würde. Das ist in etwa vergleichbar mit dem Bild, bei dem ein betrunkener Mann seinen verlorenen Hausschlüssel im Lichtkreis einer Laterne sucht - und nicht da, wo er ihn verloren hat, mit der Begründung: im Licht sehe er wenigstens etwas…

Die Lösung dieser Problematik besteht darin, dass man das, was getestet (und natürlich vorher entwickelt) werden soll, überhaupt erst einmal erfasst und beschreibt. So wie es für funktionale Anforderungen seit Jahren üblich ist, so müssen auch nicht-funktionale Anforderungen, hier speziell Sicherheitsanforderungen, auch aufgenommen und dokumentiert werden.

Für die Ermittlung von Sicherheitsanforderungen kann sehr gut eine vereinfachte Variante der Bedrohungsmodellierung herhalten. Um das Testen einfacher zu machen, können für nicht-funktionale Anforderungen Akzeptanzkritrien formuliert werden. Dies sind nur zwei einfache Werkzeuge, diese werden im Vortrag ausführlicher dargestellt.

Sven Vetsch — Node.js Security - Old vulnerabilities in new bottles
New technologies are a good thing as they drive innovation. Especially in the web world, innovation is what lead to todays popularity of sites like Google, Twitter and Facebook. Regarding security, new technologies also come with the possibility to avoid known security issues already in the design of a technology or for example a new programming language. Unfortunately most of the time, security is not a main focus and therefor also known faults are done over and over again. In addition to this, new technologies also tend to invent new vulnerability classes or at least open new ways to exploit known security issues.

In this talk I'll take as a practical example the Node (Node.js) project which allows server side non-blocking JavaScript development. It's great to have the same language for the frontend as for the backend as it makes things much easier to connect and also the frontend and backend developers can better understand each others work. Many people still think about JavaScript as static *.js files somewhere in a web accessible directory which is not security relevant as it's static. This is simply not the case. In the past there where already a lot of reported security problems related to JavaScript so the question is: Will those problems also affect Node? I will answer this and more questions during the talk but be assured, we'll end up with a reverse shell ;)

Andreas Kurtz — Laufzeitanalyse & Manipulation von Apple iOS Apps
Mit der Veröffentlichung des Software Development Kits für die Apple iOS Plattform im Jahr 2008, wurde es erstmals offiziell möglich, Apples mobile Geräte um eigenentwickelte Applikationen (Apps) zu erweitern. Seit dieser Zeit wurden in Apples App Store mehr als 650.000 Apps bereitgestellt und diese über 30 Milliarden Mal heruntergeladen (Stand: Juni 2012).

iOS Apps werden dabei primär in Objective-C entwickelt. Objective-C ist eine objektorientierte Erweiterung und strikte Obermenge der Programmiersprache C, deren Syntax und Konzeption stark an Smalltalk angelehnt ist. Ähnlich wie viele andere moderne Programmiersprachen, bietet auch die Objective-C Laufzeitumgebung eine umfangreiche Reflection-API. Diese ermöglicht den Zugriff sowie die Manipulation von Klassen und Methoden zur Laufzeit. Dadurch können interne App-Zustände und Abläufe zur Laufzeit beliebig manipuliert werden.

Im Rahmen des Vortrags werden zunächst die Hintergründe und erforderlichen Techniken zur Laufzeitmanipulation von iOS Apps erläutert: Durch das Einbringen von Bibliotheken in den Prozess einer laufenden App wird diese nachträglich um Debugging-Funktionalitäten erweitert. Anschließend können darüber interne Abläufe untersucht und verändert, vorhandene Methoden beliebig ausgeführt oder deren Implementierung überschrieben werden. Anhand einiger Praxisbeispiele wird demonstriert, wie die Laufzeitmanipulation das Reverse Engineering von Apps erleichtern kann und welche neuen Bedrohungen daraus für mobile Apps resultieren.

Robert Rachwald — A CAPTCHA in the Rye
A CAPTCHA, or Completely Automated Public Turing test to tell Computers and Humans Apart, is a common security measures used to distinguish between humans and a "phony". Ideally, a CAPTCHA should distinguish human users from automated browsing applications, preventing automated tools from abusing online services. Hackers have deployed numerous methods to bypass CAPTCHAs, such as outsourcing readers to India or creating CAPTCHA games that reward users with pornographic images.

The line between real and phony isn’t clear, forcing security professionals to present CAPTCHAs sub optimally. This talk will present several innovative CAPTCHA methods have appeared recently and review the use of CAPTCHAs as a security mechanism against malicious automation. We report and analyze four case studies and provide recommendations on ways to implement CAPTCHAs as an integrated part of a security strategy. Specifically, security teams should:


 * Use novel CAPTCHA methods that make the CAPTCHA into something enjoyable, like a mini-game.
 * Minimize the number of CAPTCHA challenges that legitimate users encounter.

The idea is to present a CAPTCHA only when users exhibit suspicious behavior. To detect such, the site should use the other automation detection mechanisms.

Sebastian Lekies — Lightweight Integrity Protection for Web Storage-driven Content Caching
The term Web storage summarizes a set of browser- based technologies that allow application-level persistent storage of key/values pairs on the client-side. These capabilities are frequently used for caching of markup or script code fragments, e.g., in scenarios with specific bandwidth or responsiveness requirements.

Unfortunately, this practice is inherently insecure, as it may allow attackers to inject malicious JavaScript payloads into the browser’s Web storage. Such payloads reside in the victim’s browser for a potentially prolonged period and lead to resident compromise of the application’s client-side code.

In this paper, we first present three possible attack scenarios that showcase how an attacker is able to inject code into web storage. Then we verify that Web storage is indeed used in the outlined, insecure fashion, via a large-scale study of the top 500.000 Alexa domains. Furthermore, we propose a lightweight integrity protecting mechanism that allows developers to store markup and code fragments in Web storage without risking a potential compromise. Our protection approach can be introduced without requiring browser modifications and introduces only negligible performance overhead.

Michael Spreitzenbarth — The Dark Side of Android Applications
It is now well-known that, for various reasons, Android has become the leading OS for smartphones with more than 50% of worldwide market share within only a few years. This fast growth rate also has an evil side. Android brought backdoors and trojans to the yet spared Linux world with growth rates of over 3,000% in the last half of 2011 and about 15,000 newly discovered malicious applications in the second quarter of 2012.

These malicious apps are only seldomly obfuscated and very basic in their functionality. In this presentation, we will give a short overview of the existing malware families and their main functionalities. As an example, we will present the results of reverse engineering a paradigmatic malware sample of the FakeRegSMS family. This sample was chosen because it tries to implement the first very simple approaches of obfuscation and behavior hiding.

Afterwards, we will show how actual malware detection systems are working. In this step we will concentrate on, often self-written, static detection modules. The detection mainly relais on the combination of permissions, receivers and API calls. Some of these systems also try to detect if an application is under- or over-privileged by comparing the API calls and the requested permissions. The well known systems (MobileSandbox and Andrubis) use a dynamic analysis with TaintDroid/DroidBox as an additional step. These systems perform taint-analysis and monitor sensitive data throughout the complete data-flow of the application. With this functionality it is possible to detect which sensitive data is leaving the device. With the knowledge we gained in this step, we will then discuss why developers should take care of permissions and ad-networks they use within their applications.

Especially ad-networks are a reason why benign apps are detected as malicious with an increasing frequency. This happens because this networks often send sensitive user data like unique identifiers (IMEI, IMSI, etc.) and sometimes even stored contact and calendar entries over the Internet. One of the most aggressive ad-networks is mobclix, which tries to get access to stored account data, location of the user and even tries to get write access to contacts and calendar. The well known ad-library mOcean is even able to send SMS messages and start phone calls without user interaction and notice.

We conclude with discussing the following questions: How do you get infected? What was the main goal of malware authors in recent malicious applications? And finally, how does the future of malware look like?

Florian Stahl — Privacy by Design am Beispiel Facebook
Der Vorschlag für die Überarbeitung der Anfang des Jahres publizierten europäischen Datenschutzrichtlinie sieht vor das Konzept „Privacy by Design“ (PbD) verpflichtend zu machen. Dies wird auch bei der Entwicklung von Webanwendungen zu neuen Anforderungen führen, wenn diese personenbezogene Daten verarbeiten. Bisher wird Privacy by Design selten konsequent berücksichtigt, da Datenschutz kaum als explizite Anforderung im Pflichtenheft auftaucht und vielen Projektleitern und Softwareentwicklern die Kenntnisse in dem Bereich fehlen. Deshalb werden in diesem Vortrag die zukünftig erforderlichen Grundlagen von Privacy by Design erläutert und Beispiele geliefert, die sich bei der Entwicklung von Webapplikationen in der Praxis bewährt haben. Dabei werden auch die sieben Prinzipien von Privacy by Design nach Ann Cavoukian (kanadische Mitgründerin des Konzepts) vorgestellt.

Neben dem datenschutzfreundlichen Design von Produkten bzw. Applikationen z.B. durch Anonymisierung, Verschlüsselung und Datensparsamkeit gelten u.A.Transparenz, Datenschutz als Standard-Einstellung (Default) und der Schutz von Daten im kompletten Lebenszyklus als zentrale Aspekte von Privacy by Design. Die Vorgaben gelten aber nicht nur für die Applikation selbst, sondern auch für die Prozesse rund um die Entwicklung und den Transfer von Daten z.B. während der Migration.

Für existierende Webanwendungen sollte nach der für 2014 geplanten Einführung der neuen Richtlinie ein "Privacy by Redesign" in Erwägung gezogen werden, um fehlende Datenschutz-Maßnahmen nachträglich zu implementieren. Ein derartiges Vorgehen wird im Vortrag am Beispiel des sozialen Netzwerks Facebook vorgestellt, das in der Vergangenheit durch seinen umstrittenen Umgang mit den Daten seiner Nutzer aufgefallen ist. Es wird untersucht, ob und wie man das soziale Netzwerk konform zum Konzept Privacy by Design machen könnte, denn die neuen europäischen Datenschutzvorgaben sollen auch für nicht-europäische Unternehmen gelten, wenn sie Daten von EU-Bürgern speichern oder verarbeiten.

Bastian Braun, Patrick Gemein und Hans Reiser — Der Weg ist das Ziel: Kontrollfluss-Integrität in Web-Applikationen sichern
Moderne Web-Applikationen implementieren häufig komplexe Kontrollflüsse, die erfordern, dass die Benutzer ihre Aktionen in einer bestimmten Reihenfolge ausführen. Die Benutzer interagieren mit Web-Applikationen durch das Senden von HTTP-Anfragen (requests) mit Parametern und den Empfang von Antworten (responses), die Verweise (hyperlinks) enthalten und dadurch die nächsten Schritte bestimmen. Falls eine Web-Applikation darauf vertraut, dass Benutzer nur den in ihre Webseiten eingebundenen Verweisen folgen, können bösartige Benutzer Anfragen generieren, die auf Seiten des Betreibers der Web-Applikation Schaden anrichten.

Analysen von Angriffen mit Benutzer-generierten Anfragen auf Web-Applikationen zeigen, dass die Ursache in der fehlenden Kontrollfluss-Definition und –Durchsetzung auf Serverseite zu finden ist. Unter anderem hat sich herausgestellt, dass die verwendeten Parameter ein wichtiger Aspekt der Wirkung von Anfragen sind. Darauf aufbauend haben wir einen Kontrollfluss-Monitor entwickelt, der sowohl bei existierenden als auch bei neu zu entwickelnden Web-Applikationen angewendet werden kann. Er wird über eine Kontrollfluss-Definition konfiguriert und garantiert der geschützten Web-Applikation, dass ausschließlich die definierten Anfrage-Sequenzen und erwartete Parameter von der Web-Applikation verarbeitet werden müssen.

Der implementierte Kontrollfluss-Monitor verhindert Race Conditions, eine besondere Form von Angriffen auf die Kontrollfluss-Integrität von Web-Applikationen. Darüber hinaus unterstützt er aktuelle Browser-Features wie Multitabbing und die Verwendung des "Zurück"-Knopfes. Die Evaluierung ergab, dass der Kontrollfluss-Monitor einen erträglichen Overhead verursacht.

Marcus Niemietz — UI-Redressing-Angriffe auf Android
Bereits im Jahr 2002 war der Security-Community intuitiv klar, dass transparente Elemente innerhalb eines Webbrowsers eine Gefahr für den Benutzer darstellen. Dies resultierte unmittelbar aus der Überlegung, dass ein Opfer auf ein Element wie eine Schaltfläche klicken kann, ohne zu sehen das ein Klick auf diese Schaltfläche erfolgt. Das daraus abgeleitete Verfahren wurde im Jahr 2008 neu aufgegriffen und mit dem Begriff Clickjacking bezeichnet. Dabei hatte ein Angreifer die Möglichkeit einen automatischen Zugriff auf die Kamera sowie das Mikrofon eines Opfers (ohne dessen Wissen) zu erhalten. Seit dem Jahr 2008 hat sich eine Vielfalt von auf Clickjacking basierenden Angriffen gebildet, die heutzutage unter der Angriffsmenge des UI-Redressing fallen.

In diesem Vortrag wird gezeigt, welche UI-Redressing-Angriffe und Gegenmaßnahmen sich auf das Betriebssystem Android übertragen lassen. Dabei wird ein Schwerpunkt auf Clickjacking ähnliche Angriffsmethoden (Tapjacking) gelegt, die keinen Webbrowser benötigen. Ein Angreifer kann daher mit einer Applikation, die bspw. keine Rechte zum telefonieren hat, mit nur einer Touch-Geste eine beliebige und vom Angreifer definierte Telefonnummer ungewollt anrufen.

Sprecher
(in alphabetischer Ordnung)

Simon Bennetts
(a.k.a. Psiinon) has been developing web applications since 1997, and strongly believes that you cannot build secure web applications without knowing how to attack them. He works for Mozilla as part of their Security Team.

Some of the projects Simon works on: 'Penetration Testing for Developers' blog author
 * OWASP Zed Attack Proxy project lead
 * OWASP Data Exchange Format project lead
 * Bodge It Store project lead
 * OWASP AppSensor contributor
 * wavsep contributor

He is also one of the chapter leaders for the OWASP Manchester chapter.

Simon has a B.Sc in Computing and Information Systems from Manchester University.

Bastian Braun
erhielt sein Diplom in Informatik und sein Vordiplom in Betriebswirtschaftslehre an der RWTH Aachen im Sommer 2006. Danach schloss er sich als Doktorand der Forschungsgruppe „Sicherheit in Verteilten Systemen“ an der Uni Hamburg an. 2008 folgte er seinem Doktorvater Joachim Posegga an die Uni Passau, wo er seitdem Mitglied des Instituts für IT-Sicherheit und Sicherheitsrecht ist. Zur Zeit arbeitet er an dem EU-Forschungsprojekt WebSand als Leiter des Arbeitspakets für sichere Web-Interaktion.

Dr. Mario Heiderich
arbeitet als Forscher für die Ruhr-Universität in Bochum, findet Lücken im IE und anderen Tools für Microsoft in Redmond und arbeitet im wesentlichen im Bereich HTML5- und SVG- und Browser-Sicherheit.

Mario glaubt allen ernstes, man könne XSS mittels JavaScript verhindern und besiegen, schrieb darüber eine Dissertation und hat auch sonst eher wunderliche Ansichten.

In der verbleibenden Zeit pen-testet und berät Mario diverse DAX-Unternehmen, spricht auf internationalen Konferenzen und hat irrationale Freude am Finden von Bugs und Designfehlern.

Volkmar Lotz
Volkmar Lotz has more than 20 years experience in industrial research on Security and Software Engineering. He is heading the Security & Trust practice of SAP Research, a group of 40+ researchers investigating into applied research and innovative security solutions for modern software platforms, networked enterprises and Future Internet applications. The Security & Trust practice defines and executes SAP's security research agenda in alignment with SAP's business strategy and global research trends.

Volkmar’s current research interests include Business Process Security, Service Security, Authorisation, Security Engineering, Formal Methods and Compliance. Volkmar has published numerous scientific papers in his area of interest and is regularly serving on Programme Committees of internationally renowned conferences. He has been supervising various European projects, including large-scale integrated projects. Volkmar holds a diploma in Computer Science from the University of Kaiserslautern.

Jim Manico
is the VP of Security Architecture for WhiteHat Security. Jim is also the host of the OWASP Podcast Series, is the committee chair of the OWASP Connections Committee, is the project manager of the OWASP Cheatsheet series, and is a significant contributor to several additional OWASP projects. Jim provides secure coding and developer awareness training for WhiteHat Security using his 8+ years of experience delivering developer-training courses for SANS, Aspect Security and others. He brings 16 years of database-driven Web software development and analysis experience to WhiteHat and OWASP as well. Jim works on the beautiful island of Kauai, Hawaii where he lives with his wife Tracey.

Marcus Niemietz
forscht an der Ruhr-Universität Bochum nach Methoden, um Hackern einen Schritt voraus zu sein und sowohl UI-Redressing als auch Cross-Site Scripting Angriffe zu verhindern. Er ist ein aktiver Sprecher auf zahlreichen internationalen IT-Security Konferenzen; in der Vergangenheit u. a. auf der Hackerkonferenz von Microsoft in Redmond. Darüber hinaus arbeitet er als Penetrationstester und Web-Security-Trainer. Marcus Niemietz ist ein publizierender Buchautor im Bereich der Websicherheit.

Matthias Rohr
(CISSP, CSSLP, CCSK) ist selbstständiger Berater für Anwendungssicherheit und momentan wohnhaft in London. Er befasst sich schwerpunktmäßig mit Konzeption und Management von Anwendungssicherheit in Enterprise Umgebungen sowie mit entwicklungsnahen Sicherheitsthemen.

Prof. M. Angela Sasse
is the Professor of Human-Centred Technology and Head of Information Security Research in the Department of Computer Science at University College London. Since 1996, Prof. Sasse has been researching usability issues of security systems, and published research on effectiveness and usability of authentication mechanisms, access control mechanisms, user attitudes and perceptions to computer security, and human and financial cost of security mechanisms. She chairs the Cybersecurity KTN on Human Vulnerabilities in Security Systems, and teaches a Masters-level course at UCL, Oxford University, and the Defence Academy.

Dr. Sebastian Schinzel
forscht als Postdoc an der FAU Erlangen am Lehrstuhl für IT-Sicherheitsinfrastrukturen an den Themen Penetrationstests und Softwaresicherheit. Vor seiner akademischen Laufbahn hat er mehr als 7 Jahre als Penetrationstester, Berater und Autor in der Wirtschaft gearbeitet.

Florian Stahl
ist als Senior Consultant für Information Security bei der msg systems ag in München tätig. Er ist Diplom-Wirtschaftsinformatiker, Master of Computer Science, CISSP und CCSK und treibt die Umsetzung von Informationssicherheits- und Datenschutz-Anforderungen in zahlreichen Projekten zur Entwicklung oder Prüfung von Webanwendungen voran. Herr Stahl hat langjährige internationale Erfahrung in der Beratung und Schulung zu technischen und organisatorischen Datenschutz-Themen bei DAX-Unternehmen und ist Mitglied der IAPP (International Association of Privacy Professionals). Seine aktuellen Kernthemen sind Privacy by Design und Aspekte der überarbeiteten EU-Richtlinie zum Datenschutz.

 