Webserver Security

Abstract

In der vorliegenden Arbeit werden zu Beginn die zehn größten Risiken für Webanwendungen anhand von „ OWASP Top 10 - 2010 “ vorgestellt. Im nächsten Schritt wird die Realisierung von siche- ren Webanwendungen auf Grundlage eines Ebenenmodells besprochen, sie basiert auf dem Maßnahmenkatalog, der im Auftrag des Bundesamtes für Sicher- heit in der Informationstechnik (BSI) erstellt wurde.

Im letzten Teil dieser Ausarbeitung wer- den die Kennzeichen einer sicheren Netzwerk-Infrastruktur u.a. im Unter- nehmen behandelt.

1 Einleitung

Laut dem Bericht „ Die Lage der IT- Sicherheit in Deutschland 2011 “, der vor kurzem von BSI veröffentlicht wurde, ist die Zahl der „professionellen IT- Angriffen auf Firmen, Behörden und auch auf Privatpersonen“ stark zuge- nommen[1]. Mit dem Problem der Ab- wehr solcher Cyber-Attacken beschäftigt sich auch die Politik, so wurde im Juni 2011 das nationale Cyber- Abwehrzentrum vom Bundesinnenmi- nister offiziell eröffnet.

Die Cyber-Kriminalität bedroht aber mittlerweile nicht nur Privatpersonen, sondern richtet sich verstärkt auf Unter- nehmen und große Industrieanlagen, z.B. wurden vom Aurora-Angriff im Jahre 2009, bei dem eine unbekannte Sicher- heitslücke im Internet Explorer ausge- nutzt wurde, hunderte von Unternehmen betroffen[2]. Durch den qualitativ sehr hochwertigen Stuxnet-Wurm wurde 2010 die iranische Urananreicherungsan- lage lahmgelegt.

Diese Arbeit beschäftigt sich vor allem mit der Sicherheit von Webanwendun- gen und einer sicheren IT-Infrastruktur im Unternehmen.

2 Top-10-Risiken für Weban- wendungen

Auf Webanwendungen setzen heutzuta- ge immer mehr Firmen, um den potenzi- ellen Kunden ihre Leistungen anzubieten oder einfach zur Präsentation des Unter- nehmens. Auch Behörden verwenden Websites, um bestimmte Vorgänge zu vereinfachen und zu beschleunigen. Doch solche offenen Systeme bedeuten auch Sicherheitsrisiken, da die Angreifer die Schwachstellen in den Web- Anwendungen nutzen können, um den Zugang zu vertrauenswürdigen Daten oder zum Webserver zu bekommen.

Die unternehmensunabhängige Organi- sation OWASP (Open Web Application Security Project) veröffentlichte im Jah- re 2010 einen Bericht über die zehn ak- tuell größten Risiken für Webanwen- dungen[3], die in diesem Kapitel näher betrachtet werden.

2.1 Platz 1: Injection

Um Injection (injection flaw) handelt es sich, wenn von einem Angreifer manipu- lierte Benutzereingaben ungeprüft bzw. ungefiltert an ein Hintergrundsystem weitergegeben werden[4]. Ein Angreifer kann dadurch einen unautorisierten Zu- griff auf Inhalte von Hintergrundsyste- men bekommen [4]. Es gibt mehrere Arten der Injection-Attaken: SQL- Injection (möglicher Zugriff auf Daten- bank), LDAP-Injection (Zugriff auf LDAP-Verzeichnis des Servers), OS Command Injection (Einschleusen von Shell-Befehlen) und XPATH-Injection (unerlaubter Zugriff auf XML- Dateien)[4].

Am häufigsten tritt SQL-Injection auf. Durch SQL-Befehle kann ein Angreifer Daten des Systems verändern, löschen oder neue anlegen[4]. Dabei wird SQL- Code z.B. innerhalb eines Parameters an die Webapplikation übermittelt und aus- geführt. Ein einfaches Beispiel von SQL-Injection:

SQL-Anfrage innerhalb der Anwen- dung[3]:

Abbildung in dieser Leseprobe nicht enthalten

Ein Angreifer verändert die URL und schickt folgende Anweisung an den Ser- ver[3]:

Abbildung in dieser Leseprobe nicht enthalten

Damit bekommt er als Ergebnis alle Ein- träge der Tabelle accounts.

Einen Schutz gegen SQL-Injections bie- ten die Stored Procedures bzw. Prepared SQL Statements, da sie im Normalfall keine SQL-Befehle als Parameter akzep- tieren[4]. Weiterhin sollte der Benutzer über eingeschränkte Rechte verfügen, so dass er z.B. nur SELECT-Anfragen stel- len darf.

2.2 Platz 2: Cross-Site Scripting

Cross-Site Scripting (XSS) - Angriffe sind den Injection-Angriffen recht ähn- lich, nur wird hier nicht direkt die Da- tenbank angegriffen, sondern es wird typischerweise versucht die benutzer- spezifische Daten an einen Angreifer zu übermitteln, indem manipulierte Parame- ter an serverseitiges Script übergeben werden oder durch das Stehlen von Coo- kies[4].

Schauen wir ein Beispiel aus[3] an:

Codeausschnitt (Webanwendung):

Abbildung in dieser Leseprobe nicht enthalten

Der Angreifer verändert den Parameter CC zu :

Abbildung in dieser Leseprobe nicht enthalten

und bekommt das Cookie des Opfers und damit evtl. die Session-ID, UserId etc., die er beim Angriff verwenden kann.

Um die Webanwendung gegen Cross- Site Scripting zu schützen, müssen alle Benutzereingaben vor der Ausführung geprüft werden. Um beispielsweise die Metazeichen zu maskieren, werden spe- zielle Sprachabhängige Funktionen ver- wendet

(PHP: htmlspecialchars()).

2.3 Platz 3: Broken Authentication and Session Management

Manche Programmierer verwenden kei- ne fertigen Frameworks, sondern entwi- ckeln sie selber, was zu Sicherheitslü- cken führen kann. Insbesondere bei der Programmierung von Authentifizie- rungsmechanismen und Session- Management. Dabei geht es vor allem um Behandlung und korrekte Erzeugung von Session-Id´s.

Wenn ein eingeloggter Benutzer die fol- gende URL[3]:

Abbildung in dieser Leseprobe nicht enthalten

anderen Personen zugänglich macht, weiß er nicht, dass bei der Webanwen- dung mit dieser Schwachstelle seine Session verwendet und alle Privatdaten eingesehen werden können.

Web-Programmierer sollen sich bei der Implementierung an den aktuellen An- forderungen orientieren und vor dem Release das System gründlich testen.

2.4 Platz 4: Insecure Direct Object References

Wenn bei der Implementierung soge- nannte Objektreferenzen verwendet werden, die auf andere Systemobjekte verweisen, können diese u.U. manipu- liert werden, falls keine Rechteüberprü- fung stattfindet[3]. Um dies zu errei- chen, verändert ein Angreifer die zuge- höre URL, wie in diesem Beispiel aus [3]:

Code aus der Webanwendung, Parame- ter acct wird nicht überprüft:

Abbildung in dieser Leseprobe nicht enthalten

[...]