Web Security Day auf der IPC/WebTech 2013

Die OWASP-Top-10 der Web-Sicherheitsrisiken
Kommentare

Web-Sicherheit ist ein Thema, mit dem man sich beschäftigen sollte – das belegen immer wieder Angriffe auch auf Applikationen großer Unternehmen, wie Facebook, Twitter und Co. Dabei können schon veraltete Plug-ins Grundlage für fatale Sicherheitsangriffe  sein.

Das Open Web Application Security Project, ein gemeinnütziger Zusammenschluss von Entwicklern, die u.a. Guidelines und Whitepapers zur Web-Sicherheit herausbringt, veröffentlicht aus diesem Grund alle drei Jahre eine Top-Ten-Liste der „Most Critical Web Security Risks“. Tobias Zander von Sitewards stellte die aktuelle Liste bei der WebTech Conference 2013 vor. Die zehn größten Sicherheitsrisiken im Web ermittelt das OWASP übrigens aufgrund der Häufigkeit an Meldungen darüber.

Die unrühmliche Liste der zehn größten Sicherheitsrisiken im Web 2013 setzt sich wie folgt zusammen:

  1. Injection
  2. Broken Authentication und Session Management
  3. Cross-Site Scripting (XSS)
  4. Insecure Direct Object References
  5. Security Misconfiguration
  6. Sensitive Data Exposure
  7. Missing Function Level Access Control
  8. Cross-Site Request Forgery (CSRF)
  9. Using Known Vulnerable Components
  10. Unvalidated Redirects und Forwards

Wir wollen uns die  Plätze 3 bis 1 einmal detaillierter ansehen.

3.  Cross-Site Scripting (XSS)

XSS ist bereits seit 2004 unter den Top-3 der OWASP-Liste. Darunter kann man sich das Einschleusen von JavaScript-Code vorstellen, was besonders tückisch ist, da JavaScript immer mächtiger wird und demzufolge auch die Angriffswege immer aufwendiger werden.

Man unterscheidet bei XSS drei Arten: DOM-based bedeutet, dass JavaScript Nutzereingaben im DOM verwendet. Non-persistent beschreibt, dass die Server-seitige Implementierung die Nutzereingabe verwendet. Persistent meint, dass die Server-seitige Implementierung Nutzereingabe speichert. Allerdings gibt es inzwischen durchaus verschiedene Möglichkeiten, sich davor zu schützen, vor allem bieten Browser vermehrt integrierte Schutzmaßnahmen: Die Content Security Policy ab Firefox 4+, Chrome 13+ und IE 10+ sorgt dafür, dass der Browser eine Angabe erhält, von welchem Server JavaScript geladen werden darf. Diese Policy befindet sich derzeit noch im W3C Working Draft, könnte dem Thema XSS aber schon bald ein für alle Mal den Garaus machen.

2. Broken Authentication und Session Management

Http ist ein statusloses Protokoll. Es hat sozusagen kein Gedächtnis, das sich die Seitenbesuche eines Benutzers merkt. Wenn man also auf einer Online-Shopping-Website einen Warenkorb füllt, die Seite verlässt und beim Wiederaufruf nach wie vor den gefüllten Warenkorb vorfindet, ist dieser Zustandserhalt das Resultat von Cookies. Diese sind im Grunde aber Session Hacks, da das Session-Management via Cookies kein fester Bestandteil von Http ist: Der Server erkennt den Benutzer anhand der Session-ID im Cookie wieder. Im Grunde bedeutet das, dass jeder, der über die Session-ID verfügt, munter mitlesen kann. Dieser Klau der Session-ID wird als Session Hijacking bezeichnet. Abhilfe schafft hier z.B. der Seitenaufruf über HTTPS. Session Fixation bedeutet im Gegensatz dazu, dass dem Opfer ein fester Cookie untergeschoben wird.

1. Injection

Der Spitzenreiter unter den Web-Sicherheitslücken ist ein klassischer Standardangriff. Injections gibt es in verschiedenen Varianten, die am weitesten verbreitete ist die SQL-Injection: Sicherheitslücken in Zusammenhang mit SQL-Datenbanken entstehen z.B. durch mangelnde Maskierung oder Überprüfung von Metazeichen in Benutzereingaben. Verschafft sich ein Angreifer über die Anwendung Zugriff auf die Datenbank, kann er eigene Datenbankbefehle einzuschleusen, Daten ausspähen oder gar die komplette Kontrolle über den Datenbank-Server übernehmen. Es lassen sich jedoch relativ einfache Vorkehrungen gegen Injections treffen: Wildcards checken, Prepared Statements oder Stores Procedures nutzen. Die wichtigste Methode ist die Verwendung von sicheren APIs, wie stark typisiert parametrisierte Abfragen und Object-Relational-Mapping(ORM)-Bibliotheken, die mehr oder weniger immun gegen Injections sind. Auch wenn solche sicheren Schnittstellen das Problem vorläufig lösen, ist Validierung dennoch empfohlen, um Angriffe weiterhin zu erkennen.

Die am weitesten verbreiteten Sicherheitsrisiken lassen sich mitunter mit einfachen Mitteln beheben oder zumindest deutlich eindämmen. Entwickler sollten die Warnzeichen, die es z.B. im Falle von SQL-Injection durchaus gibt und die wenig missverständlich sind, zur Kenntnis zu nehmen und die nötigen Schritte einleiten. Auf owasp.org findet Ihr dazu allen nötigen Informationen.

Übrigens könntet Ihr euch auch für den Vortrag von Johann-Peter Hartmann unter dem Motto „JavaScript ist toll, um Dinge kaputt zu machen“ interessieren. Dort beschreibt der Mayflower-Experte, wie man mit JavaScript verschiedenste Angriffsvektoren nutzt, um Browser fernzusteuern und Ziele zu belauschen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -