Skip to content

Neues eBook: "Angriffsziel UI - Benutzeraktionen, Passwörter und Clickjacking"

"Angriffsziel UI - Benutzeraktionen, Passwörter und Clickjacking" ist als eBook bei entwickler.press erschienen.

Vorgestellt werden verschiedene Angriffe rund um das UI und wie man sie abwehrt. Die Themen im einzelnen sind

  • Logikfehler, durch die sich die Webanwendung anders verhält als vom Entwickler gedacht.
  • Die Möglichkeiten zur sicheren Authentifizierung der Benutzer, denn einfach nur Benutzername und Passwort abfragen reicht heute nicht mehr aus. Zur wirklich sicheren Authentifizierung muss schon ein zweiter Faktor hinzu gezogen werden, zum Beispiel der Google Authenticator.
  • Aktuelle Entwicklungen rund um das auch als UI-Redressing bezeichnete Clickjacking.

Kapitel 1: Angriffe über Logikfehler

Vorgestellt werden einige typische Logikfehler sowie Möglichkeiten, deren Entstehung zu verhindern.

Was nicht beschrieben wird, ist die Suche nach den Schwachstellen. Die lässt sich nicht so einfach beschreiben, da es zu viele Möglichkeiten für Logikfehler gibt. Sehr vereinfacht gesagt müssen Sie jeden Schritt jeder Funktionalität Ihrer Webanwendung daraufhin prüfen, ob er zu unerwarteten Ergebnissen führen kann. Dafür sind umfassende Kenntnisse über das gewollte Verhalten der Webanwendung notwendig, und wer anders als der Entwickler sollte die besitzen? Falls sich aber ein Logikfehler eingeschlichen hat, dann weil es an eben diesen Kenntnissen irgendwo gefehlt hat. Das sind schlechte Voraussetzungen für eine erfolgreiche Suche, nicht war? Darum setzen Sie alles daran, Logikfehler von Anfang an zu vermeiden.

Kapitel 2: Sicheres Einloggen mit zwei Faktoren

Die Kombination aus Benutzername und Passwort reichte lange aus, um einen Benutzer sicher zu identifizieren. Inzwischen gelangen diese Zugangsdaten immer öfter in falsche Hände. Also muss ein zusätzlicher Faktor die Authentifizierung absichern, wenn man wirklich auf Nummer Sicher gehen will.

Es werden die verschiedenen Methoden zur Authentifizierung beschrieben und einige Beispiele für eine Zwei-Faktor-Authentifizierung mit ihren jeweiligen Vor- und Nachteilen vorgestellt. Den zur Zeit besten Kompromiss hinsichtlich Sicherheit und Benutzerfreundlichkeit dürfte meist eine Smartphone-App zum Erzeugen von Einmal-Passwörtern wie zum Beispiel der Google Authenticator darstellen.

Die Token zum Erzeugen von Einmalpasswörtern sind sicher (wenn der Hersteller nicht falsch spielt), aber teuer. Die Smartphone-Apps sind eine gute Alternative, so lange es noch keine spezielle Schadsoftware gibt, die sie angreift. Warum sollte man also nicht zum Google Authenticator greifen? Immerhin ist der sogar Open Source und man kann ziemlich sicher sein, dass keine Hintertür enthalten ist.

Kapitel 3: UI-Redressing aka Clickjacking

Clickjacking ist inzwischen 6 Jahre alt - und es gibt immer wieder neue Varianten und Angriffsmöglichkeiten. Inzwischen sogar ohne den Einsatz unsichtbarer iframes.

Die Cyberkriminellen scheinen Clickjacking jetzt für ihre dunklen Geschäfte nutzen zu wollen. Es wird also höchste Zeit, dass Sie ihre Webanwendungen vor solchen Angriffen schützen. Da die meisten von Ihnen "normale" Webanwendungen entwickeln werden, reichen Ihnen auch die normalen Schutzmaßnahmen. Wenn Sie Sonderfälle vergleichbar mit Facebooks Like-Button implementieren, wird der Schutz vor einem Missbrauch schwieriger. Denn wie Devdatta Akhawe et al. gezeigt haben, führen dann unter Umständen schon ein paar einfache Zaubertricks zum Erfolg des Angriffs. Im Notfall wird Ihnen also nichts anderes übrig bleiben, als auf eine einfache 1-Klick-Lösung zu verzichten. Eine Passwortabfrage oder ein CAPTCHA lassen sich mit Clickjacking nicht umgehen.

Links und Literaturverweise

Kapitel 1: Angriffe über Logikfehler

Kapitel 2: Sicheres Einloggen mit zwei Faktoren

Kapitel 3: UI-Redressing aka Clickjacking

Carsten Eilers

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!