Difference between revisions of "German OWASP Day 2015/Programm"

Revision as of 23:32, 2 December 2015

Vorläufige Agenda / Vorträge / Presentations

Downloads

• Christian Rhino: Muss das alles so kompliziert sein? Die Digitalisierung der Finanzindustrie zwischen Kundenerwartungen, Regulierung und FinTechs
• Marcus Niemietz: Not so Smart: On Smart TV Apps
• Sebastian Lekies, Ben Stock: Your Scripts in My Page - What Could Possibly Go Wrong?
• Michael Spreitzenbarth: Why Organisations should rely on Mobile AppTesting
• Volker Hammer: Löschen können! Die DIN 66398 und die Entwicklung von Anwendungen
• Christoph Kern: Technical Keynote: Robuste und Praktikable Ansätze zur Verhinderung von Sicherheitsdefekten
• Juraj Somorovsky: Practical Invalid Curve Attacks on TLS-ECDH
• Björn Kimminich: Hacking the Juice Shop "So ein Saftladen!"
• Vladislav Mladenov, Tim Guenther: EsPReSSO oder eine Erfrischung auf der Suche nach Single Sign-On
• Ralf Reinhardt: OWASP Secure Software Contract Annex auf Deutsch
• Christian Mainka: How to Evaluate Web Services with WS-Attacker
• Christian Dresen and Sebastian Schinzel: Webschwachstellen im Internet of Things
• Alexios Fakos: IT-Sicherheitsgesetz und mögliche Effekte für die Software-Industrie
• Amir Alsbih: Praktische Erfahrungen aus der Applikationssicherheit

Details zu den Vorträgen

Keynotes

Christian Rhino (Commerzbank): Muss das alles so kompliziert sein? Die Digitalisierung der Finanzindustrie zwischen Kundenerwartungen, Regulierung und FinTechs

Christoph Kern (Google): Robuste und Praktikable Ansätze zur Verhinderung von Sicherheitsdefekten

Abstract:

Bestimmte Klassen von Sicherheitslücken, wie z.B. SQL Injection und XSS (Cross-Site Scripting) sind nach wie vor weit verbreitet. Dies ist unserer Ansicht nach darauf zurückzuführen, dass die zugrundeliegenden APIs (z.B. SQL Query APIs, oder APIs der Web Platform) die Einführung von API-spezifischen Programmierfehlern und Sicherheitslücken grundsätzlich ermöglichen. Da diese APIs in großen Entwicklungsprojekten typischerweise weitläufig benutzt werden, ist es zu erwarten, dass Entwickler in einigen dieser API-Aufrufe einen Fehler bezüglich der sicheren Benutzung der APIs machen (z.B., es versäumen, korrekte Datenvalidierung anzuwenden) und somit eine Sicherheitslücke einführen.

Um diesem Problem umfassend zu begegnen hat Google's Informationssicherheitsteam alternative APIs entwickelt, die so konzipiert sind, dass die Vermeidung von API-spezifischen Sicherheitsdefekten nicht mehr in der Verantwortung des Anwendungsentwicklers liegt, sondern Zuständigkeit der APIs und desser Implementierung ist.

Unsere Erfahrungen der letzten Jahre haben gezeigt dass dieser Ansatz auch in sehr komplexen Entwicklungsprojekten praktikabel ist, und zu signifikanter Reduzierung bestimmter Sicherheitsdefekte, insbesondere XSS, führen kann.

Bio:

Christoph Kern ist seit 2003 bei Google im Bereich Informations- und Anwendungssicherheit tätig. Er leitet dort seit 2012 ein Team, das sich darauf spezialisiert hat, Methoden des Software- und Framework-Designs zu entwickeln, die das Risiko der Einführung bestimmter Klassen von Sicherheitsdefekten (z.B., XSS und SQL Injection) drastisch reduzieren.

Lightning Talks

Erstmal dieses Jahr: Lightning Talks auf dem German OWASP Day - Fast, fun und (wenn möglich) mit Demo :)

• Björn Kimminich:. Hacking the Juice Shop ("So ein Saftladen!")
• Christian Mainka, Vladislav Mladenov and Tim Guenther: EsPReSSO oder eine Erfrischung auf der Suche nach Single Sign-On
• Ralf Reinhardt: OWASP Secure Software Contract Annex auf Deutsch
• Christian Mainka and Juraj Somorovsky. How to Evaluate Web Services with WS-Attacker

Technisches Programm

Marcus Niemietz, Juraj Somorovsky and Christian Mainka: Not so Smart: On Smart TV Apps

One of the main characteristics of Smart TVs are apps. Apps extend the Smart TV behavior with various functionalities, ranging from usage of social networks or payed streaming services, to buying articles on Ebay. These actions demand usage of critical data like authentication tokens and passwords, and thus raise a question on new attack scenarios and general security of Smart TV apps.

In this paper, we investigate attack models for Smart TVs and their apps, and systematically analyze security of Smart TV devices. We point out that some popular apps, including Facebook, Ebay or Watchever, send login data over unencrypted channels. Even worse, we show that an arbitrary app installed on devices of the market share leader Samsung can gain access to the credentials of a Samsung Single Sign-On account. Therefore, such an app can hijack a complete user account including all his devices like smartphones and tablets connected with it. Based on our findings, we provide recommendations that are of general importance and applicable to areas beyond Smart TVs, in other Internet of Things scenarios.

Amir Alsbih: Praktische Erfahrungen aus der Applikationssicherheit

In diesem Vortrag sollen die praktischen Erfahrungen geteilt werden, die ich in den letzten 365 Tagen während meiner Tätigkeit als CISO gemacht habe. Dabei werden die wichtigsten Erkenntnissen aus Sicherheitsabnahmen, Audits und Projekten beschrieben. Durch das Aufzeigen der praktischen Realität über eine Vielzahl von Projekten mit unterschiedlichen Beteiligten, unterschiedlichen Größen und unterschiedlichen "Zielgruppen" soll verdeutlicht werden, wie wichtig Kontrollen und Konsequenzen sind.

Michael Spreitzenbarth and Jennifer Bombien: Why Organisations should rely on Mobile AppTesting

The usage of mobile applications is increasing rapidly not only in the private sector but also within organisations. This paper is proposed to provide an overview of available testing solutions and help to answer the most demandable question: are those apps in question secure. Therefore, we will discuss the capabilities of all solutions and introduce a mobile application testing matrix. Within the final part of the presentation we will show some of our findings.

Volker Hammer: Löschen können! Die DIN 66398 und die Entwicklung von Anwendungen

Das Löschen personenbezogener Daten wird vom BDSG gefordert. In der Praxis gibt es große Umsetzungsdefizite. Das hat zwei Ursachen: Die Löschregeln sind nicht definiert und es fehlen Löschmechanismen in Anwendungen. Der Beitrag motiviert, Löschen als eine normale Anforderung zu verstehen, die bereits zu Beginn von Entwicklungsprojekten berücksichtigt werden soll. Entwickler sollten deshalb für die Fragestellung sensibilisiert sein. Löschprojekte können außerdem positive Wirkungen nach sich ziehen, die weit über die Datenschutz-Anforderungen hinausgehen.

Um Löschregeln zu definieren, kann die Vorgehensweise der im September verabschiedeten DIN 66398 verwendet werden: Mit Hilfe von Standardfristen und Typen von Startzeitpunkten werden Löschklassen gebildet. Abgegrenzte Arten personenbezogener Daten können dann leicht in die Löschklassen eingeordnet werden. Daraus ergeben sich die Löschregeln mit je einem Startzeitpunkt und einer Regellöschfrist.

Mechanismen zur Löschung können sehr unterschiedlich implementiert werden. Entwurfsentscheidungen sind z.B. abhängig vom Verarbeitungsprozess, der Einbettung des Systems in die IT-Landschaft oder Datenvolumen. Beispiele für Implementierungsansätze sind:

• Transport-Files, Log-Files etc: dateibasiertes Löschen
• Massendatenverarbeitung: partitionieren von Tabellen nach Zeitscheiben und „Drop Table“
• Datensätze in Datenbanken: (SQL-)Statements auf Tabellen
• Attribut-Ebene: Überschreiben von Werten
• Objektorientierte Ansätze z.B.: Die Klasse „kennt“ die Regellöschfrist; über weitere Attribute kann der Startzeitpunkt und ein „aussetzen-Flag“ gesetzt werden. Über Methoden könnten die löschfälligen Datensätze identifiziert und dann auch gelöscht werden.

Allgemeine Anforderungen an Löschmechanismen:

• Die Löschfrist sollte konfigurierbar sein
• Der Mechanismus muss insgesamt ausgesetzt werden können.
• Je nach Datenart kann es notwendig sein, einzelne Datenobjekte zeitweise aus der Löschung auszunehmen
• Es sollte „sicher“ gelöscht werden.

Die Vorgehensweise kann auch für nicht-personenbezogene Daten angewandt werden. Nutzen – neben der datenschutzgerechten Gestaltung von Prozessen – kann sich ergeben, weil

• Geschäftsprozesse präzisiert werden
• Systeme und IT-Prozesse entkoppelt werden
• Vorgaben für die Datenhaltung getroffen werden
• überflüssige Daten aufgeräumt und Redundanzen abgebaut werden. Dadurch sinken Kosten für den IT-Betrieb und für Migrationen.

Sebastian Lekies and Ben Stock: Your Scripts in My Page - What Could Possibly Go Wrong?

Viele moderne Webseiten generieren JavaScript code dynamisch zur Laufzeit. Dieser JavaScript Code enthält dabei häufig sensitive Benutzerdaten. Obwohl die Same-Origin Policy solche Daten vor Zugriffen Dritter schützt, können solche Scripte von anderen Webseiten eingebunden und zur Ausführung gebracht werden. Dies versetzt einen Angreifer in die Lage, eine sensitive JavaScript Datei zu laden und auszuführen während ein Opfer die Seite des Angreifers besucht. Indem der Angreifer die Seiteneffekte der Ausführung beobachtet, kann er auf die personenbezogenen Daten im Script zugreifen.

Obwohl dieses Problem seit Jahren bekannt ist, wurden bisher weder Untersuchungen noch Schutzmaßnahmen egriffen. Um dieses Problem systematisch zu untersuchen präsentieren wir die Ergebnisse einer empirischen Studie. Dabei haben wir beobachtet, dass zirka ein Drittel aller untersuchten Webseiten, JavaScript Dateien dynamisch generiert und dass 80% dieser Seiten verwundbar gegen den gezeigten Angriff sind. Die gestohlenen Daten erlaubten es uns verschiedenste Angriffe durchzuführen. Die Spanne reichte von einfacher Deanonymisierung eines Web users bis hin zur kompletten Übernahme eines Benutzerkontos.

Juraj Somorovsky: Practical Invalid Curve Attacks on TLS-ECDH

In the recent years, we saw resurrection of many new cryptographic attacks and their application to TLS. Examples give famous attacks like CRIME, BEAST or Lucky13. In our work, we continue this line of research and analyze another forgotten attack: invalid curve attack. Originally published in 2000, the attack is very powerful and allows one to extract private elliptic curve keys from servers using Elliptic Curve Diffie Hellman (ECDH). We analyzed 8 cryptographic libraries and found out that two out of these libraries are vulnerable to these attacks: Java crypto provider and Bouncy Castle.

Christian Dresen and Sebastian Schinzel: Webschwachstellen im Internet of Things

Im Netz gibt es die verschiedensten Geräte, die IP sprechen, mit dem Internet verbunden sind und die teilweise haarsträubende Sicherheitslücken enthalten. Hierzu zählen unter anderem Router, Drucker, Telefone, Kameras, Fernseher und Handys. Der Softwareteil dieser Geräte steht meist als binäres proprietäres Firmware-Image auf den Hersteller-Webseiten zur Verfügung. Die meisten dieser Produkte können über eine Webschnittstelle konfiguriert werden, welche in den unterschiedlichsten Programmiersprachen, zum Beispiel C, lua, PHP oder Perl, geschrieben sind. Diese Webschnittstellen wurden meist unter völliger Missachtung jeglicher Best-Practices der OWASP-Richtlinien entwickelt.

Wir stellen ein neues Werkzeug vor, mit dem wir mittlerweile 1000 Firmwares automatisiert auf Sicherheitsschwachstellen untersucht haben. Dabei wurden einige kritische (und teilweise kuriose) Sicherheitslücken zu Tage gebracht hat. In dieser Präsentation geben wir einen Überblick über das Werkzeug und die von uns gefundenen Webschwachstellen.

Alexios Fakos: IT-Sicherheitsgesetz und mögliche Effekte für die Software-Industrie

Allgemein bekannt ist, dass das verabschiedete IT-Sicherheitsgesetz in erster Linie Betreiber kritischer Infrastrukturen (KRITIS) betrifft. Diese werden zukünftig verpflichtet ein Mindestniveau an IT-Sicherheit einzuhalten und dem Bundesamt für Sicherheit in der Informationstechnik (BSI) IT-Sicherheitsvorfälle zu melden.

Weniger bekannt ist, dass das IT-Sicherheitsgesetz auch Hard- und Software-Hersteller betrifft.

Der Vortrag fokussiert sich auf die Mitwirkungspflicht von Software-Hersteller hinsichtlich der Beseitigung von Sicherheitslücken und stellt denkbare Handlungsmöglichkeiten seitens Betreiber und Hersteller dar.

<top> <zurück> <Germany>