Inhaltsverzeichnis

1  Security Sicher  3

2  Application Security  5

2.1  Definition  5

2.2  Hindernisse  5

2.3  Lösungen  6

2.3.2  Application Design  7

3  Application Security Exploits  9

3.1  Cookie Poisoning  9

3.1.3  Lösungen Schutz  10

3.2  Cross-Site Scripting  11

3.3  SQL-Injection  13

3.3.3  Lösungen Schutz  15

4  Application Security Software  16

4.1  Varianten  16

4.2  Beispiel AirLock  16

5  Fazit Ausblick  19

6  Abbildungsverzeichnis  22

7  Quellenverzeichnis  23

  Seite  i

7.1 Literatur ........................................................................................................... 23

7.2 Online-Quellen................................................................................................. 23

Seite ii

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 ¹ . 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 1: Steigende Computerkriminalität in Deutschland 2

¹ Vgl. Helmbrecht 2005

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

3

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 ³ .

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.

³ Vgl. Leyeza, Kirchner 2003

4

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 ⁴ :

• 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

⁴ Vgl. Leyeza, Kirchner 2003

5

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 ⁵ .

⁵ Vgl. OWASP 2002, S. 10 f.

6