This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
German OWASP Day 2015/Programm
Vorläufige Agenda / Vorträge / Presentations
|
| |
| 08:15 - 10:30 | Einlass |
| 08:55 - 9:00 | Begrüßung / Welcome Bois Hemkemeier & Dirk Wetter |
| 09:00 - 9:45 | Morning Keynote: t.b.a Christian Rhino (Commerzbank) |
| 09:45 - 10:15 | Not so Smart: On Smart TV Apps Marcus Niemietz, Juraj Somorovsky and Christian Mainka |
| 10:15 - 10:45 | Your Scripts in My Page - What Could Possibly Go Wrong? Sebastian Lekies and Ben Stock |
| 10:45 - 11:15 | Kaffeepause / Coffee Break |
| 11:15 - 11:45 | Why Organisations should rely on Mobile AppTesting Michael Spreitzenbarth and Jennifer Bombien |
| 11:45 - 12:15 | Löschen können! Die DIN 66398 und die Entwicklung von Anwendungen Volker Hammer |
| 12:15 - 13:15 | Mittagspause / Lunch Break |
| 13:15 - 14:00 | Technical Keynote: t.b.a. Christoph Kern (Google) |
| 14:00 - 14:30 | Practical Invalid Curve Attacks on TLS-ECDH Juraj Somorovsky |
| 14:30 - 15:15 | Lighning Talks
|
| 15:15 - 15:45 | Pause / Coffee Break |
| 15:45 - 16:15 | Webschwachstellen im Internet of Things Christian Dresen and Sebastian Schinzel |
| 16:15 - 16:45 | IT-Sicherheitsgesetz und mögliche Effekte für die Software-Industrie Alexios Fakos |
| 16:45 - 17:15 | Praktische Erfahrungen aus der Applikationssicherheit Amir Alsbih |
Details zu den Vorträgen
Keynotes
- Christian Rhino (Commerzbank): t.b.a
- Christoph Kern (Google): t.b.a
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.
Downloads
(Hier werden die Vorträge zu finden sein, sobald die Slides der Autoren vorliegen)
