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 sicheren Webanwendungen auf Grundlage eines Ebenenmodells besprochen, sie basiert auf dem Maßnahmenkatalog, der im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) erstellt wurde.
Im letzten Teil dieser Ausarbeitung werden die Kennzeichen einer sicheren Netzwerk-Infrastruktur u.a. im Unternehmen behandelt.
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
[...]
- Citar trabajo
- Pavel Ermolin (Autor), 2011, Webserver Security, Múnich, GRIN Verlag, https://www.grin.com/document/196919
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.