Application Security

Inhaltsverzeichnis

1 Security! Sicher?

2 Application Security
2.1 Definition
2.2 Hindernisse
2.3 Lösungen
2.3.1 Grundsätze
2.3.2 Application Design
2.3.3 Application Testing

3 Application Security Exploits
3.1 Cookie Poisoning
3.1.1 Cookies
3.1.2 Ablauf
3.1.3 Lösungen / Schutz
3.2 Cross-Site Scripting
3.2.1 Ablauf
3.2.2 Lösungen / Schutz
3.3 SQL-Injection
3.3.1 SQL
3.3.2 Ablauf
3.3.3 Lösungen / Schutz

4 Application Security Software
4.1 Varianten
4.2 Beispiel AirLock
4.2.1 Aufbau
4.2.2 Lösungen / Funktionen

5 Fazit / Ausblick

6 Abbildungsverzeichnis

7 Quellenverzeichnis
7.1 Literatur
7.2 Online-Quellen

1 Security! Sicher?

Sicherheit ist und war schon immer ein menschliches Grundbedürfnis. Doch in einer Gesellschaft, die immer stärker abhängig wird von funktionierender Informations- und Kommunikationstechnik, steigt das Bedürfnis nach Sicherheit noch weiter an^[1]. Nicht zuletzt durch die Entwicklung der modernen Wirtschaft hin zu mehr Dienstleistungen, und der monetären Bewertung von Informationen und Know-how. Einem modernen Unternehmen, das all sein Wissen in einem modernen Portal als „Single Point of Access“ seinen Mitarbeitern zur Verfügung stellt, kann ein erheblicher, wenn nicht sogar existenzieller Schaden drohen, sollte es Fremden gelingen an diese Informationen zu gelangen und sie z. B. der Konkurrenz zugänglich zu machen.

Je komplexer und aufwendiger die Anwendungen werden, und je besser diese über Internet etc. erreichbar sein sollen, desto größer wird die Angriffsfläche für Datendiebstahl und -Manipulation.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Steigende Computerkriminalität in Deutschland^[2]

Bereits die meisten Privat-User wissen heute von der Gefahr, die von Viren, Trojanern u. a. im Internet ausgeht. Man schützt sich davor mit Virenscannern, Firewalls, Anti-Spyware-Tools und ähnlichem. Doch viele Firmen bzw. Entwickler von Software kümmern sich kaum um den Schutz der eigentlichen Applikationen oder von dynamischen Websites, und hier hilft ihnen keinerlei Firewall oder Intrusion Detection System^[3].

Schutzmaßnahmen gegen Angriffe auf die eigentliche Applikation kann man unter dem Begriff der „Application Security“ zusammenfassen, womit sich auch diese Seminararbeit beschäftigt. Zunächst sollen allgemeine Richtlinien und Methoden aufgezeigt werden, die zur Erhöhung der Application Security beitragen und diese ausmachen. Danach werden einige der wichtigsten Angriffsarten auf (Internet-) Applikationen, mitsamt der Möglichkeiten diese zu verhindern vorgestellt, und zum Schluss noch Schutzmöglichkeiten durch Software, inklusives eines Beispiels erläutert.

2 Application Security

2.1 Definition

Bei der Application Security geht es um die Sicherheit der eigentlichen Applikationen. Eine Firewall kann keine Ausnutzung von Schwachstellen im Code ausmachen oder verhindern. Generell gibt es kaum externen Schutz von solchen, meist erst im Nachhinein entdeckten Sicherheitslücken. Eine nachträgliche Veränderung des Codes bzw. der gesamten Applikation ist meist mit erheblichem Aufwand und damit Kosten verbunden. Zudem werden viele Schwachstellen erst durch Fremde entdeckt, die dann zuerst die Möglichkeit haben diese auszunutzen, bevor der Geschädigte etwas von der Schwachstelle erfährt.

Die Sicherheit muss in der gesamten Struktur der Applikation beachtet werden, wodurch eine ausreichende Application Security meist nur bei der eigentlichen Entwicklung der Applikation erreicht werden kann.

2.2 Hindernisse

Viele Firmen beachten diesen Aspekt nicht oder zu wenig. Ein Unternehmen, das eine Software entwickelt, denkt meist aus diversen Gründen nicht daran, diese wirklich sicher zu machen^[4]:

- Die Sicherheit ist bei Individualsoftware meist kein richtig angesprochenes oder vertraglich festgelegtes Kriterium. Der Käufer erwartet Sicherheit gewissermaßen als Grundvorrausetzung, während der Entwickler sich nicht darum kümmert, ob die Applikation irgendwann später Sicherheitslücken aufweist, sondern dafür sorgt, dass die Funktionalitäten schnell zur Verfügung stehen.
- Anforderungen an die Sicherheit von Applikationen werden nicht ausreichend formuliert, u.a. auch da sie oftmals schwer an Kriterien festzumachen ist („keinerlei Schwachstellen oder Sicherheitslücken“ als Anforderung wären z.B. utopisch bzw. nicht nachzuweisen). Möglich wäre hier z.B. die Software vor dem Kauf einem Sicherheitstest durch Externe zu unterziehen, und die Kosten der Behebung dem Entwickler zu berechnen.
- Bei Standard Software, die an viele Kunden verkauft wird, könnte weniger auf Application Security geachtet werden, da keine direkte Bindung zu einem Kunden besteht, sich im Nachhinein also niemand über Sicherheitslücken beschweren kann.

Es ist also unbedingt nötig bereits bei der Entwicklung (inkl. Planungs- und Design-Phase) darauf zu achten, wie man die Applikation sicherer gestalten kann.

2.3 Lösungen

Dieses Kapitel soll eine Auswahl an Methoden, Theorien und Ideen aufzeigen, mit denen man Applikationen sicher machen kann.

Der erste Schritt ist die Anerkennung der Sicherheit als wichtiger Aspekt der Entwicklung und nicht als Nebensache. Die Entwickler müssen in allen Phasen ihrer Arbeit die Sicherheit beachten, und die entsprechenden Fachkenntnisse besitzen bzw. sich aneignen, um diese richtig umzusetzen.

Weiterhin können ausgearbeitete Strategien für die allgemeine Implementierung der Sicherheit, als auch für Teilbereiche, wie Konfiguration oder Logging, sehr hilfreich sein. Auch externe Software stellt eine Alternative oder einen Zusatz zu Application Security dar (siehe Kapitel 4).

2.3.1 Grundsätze

Es gibt natürlich noch viele weitere Methoden und Lösungen um ausreichende Sicherheit in Applikationen zu schaffen, von denen hier noch drei wichtige genannt werden sollen:

- Input und Output validieren – Es sollten nur explizit erlaubte Daten ein- und ausgegeben werden dürfen. Z. B. sollte ein Eingabefeld für deutsche Postleitzahlen nur fünfstellige numerische Werte zulassen, und nichts anderes^[5].
- Fail Securely (Closed) – Wenn eine Applikation oder ein Prozess einen Fehler verursacht, dann sollte sie bzw. er sich sofort schließen, um evtl. diesen als Fehler getarnten Angriff, aber auf jeden Fall weitere, zu vermeiden^[6].
- Secure Deployment & Updating – Deployment umfasst die Installation und Verteilung auf Client-Rechnern und Servern. Beim Updating sollte darauf geachtet werden, die aktuellsten Sicherheits-Patches für das System zu verwenden, z. B. mit automatischer Installation und Verifizierung über Software Update Dienste^[7].

2.3.2 Application Design

Möglichkeiten bereits in der Design-Phase eines Entwicklungsprojekts eine Basis für eine sichere Struktur zu schaffen, sind u. a.:

- Threat Modeling – Ein Ansatz, bei dem während der Entwicklung strukturiert auf Sicherheitsrisiken geachtet wird, indem man diese versucht, u. a. aus dem Blickwinkel von Angreifern, zu identifizieren und zu evaluieren, um sie letztendlich zu vermeiden^[8].
- Segmentierung – Die Teilung der Infrastruktur (des Netzwerkes) in mehrere Teile oder Schutzzonen, im Gegensatz zu einer zentral ausgelegten Sicherheitsstruktur (möglicherweise von der Konzernzentrale nach außen hin abnehmend)^[9].
- Prinzip des geringsten Zugriffsrechts – Jeder User erhält nur genau so viele (Zugriffs-) Rechte, wie er wirklich benötigt. Sollte irgendwann ein User zu einem Sicherheitsrisiko werden, kann er durch diese Beschränkung möglichst wenig Schaden anrichten^[10].

2.3.3 Application Testing

Application Testing beschreibt Methoden, die Software auf Sicherheitslücken zu testen, um diese bei Identifizierung beheben zu können. Testen kann man oftmals leider erst richtig, wenn das Projekt bereits fortgeschritten, und die Behebung gefundener Fehler kostenintensiver ist, als zu Beginn der Entwicklung. Einige Möglichkeiten um Applikationen auf potenzielle Fehler zu testen sind:

- Audit – Die Bewertung eines Standards, einer Richtlinie o. ä. (z. B. Sicherheitsrichtlinie eines Unternehmens).
- (Vulnerability-) Assessment – Das Finden, Identifizieren und Evaluieren von Schwachstellen, z. B. mit entsprechenden Scannern.
- Penetration Test („Pentesting“) – Der praktische und aktive Versuch Sicherheitsmaßnahmen zu durchbrechen bzw. Applikationen anzugreifen, um ihre Verwundbarkeit aufzuzeigen und zu bewerten^[11].
- Security Tests in Unit Tests – Bei Unit Tests (auch „Komponententests“) durchlaufen die Module (z. B. Klassen) regelmäßig nach jeder Änderung alle Testfälle. Hierbei können bereits erste Security Tests mit durchgeführt werden^[12].

3 Application Security Exploits

Attacken auf Applikationen nennt man „Application Security Exploits“, da sie Schwachstellen in der Software bzw. im Code ausnutzen um Schaden anzurichten bzw. um an Informationen zu gelangen. Im Folgenden sollen nun einige der häufigsten Exploits näher beschrieben werden.

3.1 Cookie Poisoning

Beim Cookie Poisoning werden eigene oder fremde Cookies manipuliert bzw. Informationen (oder auch ganze Cookies) gestohlen, um an Informationen anderer User zu gelangen, oder Web-Applikationen bzw. deren Benutzung zu kompromittieren.

3.1.1 Cookies

Ein Cookie (genauer: HTTP- bzw. Browser-Cookie) beinhaltet Informationen, die ein Webserver an den Browser des Besuchers einer Site schickt, welcher ihn u. U. auf dem Rechner des Clients speichert. Bei Bedarf kann der Webserver den gesetzten Cookie wieder anfordern, woraufhin der Browser ihn zurückschickt. Ein Cookie wird als Textdatei gespeichert und kann maximal 4 KB an Daten enthalten (nur Text)^[13].

3.1.2 Ablauf

Cookies sind auf dem Client-Rechner nur als Textdateien gespeichert, die jeder ganz einfach verändern kann. In HTTP-Cookies werden z. B. User IDs, Passwörter, Nummern von Benutzerkonten oder auch Parameter (wie „admin=true“) gespeichert. Eine weitere häufige Nutzung ist die Speicherung von Daten des Kunden eines Online Shops, wie die genauen Artikel im Warenkorb eines Kunden, mitsamt Preisen^[14].

Je nachdem welche Daten im Cookie gespeichert sind, können diese zu verschiedenen Zwecken genutzt werden:

- eShoplifting – Veränderung von Bestellungen und Preisen, wenn diese im Cookie eines Webshops gespeichert sind.
- eFraud – Rechnungen von Webshops auf andere User umschreiben, wenn die entsprechenden User-Daten im Cookie gespeichert sind^[15].
- Session Hijacking und Identity Theft – Wenn in Cookies Daten über den Sitzungsstatus eines Users gespeichert sind, so ist es möglich diese zu manipulieren oder einen Cookie zu stehlen, um damit die Sitzungen anderer User zu übernehmen. Dies geht solange eine Sitzung geöffnet ist (gewöhnlich bis zu 20 Minuten). Über diesen gefälschten Sitzungsstatus können dann ebenfalls Angriffe durchgeführt werden^[16].

3.1.3 Lösungen / Schutz

Es gibt verschiedene Möglichkeiten sich vor den genannten Angriffen über Cookies zu schützen bzw. die eigenen Cookies sicherer zu machen:

- Verschlüsseln und / oder Signieren der Cookies.
- Einsatz von Application Firewalls (siehe Kapitel 4)^[17].
- Verzicht auf die Speicherung von sicherheitsrelevanten oder generell sensitiven Daten in Cookies. Eine Alternative bietet z. B. eine einzige Session-ID, zu welcher auf der Server-Datenbank dann die entsprechenden, wichtigen Informationen gespeichert sind. Dies kann einhergehen mit einer Plausibilitätsprüfung der Daten in einem Cookie (passen Session-ID und User zusammen?)^[18].

3.2 Cross-Site Scripting

Beim Cross-Site Scripting (auch „XSS“) werden Sicherheitslücken in Web-Applikationen und Browsern ausgenutzt um dort Code zu platzieren, welcher dann bei Usern Einstellungen ändern, Applikationen starten oder dem Angreifer Zugang zu Informationen verschaffen kann^[19].

[...]

^[1] Vgl. Helmbrecht 2005

^[2] Bundesministerium für Wirtschaft und Arbeit (o. V.): e-f@cts 08/2005, S. 2

^[3] Vgl. Leyeza, Kirchner 2003

^[4] Vgl. Leyeza, Kirchner 2003

^[5] Vgl. OWASP 2002, S. 10 f.

^[6] Vgl. OWASP 2002, S. 10 f.

^[7] Vgl. Microsoft – Security Vision and Framework 2004

^[8] Vgl. Microsoft Security Developer Center (o. V.): Threat Modeling

^[9] Vgl. Rothkugel 2005, S. 1 f.

^[10] Vgl. OWASP 2002, S. 10 f.

^[11] Vgl. Rothkugel 2004, S. 10 f.

^[12] Vgl. Wikipedia (o. V.): Unit-Test 2005

^[13] Vgl. Wikipedia (o. V.): HTTP-Cookie 2005

^[14] Vgl. Imperva Inc. (o. V.): Application Defense Center – Cookie Poisoning Attack 2005

^[15] Vgl. Leyeza, Kirchner 2003

^[16] Vgl. Esposito, Dino: Microsoft – Abwehr von Webangriffen mit ASP.NET: Session Hijacking 2005

^[17] Vgl. Leyeza, Kirchner 2003

^[18] Vgl. OWASP 2002, S. 10 f.

^[19] Vgl. heise security (o. V.): Papers - Cross-Site-Scripting FAQ 2003