Sicheres Programmieren

Sicheres
Programmieren
Einführung in die sichere
Anwendungsentwicklung
SAP Pocketseminar
Fü
De
rE
rs
nt
ch
w
ick
Pr zur nell
le
og s e
r:
ra ich Üb
m er er
m en bl
ie
ick
ru
ng
Herausgegeben für die Sicherheitsinitiative
„Deutschland sicher im Netz“
Sicheres Programmieren · Einführung in die sichere
Anwendungsentwicklung
SAP Pocketseminar
Eine Schriftenreihe der SAP AG
Sicheres
Programmieren
Einführung in die sichere
Anwendungsentwicklung
Bei der Zusammenstellung der Texte, Verweise und Abbildungen wurde mit größter Sorgfalt vorgegangen;
trotzdem ist ein vollständiger Fehlerausschluß nicht möglich. Die nachfolgende Dokumentation erfolgt
daher ohne Gewähr für Richtigkeit und Vollständigkeit der gemachten Angaben, für deren Verifizierung
allein der Anwender die Verantwortung trägt.
SAP übernimmt für aus der Verwendung dieser Dokumentation entstehende Schäden, gleich aus welchem
Rechtsgrund, eine Haftung nur im Falle vorsätzlichen oder grob fahrlässigen Handelns; im übrigen ist die
Haftung von SAP ausgeschlossen. SAP übernimmt keine Verantwortung für die Inhalte von Seiten oder
Veröffentlichungen Dritter, auf welche wir durch Links verweisen.
Copyright by SAP AG 2005
Inhalt
1
2
2.1
2.2
2.3
2.4
2.5
3
3.1
3.2
3.2.1
3.2.2
3.2.3
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ziel dieses Leitfadens . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicherheit in der Informationstechnologie . . . . . . . . . .
Angreifer wachsen mit ihren Herausforderungen . . . . .
Softwareentwickler mit Sicherheits-Knowhow . . . . . . .
Anwendungssicherheit als Prozess . . . . . . . . . . . . . . . .
Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . .
Datenklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicherheitsgrad „normal” . . . . . . . . . . . . . . . . . . . . . . .
Sicherheitsgrad „hoch" . . . . . . . . . . . . . . . . . . . . . . . .
Sicherheitsgrad „sehr hoch" . . . . . . . . . . . . . . . . . . . . .
Sicheres Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grundlegende Anforderungen an das Design . . . . . . . .
Sichere Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eingabeprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parametermanipulation . . . . . . . . . . . . . . . . . . . . . . . . .
Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Berechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anwendungskonfiguration . . . . . . . . . . . . . . . . . . . . . .
Vertrauliche Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einsatz von Kryptographie . . . . . . . . . . . . . . . . . . . . . .
Session-Management . . . . . . . . . . . . . . . . . . . . . . . . . .
Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prinzip der minimalen Rechtevergabe . . . . . . . . . . . . .
Revision und Logging . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
7
9
9
9
10
11
11
14
14
15
15
16
16
18
18
20
22
24
25
27
30
32
33
35
36
37
38
40
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
5.3
5.4
5.5
5.6
5.7
5.8
6
6.1
6.2
6.3
7
7.1
7.2
7.3
8
9
10
11
12
Sichere Kodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
„Bewährte” Angriffsvarianten . . . . . . . . . . . . . . . . . . .
Manipulation von Parametern . . . . . . . . . . . . . . . . . . .
Cross-Site Scripting (CSS/XSS) . . . . . . . . . . . . . . . . . . . .
SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eingabeprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reguläre Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . .
URI/URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eingaben über Gerätedateien . . . . . . . . . . . . . . . . . . . .
Einsatz von Kryptographie . . . . . . . . . . . . . . . . . . . . . .
Session-Management . . . . . . . . . . . . . . . . . . . . . . . . . .
Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sicheres Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
White Box Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Black Box Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zertifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auslieferung und Wartung . . . . . . . . . . . . . . . . . . . . . .
Sichere Standardkonfiguration . . . . . . . . . . . . . . . . . . .
Wartungsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Patch-Management und Bug-Fixing . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abkürzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . .
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
41
41
41
41
42
43
43
46
46
47
48
50
52
54
54
56
56
57
57
58
58
60
61
63
64
65
1
Vorwort
IT-Sicherheit hat sich lange Zeit vorwiegend mit InfrastrukturThemen wie Netzwerkarchitektur und Firewalls, verschlüsselten
Datenleitungen und dem Schutz vor Viren und Würmern beschäftigt. Der Hauptgrund dafür ist, dass die Angreifer sich fast ausschließlich in diesen Techniken auskannten. Doch zunehmend
rücken die Anwendungen selbst in das Interesse der Hacker, und
zusätzliche Schutzmechanismen sind entweder noch nicht ausgereift – wenngleich auch schon hilfreich, wie etwa Application
Level Firewalls – oder einfach nicht in der Lage, alle Angriffe abzuwehren. Dementsprechend kommt der Sicherheit der Applikation
immer mehr Bedeutung zu. Dabei stehen nicht die vorhandenen
Sicherheitsfunktionen, sondern vielmehr die Qualität der Software
im Hinblick auf Robustheit gegen Angriffe, meist vereinfacht
„Sicheres Programmieren“ genannt, im Mittelpunkt des Interesses.
Dieser Leitfaden soll eine erste Hilfestellung zum Thema sichere
Entwicklung für Software-Bauer jeder Art, etwa Architekten, Programmierer oder Tester, darstellen. Er ist anlässlich der Initiative
„Deutschland sicher im Netz“ im Jahr 2005 entstanden und hat
den Anspruch, die internen Richtlinien von Microsoft und SAP auf
wenigen Seiten verständlich und in allgemeiner Form wiederzugeben.
7
2
Einleitung
2.1
Ziel dieses Leitfadens
Ziel dieses Leitfadens ist es, Softwareentwicklern eine Informationssammlung für das Programmieren sicherer Anwendungen an
die Hand zu geben. Er soll Entwickler während der Design- und
Implementierungsphase unterstützen, gleichzeitig aber auch ihren
Auftraggebern als Kontrollwerkzeug dienen: Anhand der hier
beschriebenen Prinzipien lässt sich überprüfen, ob das Produkt
allen aktuellen Sicherheitsanforderungen genügt.
Entwickler sollten
I festlegen, welche der hier beschriebenen Sicherheitsaspekte
für ihre Anwendung relevant sind. So ist zum Beispiel eine
Web-basierte Anwendung, der keine Datenbank zugrunde liegt,
nicht anfällig für SQL Injections.
I ihr Vorgehen mit ihrem Auftraggeber besprechen und gemeinsam ein Sicherheitskonzept für die zu erstellende Software
erarbeiten.
Die hier beschriebenen Regeln gelten für jede Art von Anwendung.
Web-Anwendungen bieten jedoch aufgrund ihrer Architektur und
Exponiertheit im Internet eine breitere Angriffsfläche als andere
Software. Viele Beispiele und Beschreibungen sind daher speziell
auf Web-basierte Applikationen zugeschnitten.
2.2
Sicherheit in der Informationstechnologie
Unter Sicherheit versteht man in der Informationstechnologie die
Gewährleistung folgender Aspekte, die im Englischen als „CIA“Prinzip (Confidentiality, Integrity, Availability), im Deutschen als
„VIV-Dreieck“ bezeichnet werden:
9
Vertraulichkeit: Das System stellt seine Daten ausschließlich einer
zuvor definierten Gruppe von Benutzern zur Verfügung und
gewährleistet so ihre Vertraulichkeit. Nur Personen mit entsprechender Berechtigung dürfen in der Lage sein, kritische Daten
einzusehen. Die Vertraulichkeit von Daten hat rechtliche und wirtschaftliche Implikationen: In den meisten Ländern wird der Schutz
von Personendaten durch die nationale Gesetzgebung geregelt.
Wenn jedoch beispielsweise vertrauliche Finanzinformationen oder
Forschungsergebnisse eines Unternehmens der Konkurrenz in die
Hände fallen, kann dies auch weit reichende wirtschaftliche Konsequenzen nach sich ziehen.
Integrität: Das System kann die unberechtigte Manipulation von
Daten erkennen und/oder verhindern.
Verfügbarkeit: Das zentrale Sicherheitsziel jedes IT-Systems ist die
Verfügbarkeit. Anwendungen müssen funktionieren, auch wenn ein
unerwarteter Vorfall Probleme bereitet. Da Geschäftsprozesse in
verstärktem Maß computergesteuert ablaufen, werden Systemausfallzeiten immer teurer. Die Verfügbarkeit eines Systems erhöht
sich, wenn eine Störung des Systembetriebs durch unberechtigten
Datenzugriff bzw. die böswillige Manipulation von Daten weitestgehend verhindert werden kann.
2.3
Angreifer wachsen mit ihren
Herausforderungen
Noch vor wenigen Jahren richteten sich die meisten Hacker-Angriffe
gegen Systeminfrastrukturen. Denial-of-Service-Angriffe, die darauf
abzielen, Server von der Bearbeitung eingehender Anfragen abzuhalten, gehörten zu den am häufigsten eingesetzten Taktiken.
Heutzutage haben Hacker auch andere Komponenten im Visier. Mit
Methoden wie Code Injections oder Cross-Site Scripting zielen sie
verstärkt auf die Software und die dahinter liegenden Daten ab.
10
Bisher gebräuchliche Infrastruktur-Sicherheitsmechanismen wie
Firewalls, Virenscanner und Intrusion-Detection-Systeme sind nach
wie vor wichtig, reichen aber längst nicht mehr aus, um alle Gefahren abzuwenden. Sie sind machtlos bei Angriffen auf die WebAnwendungen selbst. Hier sind neue Strategien gefragt, die in alle
Phasen des Software-Entwicklungsprozesses – Analyse, Design,
Programmierung, Test, Auslieferung und Wartung – hineinreichen.
2.4
Softwareentwickler mit Sicherheits-Knowhow
Vor diesem Hintergrund sehen sich Softwareentwickler mit neuen
Herausforderungen konfrontiert. Mit „Sicheres Programmieren“
möchten wir Ihnen eine Anleitung zur sicheren Softwareerstellung
während des gesamten Entwicklungsprozesses, angefangen bei der
Analyse bis hin zu Tests und Integration, an die Hand geben.
Web-Applikationen sind am stärksten gefährdet; jeder Softwareentwickler sollte die wichtigsten Gefahrenfaktoren solcher Anwendungen kennen. Die Ziele der Produktentwicklung, Funktion und
Qualität, müssen durch das ebenso wichtige Ziel Sicherheit ergänzt
werden.
Der Erfolg eines Hackers liegt meist nicht nur an ausgetüftelten
Angriffsmethoden, sondern basiert zu großen Teilen auf dem
geschickten Ausnutzen von Programmierschwachstellen. Ein
geschärftes Sicherheitsbewusstsein bei der Softwareentwicklung ist
daher meist effektiver als teure Technologie zum Schutz gegen
Hacker.
2.5
Anwendungssicherheit als Prozess
Anwendungssicherheit umfasst den gesamten Lebenszyklus einer
Software. Neben den bereits erwähnten Phasen der Softwareentwicklung spielen auch die Wartung, Änderungsanträge, Rechteverwaltung, Backup und die Systemwiederherstellung im Versagensfall eine wichtige Rolle.
11
Hacker lernen täglich dazu. Sie verfeinern ihre Angriffsmethoden und
suchen neue, lohnenswerte Ziele. Sicherheitsverfahren müssen daher
ebenfalls ständig aktualisiert und weiterentwickelt werden – nur so
können Sie das Rennen gegen die Angreifer gewinnen.
Anwendungssicherheit ergibt sich aus einem Zusammenspiel
verschiedener Faktoren:
1. Bei allen am Projekt beteiligten Personen muss ein Bewusstsein
für die Risiken der Anwendung geschaffen werden.
2. Sicherheit muss in allen Phasen der Softwareentwicklung und
-wartung berücksichtigt werden.
3. Sicherheit muss als unverzichtbares Qualitätsmerkmal einer Software angesehen werden.
4. Der Sicherheitsprozess sollte regelmäßig auf Aktualität und Funktion überprüft werden.
5. Sicherheitsrelevante Vorfälle und Angriffe sollten als Chance zur
Verbesserung des Sicherheitsprozesses begriffen werden.
Um eine sichere Anwendung zu entwickeln, muss das Thema
Sicherheit in allen Abschnitten des Projekts berücksichtigt werden.
Scheuen Sie sich nicht, einen Experten zu Rate zu ziehen. Die
Sicherheit der gesamten Anwendung ist gefährdet, wenn in nur einer
Phase Sicherheitslücken entstehen.
Definieren Sie Sicherheit als Teil der funktionalen und technischen Anforderungen Ihrer Anwendung. Legen Sie zuerst die Anforderungen
fest, und integrieren Sie die Sicherheitsaspekte bereits in die Analyseund Design-Phase. Die meisten konzeptionellen Probleme können zu
diesem Zeitpunkt noch verhindert werden; eine spätere Behebung von
Sicherheitslücken kann im Gegensatz dazu sehr kostspielig werden.
Behalten Sie Ihre Sicherheitsmechanismen im Auge, wenn Ihre
Software produktiv genutzt wird. So können Sie rasch auf neue
Gefahren und Angriffsmethoden reagieren.
12
SicherheitsReview des
Designs
Testfälle
festlegen
ThreadAnalyse
Analyse
Design
Kodierung
Sicherheitsschulungen
für Teammitglieder
Sicherheits
richtlinie
Technische
Revision
Kontinuierliche
Verbesserung
Testen
Auslieferung
und Wartung
Sicherheitskonzept
Hosting-Konzept
Code Review
Sichere Entwicklungsverfahren
und Best Practices
Richtlinien für den Produktivbetrieb
Signieren von Code
Entfernen von Debugging-Informationen
Integration bei Hosting-Anbieter
Abbildung 1: Sicherheit bei der Softwareentwicklung
I
I
I
I
I
Folgeprojekte
Sicherheitsbewusstsein
schaffen
Analyse
– Definieren Sie die Sicherheitsziele ihres Produkts
Design
– Sichere Anwendungsarchitektur
– Design Review
Kodierung
– Sicheres Kodieren
– Code Review
Testphase
– Angriffssimulationen
Auslieferung und Wartung
– Sichere Standardkonfiguration
– Wartungsplan
– Zeiträume für das Patch-Management
– Kriterien für die Fehlerbehebung (Bug-Fixing), besonders bei
sicherheitsrelevanten Fehlern
Jede Entwicklungsmethode, wie z. B. das Wasserfallmodell oder
„Extreme Programming”, umfasst Aufgaben, die auf diese Phasen
abgebildet werden können.
13
3
Sicherheitsanalyse
Wie in anderen kritischen betriebswirtschaftlichen Vorgängen,
spielen auch bei Sicherheitsprozessen Risikoanalyse und Risikomanagement eine wichtige Rolle. Unter Risikoanalyse versteht man
das Identifizieren der wichtigsten Informationswerte eines Unternehmens sowie die Untersuchung ihrer Verwendung und Funktion.
3.1
Sicherheitsanforderungen
Wenn Sie sichere Software entwickeln wollen, müssen Sie zunächst
definieren, WAS sie schützen möchten, vor WEM Sie es schützen
müssen und WIE dieser Schutz aussehen soll.
Die Zielgruppe und die sich daraus ergebenden Sicherheitsanforderungen müssen bereits zu Beginn des Prozesses festgelegt
werden. Beim Sammeln der Entwicklungsanforderungen können
sicherheitsbezogene Fragen während der Gespräche mit dem
Auftraggeber helfen, die Benutzerrollen, Rechte und Anforderungen
im Detail zu verstehen.
Definieren Sie die Sicherheitsziele für Ihr Produkt:
I Wer ist die Zielgruppe des Produkts?
I Welche Bedeutung hat Sicherheit für diese Zielgruppe?
I Können mehrere Benutzergruppen unterschieden werden?
Müssen alle Benutzer Zugriff auf alle Daten haben? Sollten alle
Benutzer die Berechtigung haben, alle Funktionen der Anwendung auszuführen?
I Was muss geschützt werden?
I Wer wird die Anwendung verwalten? Wer wird dafür verantwortlich sein und wer die Zugriffsrechte vergeben?
I Was würde passieren, wenn in der Anwendung genutzte Daten
in falsche Hände gelangen?
I Wie lang darf die Ausfallzeit der Anwendung maximal sein?
14
Anwendungsszenarien werden üblicherweise in Zusammenarbeit
mit Experten für den Funktionsbereich der Anwendung erstellt, um
Anforderungen zu sammeln. Sicherheit sollte als Geschäftsprozess
betrachtet und entsprechend in die Modellierung einbezogen werden. Jedes Szenario sollte Informationen darüber enthalten, wie der
Prozess Sicherheit gewährleistet.
Bestimmte Regeln können jedoch nicht als Prozess abgebildet
werden, z. B. die Passwortrichtlinie. Solche Themen sollten bei der
Sammlung der Anforderungen nicht außer Acht gelassen werden;
sie können separat oder als eigenes Szenario dokumentiert werden.
Auch bei der Auswahl von Entwicklungswerkzeugen, Bibliotheken
oder Entwicklungsumgebungen sollten Sie Sicherheitsaspekte in
Ihre Auswahlkriterien einfließen lassen.
3.2
Datenklassifizierung
Entsprechend der jeweiligen Sicherheitsanforderungen können
Daten unterschiedlich klassifiziert werden. In diesem Kapitel finden
Sie Vorschläge, die Sie beim Festlegen des erforderlichen Sicherheitsgrads unterstützen sollen. Die zentrale Fragestellung ist: Was
sind die Konsequenzen, wenn Daten manipuliert werden oder in
falsche Hände gelangen?
3.2.1 Sicherheitsgrad „normal”
I
I
I
Verstöße gegen Gesetze, Verträge oder andere Regelwerke würden keine schwerwiegende Konsequenzen und lediglich geringe Strafen nach sich ziehen.
Ein Datenmissbrauch hätte minimale soziale bzw. finanzielle
Auswirkungen auf die betroffenen Personen.
Es kann praktisch ausgeschlossen werden, dass Menschen verletzt werden.
15
I
I
I
Die Auswirkungen eines sicherheitsrelevanten Vorfalls auf Ihre
Arbeit werden von den betroffenen Personen als gering eingeschätzt.
Bei einem Sicherheitsproblem ist nur eine geringfügige rufschädigende Wirkung für das Unternehmen zu erwarten.
Die finanziellen Verluste für das Unternehmen im Fall eines
Sicherheitsverstoßes wären gering.
3.2.2 Sicherheitsgrad „hoch"
I
I
I
I
I
I
Verstöße gegen Gesetze, Verträge oder andere Regelwerke würden schwerwiegende Konsequenzen und hohe Strafen nach
sich ziehen.
Ein Datenmissbrauch hätte schwerwiegende Folgen für den
Schutz von Personendaten.
Es kann nicht ausgeschlossen werden, dass Menschen verletzt
werden.
Die Auswirkungen eines sicherheitsrelevanten Vorfalls auf Ihre
Arbeit werden von einigen betroffenen Personen als unzumutbar eingeschätzt.
Bei einem Sicherheitsproblem ist eine rufschädigende Wirkung
für das Unternehmen zu erwarten.
Die finanziellen Verluste für das Unternehmen im Fall eines
Sicherheitsverstoßes wären hoch, aber nicht existenzbedrohend.
3.2.3 Sicherheitsgrad „sehr hoch"
I
I
I
Verstöße gegen Gesetze, Verträge oder andere Regelwerke würden existenzbedrohende Konsequenzen nach sich ziehen.
Datenmissbrauch hätte extrem schwerwiegende Folgen für den
Schutz von Personendaten.
Ein Sicherheitsvorfall würde den sozialen oder finanziellen Ruin
für die betroffenen Personen bedeuten.
16
I
I
I
I
Es besteht die Gefahr schwerer Verletzungen bzw. lebensbedrohlicher Situationen.
Die Auswirkungen eines sicherheitsrelevanten Vorfalls auf Ihre
Arbeit werden von allen betroffenen Personen als unzumutbar
eingeschätzt.
Bei einem Sicherheitsproblem ist eine gravierende, möglicherweise existenzbedrohende Rufschädigung für das Unternehmen
zu erwarten.
Die finanziellen Verluste für das Unternehmen im Fall eines
Sicherheitsverstoßes wären existenzbedrohend.
Die höchste Klassifizierung, die Sie für einen Teilbereich Ihres Projekts wählen, bestimmt den Schutzbedarf der gesamten Anwendung. Dementsprechend sind auch die Schutzmechanismen auszuwählen.
17
4
Sicheres Design
4.1
Grundlegende Anforderungen an das Design
Die folgenden Grundregeln sollten Sie unabhängig von Implementierungstechnologie und Anwendungsszenario befolgen.
Sorgen Sie für Sicherheit im Versagensfall
Wenn Ihre Anwendung abstürzt, dürfen keine vertraulichen Daten
preisgegeben werden. Verfassen Sie eine aussagekräftige, aber allgemein formulierte Fehlermeldung. Sie darf keine internen Systeminformationen enthalten, die einem Angreifer eventuelle Schwachstellen in Ihrer Anwendung aufzeigen würden.
Vertrauen Sie nicht auf „Security by Obscurity“
Der Versuch, durch Vertuschen von Schwachstellen die Sicherheit
Ihrer Anwendung zu verbessern, kann langfristig nicht funktionieren – und auch die kurzfristige Wirkung ist keinesfalls garantiert.
In der Vergangenheit wurden viele, solcher vermeintlich geschützten
Systeme erfolgreich angegriffen.
Handeln Sie nach dem Prinzip der minimalen Rechtevergabe
Verfahren Sie nach dem Prinzip der minimalen Rechtevergabe: Verwenden Sie Benutzerkonten mit den geringstmöglichen Privilegien
und Zugriffsrechten.
Bauen Sie mehrere Verteidigungsmechanismen ein
Verwenden Sie mehr als einen Sicherheitsmechanismus. Bedenken
Sie, dass eines Ihrer Verfahren geknackt werden könnte.
18
Vertrauen Sie keiner Benutzereingabe
Seien Sie misstrauisch. Gehen Sie davon aus, dass jede Dateneingabe böswillig ist bis das Gegenteil bewiesen ist. Implementieren
Sie eine Validierung der Eingaben, sobald ein Übergang zwischen
Vertrauensbereichen Ihrer Anwendung vorliegt (beispielsweise zwischen Client- und Serverseite).
Prüfen Sie beim ersten Zugang
Führen Sie bei der ersten Zugangsmöglichkeit zur Anwendung
Authentisierung und Berechtigungsprüfung durch.
Stärken Sie das schwächste Glied
Sie müssen wissen, welches das schwächste Glied in Ihrer Kette ist
und wie Sie es stärken können. Arbeiten Sie sich Schritt für Schritt
vor, indem Sie nach dem jeweils neuen schwächsten Glied suchen.
Betreiben Sie Schadensbegrenzung
Wie kann eine Schadensbegrenzung aussehen? Wenn ein Angreifer
Zugang zu Ihrer Anwendung bekommt, auf welche Ressourcen
kann er dann zugreifen? Das Prinzip der minimalen Rechtevergabe
für Benutzer und Prozesse kann bei der Verhinderung weiteren
Schadens helfen.
Implementieren Sie sichere Standardeinstellungen
Werden vertrauliche Informationen an den Client gemeldet, wenn
Ihre Anwendung versagt? Folgt das Standardbenutzerkonto dem
Prinzip der minimalen Rechtevergabe? Ist es initial abgeschaltet
und muss bei Bedarf explizit aktiviert werden?
Bieten Sie eine möglichst geringe Angriffsfläche
Hat Ihr System Services oder Ports, die nicht benutzt werden? Bietet
Ihre Anwendung Funktionen, die nicht benötigt werden? Entfernen
oder deaktivieren Sie diese und verkleinern Sie so die Angriffsfläche
Ihrer Applikation.
19
Vermeiden Sie eine Überlastung Ihrer Anwendung
Stellen Sie den Betrieb Ihrer Anwendung auch dann sicher, wenn
eine große Anzahl von Anfragen, Transaktionen und/oder ein hohes
Aufkommen an Netzwerkverkehr bewältigt werden muss. Ziehen
Sie eine defensive Umverteilung der Ressourcen in Betracht:
I Verwenden Sie Thread Pooling, um die maximale Anzahl von
Threads, die einer Benutzer-Session zugeordnet werden können, zu limitieren.
I Beschränken Sie die Anzahl von Datenbankverbindungen, die
für Benutzer-Sessions zur Verfügung stehen.
I Beschränken Sie die Anzahl gleichzeitiger Sessions für einen
Benutzer. Dies gilt besonders für Gastkonten.
I Legen Sie Quoten für den Gebrauch von Ressourcen fest,
wie z. B. Verzeichniszugriff, Speicherzuordnung oder Prozessorgebrauch.
4.2
Sichere Architektur
Neuere Anwendungen, im Folgenden als Web-Anwendungen
bezeichnet, basieren meist auf dem zustandslosen („stateless“)
HTTP-Protokoll. Daher muss eine Anwendung in der Lage sein, mit
Hilfe eines Session-Managements nachfolgende Anfragen einem
einmal authentisierten Benutzer zuzuordnen. Alle Berechtigungsentscheidungen, die nach der initialen Authentisierung erfolgen,
basieren auf der Identität des Benutzers und somit der Session-ID.
Daher ist es besonders wichtig, dass der Authentisierungsprozess
selbst sicher ist; auch der Mechanismus für die Verwaltung der
Benutzer-Session, der den authentisierten Benutzer überwacht,
muss gut geschützt sein. Daneben kommt auch der Verhinderung
von Parametermanipulationen und der Offenlegung vertraulicher
Daten besondere Bedeutung zu.
20
Verhindern von
SessionManipulationen
Authentisierung
Sichere
Konfiguration
Verhindern von
Parametermanipulation
Revision und Protokollierung
von Aktivitäten und
Transaktionen
Eingabeprüfung
AppServer
Schutz von
vertraulichen
Daten
Fehlerhandhabung
WebServer
Benutzerauthentisierung
Verbindungstrennung nach
vorgegebener
Zeit
DB-Server
Verschlüsselung
vertraulicher
Daten
Abbildung 2: Sichere Softwarearchitektur
So genannte „Service-oriented Architectures (SOA)” basieren auf
dem Prinzip des „Distributed Computing”, bei dem Anwendungsfunktionen als konfigurierbares Bündel von geschäftsprozessorientierten Services zur Verfügung gestellt werden, um eine möglichst
hohe Anpassungsfähigkeit zu gewährleisten.
Hier sichert das Session-Management ausschließlich den Kontakt
zwischen Benutzer und Web-Oberfläche, etwa einem Portal.
Darüber hinaus kommt dem Berechtigungsverfahren besondere
Bedeutung zu, denn die angebotenen Services können auf unterschiedlichen Plattformen mit eigenen Benutzerverwaltungs- und
Sicherheitsrichtlinien liegen; bei streng serviceorientierten Applikationen ist sogar häufig keine lokale Benutzerverwaltung mehr vorhanden.
21
Aus diesem Grund muss das Unternehmen eine zentrale Benutzerverwaltung bereitstellen, die den Zugriff auf alle Komponenten
regelt und die Sicherheit der Anwendungen gewährleistet. Es
müssen Sicherheitsrichtlinien erstellt werden, die auch externe
Benutzer umfassen. Sicherheit muss sich an Schichten und Hierarchien orientieren und zentral verwaltet werden.
Im Hinblick auf die Verfügbarkeit ist ein verteiltes System generell
angreifbarer. Funktioniert eine zentrale Verwaltungskomponente
nicht, liegt das gesamte System still. Ein Redundanzkonzept kann
sinnvoll sein, ist jedoch aufwendig.
Auch in Bezug auf die Datenintegrität bieten verteilte Systeme
mehr Angriffsmöglichkeiten.
4.3
Eingabeprüfung
Cross-Site Scripting (XSS), SQL Injections, Buffer Overflows und
andere Angriffe, die auf Benutzereingaben basieren, können durch
die Überprüfung aller eingegebenen Daten verhindert werden.
Beachten Sie die folgenden Regeln:
Vertrauen Sie keiner Benutzereingabe
Gehen Sie immer davon aus, dass eine Dateneingabe böswillig ist
bis das Gegenteil bewiesen ist. Unabhängig davon, ob die Eingaben
von einem Benutzer, einem Service, einem File Share oder einer
Datenbank kommen; prüfen Sie die Eingaben, wenn die Eingabequelle außerhalb des jeweiligen Vertrauensbereichs liegt.
Zentralisieren Sie die Prüfung
Die Strategie zur Validierung von Benutzereingaben ist ein grundlegender Bestandteil Ihres Anwendungsdesigns. Implementieren Sie
zentrale Funktionen für die Prüfung von Eingaben. So können Sie
22
sicherstellen, dass die Validierungsregeln konsistent umgesetzt
werden; zudem reduzieren Sie den Entwicklungsaufwand und vereinfachen die Wartung.
Validieren Sie unbedingt auf Serverseite
Der Client kann einfach umgangen werden; auch der Client-seitige
Script-Code kann schnell manipuliert oder abgeschaltet werden.
Verlassen Sie sich nicht auf eine Prüfung am Client. Der Server sollte eine eigene Validierung aller Eingaben vornehmen.
Validierung von Dateipfad und URL
Konvertieren Sie Parameter in eine kanonische Form, bevor sie
validiert und gefiltert werden.
Beispiel: Der folgende String enthält Datei- und Pfadnamen in ihrer
Grundform:
c:\data\anyfile.htm
Auch der folgende String könnte auf diese Datei, anyfile.htm, verweisen:
I c:\data\sub\..\anyfile.htm
I c:\ data\ anyfile.htm
I ..\anyfile.htm
I c%3A%5Cdata%5Csub%5C%
I 2E%2E%5-Canyfile.htm
Konzipieren Sie Ihre Anwendungen so, dass diese keine Dateinamen
und ähnliche Eingaben von Benutzern benötigen. Sollte dies unumgänglich sein, müssen sie in kanonischer Form vorliegen, bevor
sicherheitsrelevante Entscheidungen wie beispielsweise das
Gewähren eines Zugriffs auf bestimmte Ressourcen, getroffen werden.
23
Validieren, ablehnen, säubern
Eine effektive Strategie zur Prüfung von Eingaben sollte den folgenden Prinzipien unterliegen:
I Prüfen Sie alle Daten auf Art, Länge, Format und Auswahlbereich.
I Akzeptieren Sie nur Eingaben, die diese Prüfung bestanden
haben.
I Entfernen Sie schädliche Daten aus den Eingaben.
4.4
Parametermanipulation
Mit Hilfe eines (Client-seitigen) Proxy zwischen Client (Browser)
und (Web-) Anwendung ist es für einen Angreifer einfach, Anfragedaten wie Query-Strings, Formularfelder, Cookies oder HTTPHeader zu manipulieren, bevor sie zum Server geschickt werden.
Die folgenden Verfahren schützen Ihre Anwendung vor Angriffen
durch Parametermanipulation:
Prüfen Sie alle Daten, die vom Client kommen
Schränken Sie die Anzahl der Felder ein, die der Benutzer ändern
kann. Prüfen Sie alle Werte, die der Client übermittelt. Vordefinierte
Werte, beispielsweise in Form von Listen, können geändert werden;
lassen Sie nur Werte zu, die Sie zuvor definiert haben.
Verschlüsseln und signieren Sie vertrauliche Daten
Vertrauliche Daten, etwa zum Identifizieren einer Session, zur
Berechtigungsprüfung auf Serverseite oder vertrauliche Benutzerdaten in Client-seitigen Cookies bzw. dynamisch generierten
Webseiten sollten verschlüsselt und digital signiert werden, damit
sie nicht gelesen oder manipuliert werden können.
Prüfen Sie Informationen aus dem HTTP-Header
HTTP-Header werden in HTTP-Anfragen und -Antworten mitgeschickt. Header-Informationen sind für einen Angreifer einfach zu
24
manipulieren; stellen Sie sicher, dass keine ungeprüften HeaderInformationen weiterverarbeitet werden, insbesondere keine
Benutzernamen oder gar Passwörter.
4.5
Authentisierung
Ein Authentisierungsverfahren garantiert, dass ein Benutzer oder
Prozess derjenige ist, für den er sich ausgibt.
Üblicherweise authentisiert sich ein Benutzer mit Hilfe von
Benutzername und Passwort. Für Anwendungen mit hohen Sicherheitsanforderungen reicht diese Art der Authentisierung jedoch
nicht aus. Die Kombination von Wissen (Passwort) und Besitz
(z. B. Beiner Smartcard) bietet stärkeren Schutz. Andere Verfahren
sind Einmalpasswörter oder digitale Zertifikate auf Smartcards bzw.
anderen Tokens. Auch biometrische Verfahren wie Fingerabdruck
oder Iris-Scan sind bereits verbreitet.
Die zusätzlichen Ausgaben für solche Hardware-gestützten
Lösungen können im Notfall hohe Kosten vermeiden.
Verwenden Sie Sperrfunktionen für Benutzerkonten
Ziehen Sie in Erwägung, eine Sperrfunktion einzubauen, die das
Konto eines Benutzers automatisch nach einer vorgegebenen
Anzahl fehlgeschlagener Anmeldeversuche sperrt. Das Sperren von
Benutzerkonten ist die grundlegende Verteidigung gegen sogenannte Brute-Force-Angriffe.
Sperren Sie Benutzerkonten für kurze Zeit und protokollieren Sie die
Ereignisse in einer Log-Datei, wenn die Anmeldung mehrere Male
fehlgeschlagen ist. Beachten Sie jedoch, dass eine solche Kontensperrungsstrategie auch ausgenutzt werden kann, um Denial-ofService-Angriffe zu starten.
25
Setzen Sie eine Ablauffrist für Passwörter
Passwörter sollten regelmäßig geändert werden; richten Sie zu
diesem Zweck einen Ablaufmechanismus ein.
Implementieren Sie ein Verfahren zur Sperrung
von Benutzerkonten
Hat ein Angreifer Ihr System erfolgreich gehackt, müssen Sie zur
Schadensbegrenzung in der Lage sein, schnell zu reagieren und
Benutzerkonten zu sperren.
Speichern Sie keine Passwörter bei den Benutzerdaten
Zum Verifizieren von Passwörtern reicht es aus, diese in Form eines
Einweg-Hash-Werts zu speichern.
Akzeptieren Sie nur starke Passwörter
Implementieren Sie eine Passwortrichtlinie. Generelle Regeln sind:
Passwörter sollten mindestens 8 Zeichen lang sein und sowohl
Klein- als auch Großbuchstaben, Zahlen und Sonderzeichen enthalten. Bieten Sie ein Verfahren zum Testen von Passwörtern an.
Übermitteln Sie Passwörter nicht im Klartext
Schicken Sie Passwörter nicht im Klartext über das Netz. Sichern Sie
Ihre Kommunikationskanäle, z. B. durch die Verwendung von SSL
zur Verschlüsselung von HTTP-Verbindungen.
Schützen Sie Cookies, die der Authentisierung dienen
Ein gestohlenes Authentisierungs-Cookie ist gleichbedeutend mit
einer gestohlenen Identität. Schützen Sie Cookies mit Hilfe von
verschlüsselten Datenkanälen. Beschränken Sie außerdem die
Gültigkeitsdauer eines Authentisierungstickets. So können Sie die
Gefahr des Spoofing verringern: Dem Angreifer bleibt weniger Zeit,
ein gestohlenes Cookie böswillig einzusetzen.
26
Trennen Sie öffentliche und geschlossene Bereiche
Ein öffentlicher Bereich Ihrer Website kann anonym von jedem
beliebigen Benutzer besucht werden. Geschlossene Bereiche können nur von bekannten Benutzern nach vorheriger Authentisierung
aufgerufen werden. Durch das Aufteilen einer Einzelhandelsseite
in einen öffentlichen und einen geschlossen Bereich können Sie
beispielsweise unterschiedliche Authentisierungs- und Berechtigungsregeln anwenden und die Nutzung von SSL einschränken.
4.6
Berechtigungen
Berechtigungen legen fest, was ein authentisierter Benutzer tun
kann und auf welche Ressourcen er zugreifen darf. Ein schwaches
Berechtigungsverfahren ist gefährlich, weil ein Angreifer vertrauliche Daten problemlos einsehen und manipulieren kann. Legen Sie
daher besonderen Wert auf Ihre Berechtigungsstrategie.
Bauen Sie mehrere Verteidigungsmechanismen ein
Wenn Sie nur einen Sicherheitsmechanismus implementieren,
gehen Sie ein hohes Risiko ein. Entdeckt ein Angreifer diesen
Schwachpunkt, ist das gesamte System in Gefahr. Daher verstärkt
jeder zusätzliche Mechanismus, der an einem anderen Punkt
ansetzt, die Sicherheit des gesamten Systems.
Ein Beispiel: Die Web-Permissions des Web-Servers gelten unabhängig vom Benutzer für alle Ressourcen, die über das HTTPProtokoll angefordert werden. Sie bieten keinen Schutz, wenn ein
Angreifer es geschafft hat, sich am Server anzumelden. Nutzen Sie
zusätzlich Berechtigungen auf Dateiebene, um den Zugriff des
Webservers auf die notwendigen Dateien zu begrenzen.
27
Schränken Sie den Ressourcenzugriff auf Systemebene ein
Verwenden Sie Access Control Lists (ACLs), um den Ressourcenzugriff auf Systemebene einzuschränken. Dazu gehören beispielsweise Dateien, Ordner, Geräte im Netz, Datenbankobjekte oder
Ereignisprotokolle. Legen Sie fest, welche Benutzer welche Ressourcen nutzen können und welche Art von Nutzung vorgesehen ist.
Dies gilt besonders für anonyme Internet-Benutzerkonten; sichern
Sie diese mit ACLs, die den Zugriff speziell für anonyme Benutzer
einschränken.
Legen Sie die Granularität der Berechtigungen für den
Ressourcenzugriff fest – Zugriff über Rollen
Die Entscheidung über das Zugriffsrecht basiert auf der Rolle des
Aufrufenden, der ein Benutzer oder ein System sein kann. Die
Aufrufer werden auf Anwendungsebene (Middle-Tier) auf Rollen
abgebildet; der Zugriff auf Programm-Module hängt von der
Zugehörigkeit zu bestimmten Rollen ab. Der nachfolgende Zugriff
auf Ressourcen erfolgt mit Hilfe einer vorgegebenen Anzahl von
Identitäten, die in Verbindung mit der Rollenzugehörigkeit des Aufrufers stehen. Der Vorteil dieser Methode liegt darin, dass die
Berechtigungen, die jeder Rolle zugeordnet sind, einer festen Anzahl von Datenbankkonten zugeordnet werden können. Connection
Pooling kann nach wie vor genutzt werden.
Weitere Informationen finden Sie im Kapitel Revision und Logging.
28
☺
Web- / App-Server
1
☺
2
☺
3
Vertrauensbereich
Rolle A
ID des
vertrauenswürdigen
Service A
Rolle B
ID des
vertrauenswürdigen
Service B
☺
DB-Server
ID 1 & 2 mit
unterschiedlichen
Rechten
4
Abbildung 3: Rollenbasierter Zugriff
Zugriff über „Impersonation“
Ein feingranularer Ansatz kann über das Prinzip der „Impersonation” erzielt werden. Ressourcen werden mit Hilfe des Sicherheitskontexts einem Betriebssystembenutzer zugeordnet. Dieser
Ansatz kann sinnvoll sein, wenn Ihre Anwendung Zugriffsrechte
primär auf benutzerspezifische Ressourcen vergibt. Der Vorteil des
Verfahrens besteht darin, dass (abhängig vom Host-Betriebssystem
und der Entwicklungsumgebung) eine Revision auf Betriebssystemebene möglich ist, weil der Sicherheitskontext hier bekannt
ist. Ein Nachteil liegt in der geringen Skalierbarkeit, weil ein effektives Connection Pooling für den Datenbankzugriff nicht möglich
ist. Impersonation wird daher meist in Intranet-basierten Anwendungen, die in ihrer Reichweite begrenzt sind, eingesetzt.
Web- / App-Server
☺
Vertrauensbereich
1
1
☺
2
☺
2
Impersonation/
Delegation
3
3
☺
4
4
Abbildung 4: Zugriff über Impersonations
29
DB-Server
Zugriff über eine Pool-Identität
Die am wenigsten granulare, aber am besten skalierbare Methode
ist die Steuerung des Ressourcenzugriffs über eine Pool-Identität.
Unabhängig vom tatsächlichen Benutzer sind der Pool-Identität
immer dieselben Berechtigungen zugewiesen. Das primäre Berechtigungsverfahren läuft im Middle-Tier des Systems auf der Basis von
Rollen ab: Hier werden Benutzer mit gleichen Privilegien in einer
Sammelrolle zusammengefasst. Dieses Verfahren unterstützt
Datenbank-Connection-Pooling.
Web- / App-Server
☺
Vertrauensbereich
☺
2
☺
Rollenbasierte
Berechtigungen
DB-Server
Datenbank
vertraut dem
Web/App-Server
1
ID des
vertrauenswürdigen
Service
3
☺
4
Abbildung 5: Zugriff über eine Pool-Identität
4.7
Anwendungskonfiguration
Bei der Konfiguration Ihrer Anwendung sollten Sie besondere
Vorsicht walten lassen, denn im schlimmsten Fall eines erfolgreichen Angriffs verschafft sich der Angreifer Administratorrechte
für das System. Die meisten Anwendungen benötigen spezielle
Schnittstellen für Administratoren und Entwickler, die Benutzerkonten und -profile sowie die Inhalte von Webseiten verwalten.
Im Fall einer Remote-Administration müssen diese Schnittstellen
besonders gesichert werden. Beachten Sie einige grundlegende
Aspekte für die sichere Konfiguration Ihrer Anwendung:
30
Sichern Sie die Konfigurationsschnittstellen
Stellen Sie sicher, dass die Funktionen zur Konfiguration Ihrer
Anwendung nur berechtigten Benutzern zur Verfügung gestellt
werden. Setzen Sie hier eine starke Authentisierung ein, beispielsweise über Zertifikate. Wenn möglich, verlangen Sie eine lokale
Anmeldung am System. Vermeiden Sie eine Remote-Administration, oder schränken Sie die hierbei verfügbaren Möglichkeiten ein;
wenn nötig, verschlüsseln Sie die Datenkanäle mit Hilfe von SSL.
Beschränken Sie die Remote-Administration auf Computer im internen Netzwerk unter Verwendung von IPSec.
Sichern Sie den Speicherort der Konfigurationsdaten
Konfigurationsdaten werden üblicherweise in Textdateien, Datenbanken oder der Registry abgelegt. Speichern Sie die Daten nie
im Klartext, sondern schützen Sie sie durch Verschlüsselung und
beschränken und sichern Sie den Zugriff auf den Speicherort.
Verwenden Sie unterschiedliche Konfigurationsprivilegien
Beschränken Sie den Zugriff auf Konfigurationsdaten. Die Entscheidung über Zugriffsberechtigungen sollte auf den unterschiedlichen
Aufgaben der jeweiligen Administratoren basieren: So sollte der
Entwickler, der für die Aktualisierung von Inhalten verantwortlich
ist, andere Rechte haben als der Administrator, der die Kreditlimits
von Kunden ändert.
Folgen Sie dem Prinzip der minimalen Rechtevergabe
Richten Sie die Prozesskonten, die für den Betrieb des Web-ServerProzesses genutzt werden, mit minimalen Rechten ein. Dies gilt
auch für Servicekonten, die für den Zugriff auf nachfolgende
Ressourcen und Systeme verwendet werden. Wenn ein Angreifer
die Kontrolle über einen Prozess erlangt, der nur eingeschränkten
Zugriff auf ein Dateisystem ermöglicht, ist der anzurichtende
Schaden begrenzt.
31
4.8
Vertrauliche Daten
Werden in Ihrer Anwendung vertrauliche Daten, etwa Passwörter,
Anmeldeinformationen, Datenbankverbindungsstrings oder andere
Konfigurationsdaten, Bankkontennummern, Kreditkartennummern,
Adressen oder medizinische Unterlagen verarbeitet, müssen Sie
besondere Schutzmaßnahmen treffen. Neben dem zu erwartenden
finanziellen Schaden müssen auch rechtliche Folgen bedacht werden, die ein erfolgreicher Angriff auf eine solche Anwendung nach
sich ziehen kann. Folgende Verfahren können zum Schutz der Daten
angewandt werden:
Vermeiden Sie die Speicherung von vertraulichen Daten
Vermeiden Sie die Speicherung vertraulicher Daten soweit wie
möglich. Jeder, der Zugriff auf den Server hat, z. B. ein Administrator, kann die Informationen lesen. Um zu prüfen, ob ein Benutzer
vertrauliche Daten, beispielsweise sein Passwort, kennt, können Sie
den Hash-Wert des Passworts speichern, den Hash-Wert aus der
Benutzereingabe des Passworts berechnen und die Werte vergleichen.
Speichern Sie keine geheimen Daten im Code
Speichern Sie keine Geheimnisse in hartkodierter Form im Code.
Ein Angreifer, der Zugriff auf die ausführbaren Dateien hat, kann
String-Konstanten aus den kompilierten Dateien extrahieren, auch
wenn der Quellcode nicht auf dem Anwendungsserver sichtbar ist.
Verschlüsseln Sie vertrauliche Daten oder sichern Sie den
Kommunikationskanal
Wenn Sie vertrauliche Daten über das Netz zum Client schicken,
verschlüsseln Sie die Daten oder den Übertragungsweg. Ein verbreitetes Verfahren ist die Verwendung von SSL zwischen Client und
Web-Server. Zwischen Servern wird mittlerweile häufig IPSec verwendet. Zum Schutz von Informationen, die mehrere Zwischen-
32
stationen durchlaufen, beispielsweise SOAP-Nachrichten (=Simple
Object Access Protocol) in Web-Services, können Sie Verschlüsselungsverfahren auf Nachrichtenebene einsetzen.
Speichern Sie keine vertraulichen Informationen
in persistenten Cookies
Vermeiden Sie es, vertrauliche Daten in persistenten Cookies zu
speichern. Wenn die Daten im Klartext abgespeichert werden, kann
der Benutzer sie sehen und modifizieren. Werden die Daten verschlüsselt, ist eine sichere Verwaltung der zugehörigen Schlüssel
wichtig. Ist beispielsweise der Schlüssel, der zur Verschlüsselung
der Daten im Cookie verwendet wurde, abgelaufen, während das
Cookie noch gültig ist, kann der neue Schlüssel die Daten bei der
Übergabe vom Browser an den Server nicht mehr entschlüsseln.
Übermitteln Sie keine vertraulichen Daten über das
HTTP-GET-Protokoll
Vermeiden Sie es, vertrauliche Daten vom Client an den Server mit
Hilfe des HTTP-GET-Protokolls zu übermitteln. Das Protokoll verwendet URL-Query-Strings für die Datenübertragung. Diese bieten
keinen Schutz für die übermittelten Informationen und werden
häufig vom Server protokolliert.
4.9
Einsatz von Kryptographie
Die folgenden Vorgehensweisen verbessern den Schutz Ihrer Anwendung, wenn kryptographische Verfahren eingesetzt werden:
Verwenden Sie bewährte Kryptographieverfahren
Entwickeln Sie keine eigenen Verfahren, sondern nutzen Sie die
bewährten Kryptographieservices oder Bibliotheken, die in Ihrem
Betriebssystem oder Ihrer Entwicklungsumgebung enthalten sind.
33
Lassen Sie Ihre Daten so lange wie möglich verschlüsselt
Greifen Sie erst auf die Klartextdaten zu, wenn dies nötig ist und
speichern Sie sie in so wenig Variablen wie möglich ab.
Wählen Sie den passenden Algorithmus und
angemessene Schlüssellängen
Wählen Sie einen passenden Algorithmus und die erforderliche
Schlüssellänge für Ihre Sicherheitsanforderungen. Der Grad der
Sicherheit steigt mit der Schlüssellänge. Im folgenden sind die
bekanntesten Algorithmen aufgeführt.
Algorithmus
Schlüssellänge
Einsatz
TripleDES
128-Bit oder 192-Bit
(16 oder 24 Bytes)
Verschlüsselung großer
Datensätze
AES
128-256 Bit (16-32 Bytes)
Langsame, aber starke Verschlüsselung großer Datensätze
DES
64-Bit (8 Bytes)
Verschlüsselung ist nicht sicher
Rivest, Shamir and Adleman (RSA)
oder Digital Signature Algorithm
(DSA)
384-16, 384 Bit (48-2,048 Bytes)
Digitale Signaturen
Secure Hash Algorithm (SHA)1.0
Hashing
Hash-based Message Authentication
Code (HMAC) SHA1.0
Keyed Hashing
Schützen Sie die Schlüssel
Um die Sicherheit der verschlüsselten Daten zu gewährleisten,
muss der zugehörige Schlüssel geschützt werden:
I Wechseln Sie den Speicherort der Schlüssel in regelmäßigen
Abständen
I Speichern Sie Schlüssel wenn möglich auf gesonderter Hardware
Das deutsche „Bundesamt für Sicherheit in der Informationstechnik“ (BSI) stellt einen Katalog mit Verschlüsselungsstandards zur
Verfügung. Sie können den Katalog unter
http://www.bsi.bund.de/esig/basics/techbas/krypto/
herunterladen. Hier finden Sie weitere Informationen sowie einen
Vergleich der Verfahren.
34
4.10 Session-Management
Das HTTP-Protokoll, das die meisten Web-Anwendungen nutzen, ist
ein zustandsloses Protokoll. Damit hier Benutzer-Sessions verwaltet werden können, wurden für Anwendungsserver Verfahren entwickelt, die Session-Management auf Anwendungsebene betreiben. Die Session selbst wird mit Hilfe einer Session-ID überwacht,
die beispielsweise in einem Cookie oder den Parametern eines
Formularfeldes gespeichert ist. Der Schutz dieser ID ist von großer
Bedeutung für die Gesamtsicherheit des Systems. Für die sichere
Verwaltung von Benutzer-Sessions sollten die folgenden Grundsätze gelten:
Verwenden Sie SSL, um die Session-ID zu schützen
Vermeiden Sie es, Session-IDs über unverschlüsselte Datenkanäle
zu übertragen. Dies gilt unabhängig davon, ob die ID in einem
Cookie oder einem versteckten Feld gespeichert ist. Verwenden Sie
stattdessen eine HTTPS-Verbindung.
Verschlüsseln und signieren Sie Cookies
Verschlüsseln und signieren Sie Cookies, auch wenn Sie SSL einsetzen. Diese Vorgehensweise schützt das Cookie vor unbefugtem
Zugriff, auch wenn ein Angreifer es – z. B. durch einen XSS-Angriff –
entwenden kann.
Beschränken Sie die zeitliche Dauer einer Session
Reduzieren Sie die zeitliche Dauer einer Session auf den kleinstmöglichen Wert, idealerweise ist das Session-Cookie genau für eine
weitere Anfrage gültig. So schränken Sie das Risiko des „Session
Hijacking“ und sogenannter Replay-Angriffe ein.
35
Schützen Sie den Session-Status vor unbefugtem Zugriff
Wenn der Session-Status eines Benutzers nicht im Prozess der WebAnwendung selbst, sondern beispielsweise in einer Datenbank
gespeichert ist, müssen Sie diese Daten sowohl bei der Übertragung
als auch bei der Speicherung schützen. Die Verbindung zwischen
Web-Anwendungsserver und Speicherort der Session-Daten sollte
durch IPSec oder SSL gesichert werden.
4.11 Fehlerbehandlung
Wenn eine Anwendung versagt, kann mit Hilfe sicherer Fehlerbehandlungsverfahren weiterer Schaden vermieden werden, der
beispielsweise durch Denial-of-Service-Angriffe auf Anwendungsebene oder unbefugten Zugriff auf interne Systeminformationen
wie Datenbankstrukturen bzw. Produkt- und Betriebssysteminformationen, entstehen könnte. Nachdem ein Fehler aufgetreten ist,
befinden sich Systeme oft in einem undefinierten Zustand;
Benutzerberechtigungen sind möglicherweise geändert.
Zudem erzeugen viele Laufzeitumgebungen Debugging-Informationen und Stack Traces, die im Falle eines Fehlers auf Anwendungsebene an den Client zurückgemeldet werden. Dies kann in
der Entwicklungsphase sinnvoll sein, wird aber zum ernstzunehmenden Sicherheitsproblem, wenn das System in den Produktivbetrieb übergeht.
Säubern Sie Ihre Fehlermeldungen
Prüfen Sie alle Informationen, die im Fehlerfall an den Client gemeldet werden. Entfernen Sie gegebenenfalls interne Informationen
wie Stack Traces, Datenbankstrukturen, Funktionsnamen, Zeilennummern oder Versionsnummern aus den Fehlermeldungen. Stattdessen sollte eine generische Meldung erscheinen, die eine Fehlerprotokoll-ID enthält und so auf den entsprechenden Eintrag im Log
File des Servers verweist.
36
Protokollieren Sie alle Fehler
Während der Benutzer nur die absolut notwendigen technischen
Informationen in der Fehlermeldung erhalten sollte, ist es sinnvoll,
ausführliche Fehlermeldungen im Fehlerprotokoll festzuhalten.
Fehlermeldungen sollten eine Fehler-ID enthalten, die auf einen Eintrag im Protokoll verweist. Vertrauliche Daten, wie z. B. Passwörter,
sollten jedoch nicht protokolliert werden.
Decken Sie alle Ausnahmefälle ab
Decken Sie alle Ausnahmen ab, die in Ihrer Anwendung bzw. dem
Framework und den APIs (Application Programming Interfaces) vorkommen können. So vermeiden Sie Inkonsistenzen, die zur unbeabsichtigten Offenlegung von Informationen führen oder Denial-ofService-Angriffe begünstigen könnten.
Die Behandlung und Verbreitung von Fehlern und Ausnahmen
innerhalb Ihrer Anwendung muss sorgfältig geplant werden.
4.12 Prinzip der minimalen Rechtevergabe
Systeme sollten nach dem Prinzip der minimalen Rechtevergabe
aufgebaut sein. Statten Sie Benutzerkonten nur mit den tatsächlich
benötigten Rechten aus.
Betriebssystem
Deaktivieren Sie alle nicht benötigten Services.
Applikationsserver/Web-Server
Ein vergessener Share kann eine bequeme Hintertür für einen
Hacker darstellen, ein übersehener Port gar einen komfortablen
Haupteingang. Vernachlässigte Benutzerkonten erlauben es einem
Angreifer, Ihre Sicherheitsmechanismen ungesehen zu passieren.
37
Legen Sie separate anonyme Konten mit den minimal erforderlichen
Privilegien an, die für den Zugriff über das Web eingesetzt werden
können. Verwenden Sie ein solches Konto pro Anwendung, damit
Sie den Betrieb jeder Anwendung einzeln absichern und prüfen
können.
Servicekonten sollten ebenfalls nur mit den unbedingt erforderlichen Rechten ausgestattet sein.
Datenbankserver
Halten Sie sich auch hier an das Prinzip der minimalen Rechtevergabe.
Remote-Administration
Schränken Sie ein, welche Tools einem Remote-Administrator zur
Verfügung stehen. Geben Sie auch vor, welche Rechner den WebServer administrieren dürfen. Legen Sie mit Hilfe von IPSec fest,
welche Rechner den Web-Server administrieren dürfen.
4.13 Revision und Logging
Jedes System sollte sicherheitsrelevante Aktivitäten über alle
Schichten hinweg protokollieren. Nur so kann Missbrauch festgestellt werden, denn ein typischer Angriff auf Anwendungsebene
erscheint zunächst häufig wie eine ganz normale Systemnutzung.
Verwenden Sie Revisions- und Protokollierungsverfahren
Protokollieren Sie alle sicherheitsrelevanten Aktivitäten und
Transaktionen über das gesamte System hinweg. Verwenden Sie
Protokollierungsmechanismen auf Systemebene für Ihren eigenen
Code und aktivieren Sie die entsprechenden Funktionen der Produkte, die Sie einsetzen (Web-Server, Anwendungsserver, Datenbank, Betriebssystem usw.). Aktivitäten der folgenden Kategorien
sollten in jedem Fall protokolliert werden:
38
I
I
I
I
I
I
Anmeldeversuche
Dateizugriff
Datenbankzugriff
Netzwerkzugang
Systemzugriff
Verwendung administrativer Funktionen
Versehen Sie alle Protokolle mit genauen Zeitstempeln, um die spätere Analyse zu vereinfachen und die Synchronisation mehrerer
Protokolle, z. B. für Datenbank und Anwendung oder Zeiterfassung,
zu ermöglichen.
Zudem sollten Protokolleinträge die folgenden Informationen enthalten:
I ID des aktuellen Benutzers
I ID der Ressource, auf die zugegriffen wurde
I ID des aktuellen Prozesses / Threads
Berücksichtigen Sie die Weitergabe von IDs
Legen Sie fest, wie Ihre Anwendung Benutzer-IDs über die Anwendungsschichten hinweg weiterleitet. Es gibt zwei Möglichkeiten:
Die IDs können (z. B. mit Hilfe der Kerberos-Protokolldelegation) auf
Betriebssystemebene weitergeleitet werden. Dies ermöglicht die
Nutzung der Prüffunktionen auf Betriebssystemebene. Ein Nachteil
dieses Ansatzes liegt in der Einschränkung der Skalierbarkeit: In der
Middle-Tier kann kein effektives Datenbank-Connection-Pooling
stattfinden. Eine andere Möglichkeit ist die Weiterleitung der ID auf
Anwendungsebene und die Verwendung vertrauenswürdiger IDs
für den Zugriff auf Back-End-Ressourcen. Bei diesem Ansatz müssen Sie dem Middle-Tier vertrauen und es besteht das Risiko der
Abstreitbarkeit (Repudiation). Sie müssen im Middle-Tier Revisionsbelege erzeugen, die mit solchen im Back-End korrelieren können.
Dazu muss sichergestellt sein, dass die Server-Uhren synchron sind.
39
Beschränken Sie den Zugriff auf Protokolldateien
Beschränken Sie den Zugriff auf Protokolldateien auf einen kleinen
Personenkreis, um die Integrität der Dateien zu gewährleisten.
Speichern Sie Protokolle nicht auf dem Web-Server.
Rotation, Backup und Analyse von Protokollen
Rotieren Sie die Protokolldateien regelmäßig, beispielsweise täglich. Verschieben Sie geschlossene Protokolldateien vom Produktivsystem auf Offline-Server.
4.14 Design Review
Nach Abschluss der Design-Phase sollten Sie durch unabhängige
Experten ein Review vornehmen lassen. So können Sie Schwachstellen in der Konzeption bereits vor Beginn der eigentlichen Implementierungsphase erkennen und beseitigen.
40
5
Sichere Kodierung
Nachdem das sichere Design für Ihre Anwendung erstellt ist, sollten
Sie auch in der Kodierungsphase einige Regeln befolgen. Die hier
beschriebenen Konzepte sind programmiersprachenübergreifend
und universell auf fast jede Entwicklungsumgebung anwendbar.
Das folgende Kapitel bietet einen Überblick über die am stärksten
verbreiteten Angriffe und mögliche Abwehrmechanismen.
5.1
„Bewährte” Angriffsvarianten
5.1.1 Manipulation von Parametern
In Anwendungen kommen verschiedene Arten von Parametern vor,
darunter
I URI/URLs
I Cookie-Werte
I Formularfeldparameter
I HTTP-Header
Angreifer manipulieren diese Parameter, um Zugriff auf Daten zu
erhalten (z. B. durch das Verändern von URLs), unerwünschte Vorgänge zu starten (z. B. durch den Aufruf undokumentierter WebFunktionen) oder um die persönlichen Daten eines anderen Benutzers auszuspähen (etwa durch die Manipulation schwacher
Session- oder Dokument-IDs).
5.1.2 Cross-Site Scripting (CSS/XSS)
Anwendungen, bei denen Daten mindestens zwei Benutzern
gemeinsam zugänglich sind, sind anfällig für Cross-Site-ScriptingAngriffe (auch CSS- oder XSS-Angriffe genannt).
41
Eine ähnliche Angriffsvariante, bei der ein scheinbar vertrauenswürdiger „Mittelsmann” gezwungen wird, bösartige Daten weiterzuleiten, bezeichnet man als „Cross-Site Malicious Content“Angriff.
Ein typisches Beispiel für einen XSS-Angriff: Der Hacker einer
Web-Anwendung fügt bösartigen JavaScript-Code in eine Nachricht
ein, die von anderen gelesen wird, etwa in einem elektronischen
„Schwarzen Brett”. Prüft der Server nicht, ob die publizierten Daten
JavaScript enthalten, gelangt der bösartige Code auf die Clients der
anderen Benutzer und wird dort ausgeführt.
Typische XSS-Angriffe zielen auf die Session-ID eines nichts ahnenden Benutzers ab und leiten diese an den Angreifer weiter. Ist der
Angriff erfolgreich, kann die gestohlene Identität dazu benutzt
werden, mit den Rechten des ursprünglichen Besitzers auf den
Server zuzugreifen, Produkte zu bestellen, persönliche Daten zu
lesen oder Informationen zu manipulieren und im Namen des rechtmäßigen Besitzers zu versenden.
Der Browser kann einen XSS-Angriff nicht entdecken, da der ScriptCode von einer vertrauenswürdigen Quelle kommt: dem WebServer, auf dem die Anwendung vorgehalten wird. Aus demselben
Grund schützt auch die alleinige Verwendung von Verschlüsselung
auf Transportebene (SSL-Verbindungen) nicht vor XSS-Angriffen.
5.1.3 SQL Injection
Eine SQL Injection nutzt ein Formularfeld oder andere ClientParameter, mit deren Hilfe die Anwendung ein SQL-Statement generiert. Sie enthält SQL-Metasyntax wie den SQL String Delimiter (‘)
oder den Statement Concatenation Character (;) und fügt so ein
ausführbares SQL-Kommando an Stellen ein, an denen die Anwendung ein String Literal erwartet.
42
5.1.4 Buffer Overflow
Buffer Overflows kommen meist in Anwendungen vor, die mit
Programmiersprachen wie C/C++ entwickelt wurden. Diese
Sprachen unterstützen Datenstrukturen auf der Basis von Zeigern
und Zugriffe auf Datenstrukturen wie z. B. Felder ohne Prüfung des
zulässigen Wertebereichs.
Der Angreifer hat folgende Optionen:
Er kann versuchen, die Länge eines Feldes zu überschreiten, indem er mehr Daten in Textfelder oder Parameter schreibt als die
Anwendung erwartet. So kann der Prozess/Thread zum Absturz
gebracht werden.
Er kann daraufhin versuchen, Maschinencode-Befehle in den
Speicherbereich „hinter” dem Feld einzuschleusen. Diese Art des
Angriffs erfordert einige Kenntnisse und richtet sich typischerweise
gegen weit verbreitete Produkte (bekanntes Beispiel: sendmail),
weniger gegen eine individuelle Software.
In modernen Programmierumgebungen wie J2EE oder Microsoft
.NET werden Buffer Overflows in der Laufzeitumgebung abgefangen und der Anwendung durch eine Ausnahme gemeldet. Trotzdem sollte auch hier die Prüfung der Eingabelängen Teil der routinemäßigen Eingabevalidierung sein.
5.2
Eingabeprüfung
Prüfen Sie Länge, Art, zulässigen Wertebereich und Format
Sämtliche Eingaben am Client sollten auf folgende Punkte geprüft
werden:
Länge: Akzeptieren Sie keine Eingaben, die die vorgegebene Maximallänge überschreiten.
Art: Prüfen Sie die Art der Daten und akzeptieren Sie nur solche
Daten, die die Anwendung benötigt. Ein Datumsfeld beispielsweise
erfordert lediglich Zahlen und Punkte.
43
Wertebereich: Prüfen Sie den zulässigen Wertebereich. Ein sinnvoller Bereich für das Feld „Kalendertag“ besteht beispielsweise
nur aus den Zahlen 1-31.
Format: Prüfen Sie, ob die Eingabe dem erwarteten Format entspricht.
Wenden Sie ein positives Sicherheitsmodell an: Jede Eingabe, die
nicht explizit erlaubt ist, sollte geblockt werden.
Prüfen Sie HTML-Code
HTML-Code in Benutzereingaben stellt ein Risiko für WebAnwendungen dar, wenn die eingegebenen Daten dazu genutzt
werden, dynamisch Web-Seiten für andere Benutzer zu generieren. Eingaben sollten daher sorgfältig auf HTML-Code überprüft
werden.
Wenn Ihre Anwendung die Eingabe von HTML-Code zulässt,
beispielsweise um HTML-Tags in Web-Inhalten zu unterstützen,
die der Benutzer anlegt, sollten Sie den zulässigen Code auf
sichere Tags wie <b>, <i>, <p> und die entsprechenden End-Tags
beschränken.
Erlauben Sie Attribute in HTML-Tags nur dann, wenn sie auf bösartigen JavaScript-Code in den Attributen prüfen. Manche HTMLAttribute erlauben Script-Code, der bei der Weiterverarbeitung des
Tags ausgeführt wird.
Auch bei Hyperlink- (<a>) und Image-Tags (<image>) sollten Sie
besondere Vorsicht walten lassen. Diese Tags veranlassen den
Browser dazu, Daten von der entsprechenden Adresse zu laden.
44
Prüfen Sie auf SQL-Syntax
Eingaben, die zur Erzeugung eines SQL-Statements verwendet werden, müssen sorgfältig auf SQL-Meta-Zeichen wie ‘ oder; geprüft
werden, um SQL Injections zu verhindern. Bei dieser Art von Angriff
kann der Client über Web-Forms bösartige SQL-Statements an die
Back-End-Datenbank schicken.
Die Sicherheit kann durch den Einsatz gespeicherter Verfahren mit
Parametern für die Datenbankabfrage weiter verbessert werden.
LDAP
Alle Daten, die der Client meldet, müssen auf Zeichen oder Strings
geprüft werden, die für einen Angriff genutzt werden könnten. Die
beste Filtermethode ist, Positivlisten zu verwenden.
Alle Anwendungen, die Benutzereingaben direkt an die LDAPSuchmaschine weiterleiten, sind gefährdet.
Betriebssystemkommandos
Command Injections nutzen externe Betriebssystem- oder Anwendungskommandos, um Zugriff auf Systemressourcen zu erlangen.
Sie erlauben es dem Angreifer, durch die Nutzung privilegierter
Kommandos Sicherheitsmaßnahmen auf Anwendungsebene zu
umgehen.
Diese Art von Angriff wird häufig genutzt, um „außerhalb“ der
Anwendung versteckte Informationen und Services aufzuspüren.
Der Angreifer kann dazu Kommandos aus dem Betriebssystem oder
der CGI-Skriptsprache verwenden.
Um Command Injections zu vermeiden, müssen Metazeichen und
Schlüsselwörter, die für Kommandos reserviert sind, aus URLs,
Headers und Formularen gefiltert werden.
45
5.3
Reguläre Ausdrücke
Nutzen Sie reguläre Ausdrücke, um eine Prüfung auf gültige
Zeichen und Formate durchzuführen und die Eingaben von unerwünschten Zeichen zu säubern. Definieren Sie Muster für bestimmte Eingabekategorien:
Prüfen Sie numerische Eingaben
Prüfen Sie die Art der Zeichen, Eingabelänge und Format der numerischen Daten, z. B. [0-9]{1,3}, wenn alle positiven Zahlen zwischen
0 und 99 zugelassen sind.
Prüfen Sie Texteingaben
Schränken Sie die Bandbreite der zugelassenen Zeichenarten ein.
Prüfen Sie die Eingabelängen und String-Felder. Prüfen Sie die
Formatierungsregeln oder Eingabefelder für Zeit/Datum, Postleitzahl, Telefonnummer usw. Seien Sie vorsichtig bei Textfeldern, die
keine Formatvorgaben machen.
Der Anmeldename eines Benutzers kann mit Hilfe dieser Formel
geprüft werden, die nur alphanumerische Zeichen mit einer maximalen Eingabelänge von 20 Zeichen zulässt: [a-zA-Z0-9]{1,20}
5.4
URI/URLs
URIs sollten ebenso wie jede andere Eingabe vor der weiteren Verarbeitung geprüft werden. Ein Angreifer kann URIs benutzen, um
I Zugriff auf Dokumente / Verzeichnisse zu erlangen, die nicht an
die Öffentlichkeit gelangen sollen („Wild Browsing”)
I SQL-Abfragen oder andere unerwünschte Kommandos in eine
Anwendung einzuschleusen
I sich durch ausgetüftelte Verfahren an ihren Sicherheitsprüfungen vorbei in das System einzuschleichen
I einem Benutzer vorzuspielen, er befände sich auf einer bestimmten Site, während er in Wirklichkeit jedoch mit einem anderen
Server verbunden ist.
46
Prüfen Sie URI/URLs
Ein generischer regulärer Ausdruck für die genaue Prüfung von
URI/URLs ist sehr komplex und nicht immer notwendig (außer beispielsweise bei der Programmierung eines Web Servers). Meist
reicht ein vereinfachtes Muster aus. Das nachfolgende Beispiel verdeutlicht, wie für HTTP und HTTPS URLs validiert werden können:
^(http|https)://[-A-Za-z0-9._/]+$
Das zweite Muster lässt komplexere Links zu:
^(http|ftp|https)://[-A-Za-z0-9._]+(\/([A-Za-z0-9\
-\_\.\!\~\*\'\(\)\%\?]+))*/?$
5.5
Eingaben über Gerätedateien
Besondere Vorsicht ist beim Zugriff auf Dateien geboten, deren
Name durch eine Benutzereingabe erzeugt wurde. Dies gilt auch für
den Zugriff auf Gerätedateien.
Verwenden Sie stattdessen feste Dateinamen und Speicherorte,
wenn Daten von einem Gerät gelesen oder darauf gespeichert
werden sollen. So vermeiden Sie den unkontrollierten Zugriff auf
Dateien.
Wenn Sie dennoch vom Benutzer vergebene Dateinamen annehmen müssen, führen Sie die folgenden Prüfungen durch:
Prüfen Sie die Existenz
Bevor sie auf eine Gerätedatei zugreifen, prüfen Sie, ob die Datei
oder das Gerät wirklich existiert.
Prüfen Sie die Zugriffsrechte
Prüfen Sie, ob der Benutzer Zugriff auf die Datei / das Gerät hat.
47
Prüfen Sie den Speicherort
Prüfen Sie, ob der Dateipfad auf einen Speicherort verweist, der von
der Anwendung verwaltet wird.
Prüfen Sie die Eingaben
Prüfen Sie die Eingaben auf Escape-Sequenzen / unzulässige
Zeichen.
Verhindern Sie das Hochladen von ausführbaren Dateien
Erlauben Sie es nicht, dass potentiell gefährliche Dateien wie ausführbare Dateien, Batch-Dateien, Scripts etc. hochgeladen werden.
Verwenden Sie eine White List von Dateitypen, die hochgeladen
werden dürfen, und verbieten Sie alle anderen Dateitypen. Führen
Sie einen Virus-Scan durch.
5.6
Einsatz von Kryptographie
Obwohl in den meisten Anwendungen bewährte Kryptographieverfahren zum Schutz der Daten bei der Übertragung oder
Speicherung eingesetzt werden, gibt es einige Probleme, mit denen
Entwickler beispielsweise bei der Verwendung von Algorithmen und
der Verwaltung von geheimen Schlüsseln konfrontiert werden.
Die folgenden Verfahren unterstützen Sie bei der sicheren Verschlüsselung vertraulicher Daten:
Verwenden Sie bestehende Implementierungen
kryptographischer Algorithmen
Die sichere Implementierung eines kryptographischen Algorithmus ist ein höchst komplexer, zeitintensiver Prozess. Benutzen Sie
daher nur bestehende und bewährte Implementierungen von
Algorithmen für Verschlüsselung, Entschlüsselung, Hashing und die
Generierung von Zufallszahlen.
48
Speichern Sie Schlüssel nicht im Code
Hartkodierte, d.h. im Klartext sichtbare Schlüssel im Programmcode
können einfach dekompiliert werden.
Beschränken Sie den Zugriff auf die gespeicherten Schlüssel
Benötigt ein Prozess zur Laufzeit Zugriff auf die Schlüssel, die in
einem persistenten Speicher abgelegt sind, sollte der Zugriff nur
einem Administrator und dem Prozess erlaubt werden.
Schützen Sie geheime Schlüssel
In Public-Key-Infrastrukturen hängt die Gesamtsicherheit des
Systems vom Schutz der geheimen Schlüssel seiner Benutzer ab.
Geheime Schlüssel müssen verschlüsselt werden, wenn sie aus dem
lokalen Speicher exportiert werden.
Schützen Sie symmetrische Schlüssel
Bei der symmetrischen Verschlüsselung kann jeder, der den
symmetrischen Schlüssel kennt, den verschlüsselten Text entschlüsseln. Nur berechtigte Benutzer dürfen daher Zugriff auf den
Schlüssel haben.
Speichern Sie symmetrische Schlüssel nie im Klartext; ziehen Sie
eine Verschlüsselung der symmetrischen Schlüssel mit Hilfe von
Public-Key-Verfahren in Betracht.
Verwenden Sie Public-Key-Verfahren,
um symmetrische Schlüssel auszutauschen
Verwenden Sie Public-Key-Verfahren, um symmetrische Schlüssel
über ein unsicheres Netz auszutauschen. Symmetrische Schlüssel
werden aus Performance-Gründen häufig eingesetzt, um die vertraulichen Daten selbst zu verschlüsseln. Prüfen Sie das Zertifikat,
das den öffentlichen Schlüssel des Empfängers Ihrer verschlüsselten
Nachricht enthält, auf folgende Aspekte:
49
I
I
I
Gültigkeitsdauer des Zertifikats
Verifizierung aller Signaturen in der Zertifikatskette bis hin zur
vertrauenswürdigen Root-Zertifizierungsstelle
Das Zertifikat findet sich nicht auf der Rückrufliste, der sogenannten Certificate Revocation List (CRL), des Ausstellers
Verwenden Sie starke Zufallszahlengeneratoren
Verwenden Sie nur kryptographisch starke Zufallszahlen, die dem
US-Kryptographiestandard FIPS-140 entsprechen, für die Erzeugung von Schlüsseln und Initialisierungsvektoren.
Verwenden Sie große Schlüssellängen
Um Brute-Force-Angriffe auf verschlüsselte Daten zu erschweren,
sollten Sie die längste für Ihren Algorithmus verfügbare Schlüssellänge nutzen.
Verwenden Sie „salted“ Hash-Werte
Um Brute-Force-Angriffe zu erschweren, sollten Sie eine HashMethode einsetzen, die bei der Erzeugung von symmetrischen
Schlüsseln so genannte „Salt”-Werte unterstützt. Der Salt-Wert
muss gemeinsam mit dem Initialisierungsvektor sicher gespeichert
werden, damit der Schlüssel wieder entschlüsselt werden kann.
5.7
Session-Management
Bei der Implementierung des Session-Managements für Ihre
Anwendung sollten Sie besonderen Wert darauf legen, den Zugriff
auf Ihre Ressourcen in öffentliche und geschlossene Bereiche zu
unterteilen, sowie Tokens für Authentisierung und Sessions einzusetzen.
50
Übermitteln Sie keine vertraulichen Daten an den Client
Vertrauliche Daten sollten den Server nicht verlassen. Mit Hilfe des
Session-Managements können sie dem entsprechenden Benutzer
zugeordnet werden. Speichern Sie keine vertraulichen Informationen in Cookies, Formularfeldern oder URL-Parametern.
Schützen Sie vertrauliche Daten
Schützen Sie alle vertraulichen Daten in einer Session durch
Verschlüsselung. Nähere Informationen hierzu in Kapitel 5.6
„Verwendung von Kryptographie“.
Schützen Sie vertrauliche Seiten
Nutzen Sie Authentisierungsverfahren, um vertrauliche Seiten zu
schützen. Unterteilen Sie ihre Ressourcen in öffentliche und
geschlossene Bereiche und schützen Sie den AuthentisierungsToken, der für den Zugriff auf den geschlossenen Bereich eingesetzt
wird.
Trennen Sie Session-Token und Authentisierungs-Token
Verwenden Sie einen Authentisierungs-Token, um den Zugriff auf
die geschlossenen Seiten / Ressourcen Ihrer Anwendung zu verwalten. Schützen Sie den Token mit Hilfe von SSL und starken
Verschlüsselungsverfahren. Beschränken Sie den Einsatz des Tokens
auf HTTPS-Verbindungen.
Verwenden Sie einen Session-Token, um personalisierte Informationen während der gesamten Benutzer-Session zu verwalten.
Ein gestohlener Session-Token allein kann nicht verwendet werden,
um auf die geschlossenen Seiten zuzugreifen. Ziehen Sie vertrauliche Daten nur dann aus einer Session, wenn ein Authentisierungstoken vorhanden ist.
51
Verwenden Sie eine sichere Länge für den Session-Token
Eine minimale Länge von 128 Bit schützt vor dem Erraten des
Tokens während einer authentisierten Session.
Trennen Sie öffentliche und geschlossene Bereiche
Wenn Ihre Anwendung öffentliche Seiten über HTTP unterstützt,
schützen Sie die geschlossenen Seiten mit SSL (HTTPS). Nehmen Sie
die erforderlichen Einstellungen vor, um zu verhindern, dass ein
Session-Cookie unverschlüsselt übertragen wird, wenn ein Benutzer
vom geschlossenen in den öffentlichen Bereich wechselt. Unterscheiden Sie zwischen Session- und Authentisierungs-Cookie wie
oben beschrieben; ordnen Sie die öffentlichen und geschlossenen
Seiten unterschiedlichen Verzeichnissen zu und konfigurieren Sie
die Zugriffsrechte entsprechend.
5.8
Code Review
Code Reviews sind eine gute Möglichkeit, die Qualität Ihres Codes
im Allgemeinen und die Sicherheit Ihrer Anwendung im Besonderen
zu verbessern. Anwendungssicherheit muss als kontinuierlicher
Prozess und nicht als punktuelle Maßnahme verstanden werden.
Daher sollten Code Reviews als integraler Bestandteil des Entwicklungsprozesses regelmäßig anberaumt werden.
Ein Code Review ist meist effektiver, wenn er von Entwicklern
durchgeführt wird, die bisher nicht an dem Projekt beteiligt waren.
Während des Programmierens konzentrieren sich Entwickler
üblicherweise auf die Funktion der Anwendung; ein externer und
unvorbelasteter Prüfer kann den Fokus hingegen auf Qualität und
Sicherheit legen.
52
Die folgenden Aspekte sollten bei einem sicherheitsbezogenen
Review berücksichtigt werden:
I Einfachheit: Unnötige Komplexität führt zu Problemen in der
Wartung und zu fehleranfälligem Code.
I Modularität: Teilen Sie Ihre Anwendung möglichst in mehrere
Module auf, die klar definierte Schnittstellen haben. So können
die Module einzeln auf Funktion und Sicherheit getestet werden. Testen Sie alle möglichen Benutzereingaben auf ihre
Praxistauglichkeit.
I Fehlerbehandlung: Werden mögliche Fehler und Ausnahmen
korrekt behandelt? Wie fährt eine Methode fort, nachdem ein
Fehler aufgetreten ist?
I Sicherheit: Entspricht die Implementierung den Sicherheitsanforderungen, die in diesem Leitfaden beschrieben werden?
I Dokumentation: Entspricht die Dokumentation dem aktuellen
Stand der Implementierung?
I Tests: Sind die Tests dem aktuellen Stand der Implementierung
angemessen? Genügen die Tests den Anforderungen des Prozesses?
53
6
Sicheres Testen
Wenn Sicherheit als Anforderung im Entwicklungsprozess definiert
wird, wird sie automatisch auch in das Test- und Akzeptanzverfahren aufgenommen.
Ziel der Tests ist es, einerseits die korrekte Implementierung von
Sicherheitsmechanismen in der Anwendung zu überprüfen, andererseits aber auch, mögliche Sicherheitslücken aufzudecken.
6.1
White Box Test
Die Prüfung der korrekten Implementierung von Sicherheitsmechanismen ist den Funktionstests sehr ähnlich. Wie beim
Erstellen von Modultests für betriebswirtschaftliche Funktionen
muss auch hier geprüft werden, ob eine Funktion/Methode/
Schnittstelle eine bestimmte Menge von Eingabewerten (und nur
diese) annimmt, die korrekten Ergebnisse liefert und sich erwartungsgemäß verhält.
Der zweite Teil, das Testen auf Sicherheitslücken, ist komplexer. Hier
soll die Qualität von Sicherheitsmaßnahmen beurteilt werden, man
kann jedoch nur annehmen, welchen Bedrohungen die Anwendung
wirklich ausgesetzt sein wird. Solche Tests können niemals den endgültigen Beweis für die Sicherheit einer Anwendung liefern.
Die folgenden Bereiche sollten getestet werden, um die größtmögliche Anzahl von Bedrohungen abzudecken:
Authentisierung
Testen Sie, ob Ihr Anmeldeverfahren
I schwache Passwörter ablehnt.
I die Passwortrichtlinie umsetzt.
I Brute-Force-Angriffe erkennt.
54
I
I
I
I
die Anzahl von Anmeldeversuchen in einem bestimmten
Zeitrahmen limitiert.
die Gefahr von Denial-of-Service-Angriffen minimiert.
das lokale Cachen von Passwörtern verhindert.
Fehlermeldungen ausgibt, die Angreifern interne Informationen
in die Hände spielen.
Session-Management
Testen Sie, ob
I Time-Out-Zeiten für Ihre Sessions sinnvoll gewählt sind und
funktionieren.
I eine abgelaufene Session eine definierte Abmeldung zur Folge
hat.
I ein Speicher auf Client-Seite (z. B. ein Cookie) verwendet wird,
um unverschlüsselte vertrauliche Daten zu speichern.
I Benutzernamen und Passwörter im Klartext an den Server
übermittelt werden.
Eingabeprüfung
Testen Sie das Verhalten Ihrer Anwendung durch folgende Eingaben:
I Daten, die die erwartete Eingabelänge überschreiten (Test auf
Buffer Overflows).
I Daten, die HTML-Tags enthalten (auch in verschlüsselter Form).
I Daten, die SQL-Meta-Syntax enthalten (auch in verschlüsselter
Form).
I Daten, die unerwartete Zeichen / Formate enthalten.
Säuberung von Ausgabewerten
Testen Sie, ob
I eine falsche Anzahl von Parametern oder falsche Parametertypen in einem Serviceaufruf, Funktionsaufruf, URL-Aufruf usw.
zu einer Fehlerausgabe führen, die dem Angreifer möglicherweise weitere Hinweise gibt.
55
I
I
HTML-Seiten interne Informationen wie IP-Adressen,
E-Mail-Adressen oder Kommentare enthalten.
der Client unabhängig von internen Fehlern eine
Standardfehlermeldung erhält.
Beim Erstellen eines Testplans für eine komplexe Anwendung sollte
der Schwerpunkt auf die Komponenten gelegt werden, die am
einfachsten angegriffen werden können. Zu diesem Zweck sollten
Sie für jede Komponente eine Rangliste der potentiellen Risiken
anlegen.
6.2
Black Box Test
Als zusätzlicher Test bietet sich ein Angriff auf die Anwendung an.
Dies sollte mindestens einmal vor der Inbetriebnahme des Systems
durchgeführt werden. Ein automatisierter Sicherheits-Scan kann
ebenfalls helfen, Sicherheitslücken zu finden. Zu diesem Zweck
sind eine Reihe von Produkten erhältlich. Sie nutzen bekannte
Angriffsmethoden und Techniken wie SQL Injections oder Cross-Site
Scripting.
Leider können solche Produkte keine logischen Fehler in Anwendungen finden; es ist daher unabdingbar, einen Sicherheitsexperten
zu Rate zu ziehen, um die Tests effektiv durchzuführen.
6.3
Zertifizierung
Für bestimmte Bereiche oder Kunden ist eine Sicherheitszertifizierung notwendig. Ist dies nicht der Fall, sollte man genau abwägen, ob der Nutzen den Aufwand rechtfertigt.
Ähnlich wie beim Qualitätsmanagement gibt es auch im Bereich
der Sicherheit eine große Anzahl von Standards und Organisationen, die sich mit Zertifizierungsfragen beschäftigen. Man kann sie
in zwei Bereiche unterteilen: Die Zertifizierung des Softwareentwicklungsprozesses und die Zertifizierung der Software als Produkt.
56
7
Auslieferung und
Wartung
Auch in der abschließenden Phase des Entwicklungsprozesses finden sich sicherheitsrelevante Aspekte. Hier sollen nur die wichtigsten Themen kurz angesprochen werden; eine umfassende
Behandlung dieses Themas finden Sie in der entsprechenden
Fachliteratur.
Eine der einfachsten Möglichkeiten für Hacker ist das Einschleusen
von bösartigem Code in ein ausgeliefertes Software-Release. Sie
schaffen sich so eine Hintertür für Cross-Site-Scripting-Angriffe
oder das Ausspionieren von Authentisierungsdaten. Mit Hilfe von
Hash-Werten und Zertifikaten können Sie sicherstellen, dass die
Version, die Sie exportiert haben, auch wirklich die Version ist, die
Ihre Kunden am Ende erhalten.
7.1
Sichere Standardkonfiguration
Besondere Vorsicht ist bei der Benutzerverwaltung, externen
Schnittstellen und der Konfiguration des Session-Managements
angebracht. Achten Sie darauf, dass potentielle Sicherheitslücken in
Form von „offenen Türen”, die zu Entwicklungs- und Testzwecken
benötigt wurden (etwa Spezialbenutzerkonten, beschleunigte
Authentisierungsverfahren oder besondere Berechtigungsprofile)
vor Auslieferung geschlossen werden.
Wie die vorhergehenden Kapitel zeigen, können bestimmte
Datenausgaben für Tests und Debugging sinnvoll sein. Sie können
sich auch für einen Angreifer durchaus als hilfreich erweisen –
prüfen Sie daher Fehlermeldungen und andere Ausgaben auf
allzu detaillierte systeminterne Informationen.
57
Software sollte mit einer sicheren Standardkonfiguration ausgeliefert werden. Beschreiben Sie diese Konfiguration in Ihrem Anwendungshandbuch. Weisen Sie auch die Benutzer Ihrer Anwendung
auf spezielle Sicherheitsfunktionen hin. Fragen Sie den Administrator bei der Installation, welche Module Ihrer Software er benötigt, damit er nicht benötigte Teile nicht installieren muss.
7.2
I
I
I
I
I
I
Wartungsplan
Beschreiben Sie die Prozesse für sicherheitsrelevante Wartungsaufgaben im Handbuch.
Prüfen Sie Protokolle regelmäßig auf Sicherheitslücken.
Prüfen Sie in bestimmten Zeitabständen, ob alle Benutzer noch
die ihnen zugeteilten Rechte benötigen.
Stellen Sie fest, ob ausreichend Speicherplatz für Datenbank
und Protokolldateien vorhanden ist. Falls Stoßzeiten festgestellt
werden, prüfen Sie, ob die Gefahr einer Überlastung besteht.
Erarbeiten Sie ein angemessenes Backup-Konzept.
Alle ein bis zwei Jahre sollten Sie einen Black Box Test durchführen. So können Sie feststellen, ob Ihre Anwendung durch
neue Angriffsvarianten gefährdet ist.
7.3
Patch-Management und Bug-Fixing
Vermeiden Sie, dass die Sicherheit Ihrer Anwendung der Funktionalität zum Opfer fällt. Sicherheit muss als Qualität angesehen werden, der die gleiche Bedeutung wie etwa einem korrekten Berechnungsverfahren zukommt.
Ob Ihr Patch-Zyklus bereits im Detail geplant ist oder ob es sinnvoller erscheint, einen Security-Patch erst mit dem nächsten funktionalen Patch auszuliefern: Machen Sie sich bewusst, dass im Rennen
mit den Angreifern Minuten zählen können. Das Bekanntwerden
einer offenen Sicherheitslücke ist unter Umständen schnell erheblich teurer als das Verteilen eines außerplanmäßigen SicherheitsPatches.
58
Andererseits kann ein ungenügend getesteter Patch zu schlechter
Performance führen. Planen Sie daher vor der Auslieferung ausreichend Zeit für einen Funktions- und Sicherheitstest ein.
Für die Zertifizierung des Prozesses müssen die Sicherheitsanforderungen ohne Berücksichtigung anderer entwicklungstechnischer
Gegebenheiten in allen Abschnitten des Software-Lebenszyklus
definiert und umgesetzt werden.
Die Zertifizierung des fertigen Produkts ist weniger komplex.
Die speziellen Sicherheitsanforderungen an ein Produkt werden
geprüft; üblicherweise werden mit Hilfe eines Black Box Tests alle
sicherheitsrelevanten Punkte getestet.
Unabhängig davon, welche Art der Zertifizierung angestrebt wird,
sollten Experten zu Rate gezogen werden.
59
8
Zusammenfassung
Marktanalysen prophezeien dem Bereich der Anwendungssicherheit ein starkes Wachstum. Dieser Leitfaden lässt erkennen, welche
Bedeutung der sicheren Anwendungsentwicklung, besonders vor
dem Hintergrund einer zunehmend Web-basierten Anwendungswelt, heute bereits zukommt. Der Schutz vor Angriffen auf die
Verfügbarkeit, Integrität und Vertraulichkeit von Daten muss in
allen Phasen des Entwicklungsprozesses konsistent berücksichtigt
werden.
Als nächste Schritte nach der Lektüre dieses Pocketseminars könnten etwa das Erstellen Ihrer eigenen Checklisten oder die Definition
anderer organisatorischer Maßnahmen auf dem Programm stehen.
Zweifellos sinnvolle Maßnahmen, doch im Mittelpunkt Ihrer Überlegungen sollten die an Ihrem Entwicklungsprojekt beteiligten
Personen stehen. Mit ihnen steht und fällt jede Sicherheitsmaßnahme; sie müssen erkennen, wie wichtig das Thema Sicherheit bei
der Entwicklung von Software ist. Führen Sie regelmäßig
Workshops durch, besprechen Sie reale Vorfälle mit Ihrem Team –
nicht, um Schuldzuweisungen vorzunehmen, sondern um das
Lernen an praktischen Beispielen zu ermöglichen.
60
9
Abkürzungen
ACL
ARP
CA
CRL
CSS
DBMS
DES
DNS
DoS
DSA
FIPS
FTP
HMAC
HTML
HTTP
HTTPS
ICMP
ID
IDS
IPSec
J2EE
LAN
LDAP
NetBIOS
NNTP
OS
RIP
RSA
SDK
SHA
SMB
Access Control List
Address Resolution Protocol
Certification Authority
Certificate Revocation List
Cross-Site Scripting
Data Base Management System
Data Encryption Standard
Domain Naming System
Denial of Service
Digital Signature Algorithm
Federal Information Processing Standard
File Transfer Protocol
Hash Message Authentication Code
Hyper Text Markup Language
Hyper Text Transfer Protocol
Hyper Text Transfer Protocol Secure
Internet Control Message Protocol
Identifier
Intrusion Detection System
Internet Protocol Security
Java 2 Enterprise Edition
Local Area Network
Lightweight Directory Access Protocol
Network Basic Input/Output System
Network News Transfer Protocol
Operating System
Routing Information Protocol
Rivest, Shamir and Adleman
Software Development Kit
Secure Hash Algorithm
Server Message Block (protocol)
61
SMTP
SOA
SOAP
SQL
SSL
TCP/IP
TFTP
UDP
URI
URL
VLAN
VPN
W3C
WebDAV
XSS
Simple Mail Transfer Protocol
Service-Oriented Architecture
Simple Object Access Protocol
Structured Query Language
Secure Sockets Layer
Transmission Control Protocol / Internet Protocol
Trivial File Transfer Protocol
User Datagram Protocol
Uniform Resource Identifier
Uniform Resource Locator
Virtual Local Area Network
Virtual Private Network
World Wide Web Consortium
Web based Distributed Authoring and Versioning
Cross-Site Scripting
62
10 Abbildungsverzeichnis
Abbildung 1: Sicherheit bei der Softwareentwicklung . . . . . . . . 15
Abbildung 2: Sichere Softwarearchitektur . . . . . . . . . . . . . . . . . 23
Abbildung 3: Rollenbasierter Zugriff . . . . . . . . . . . . . . . . . . . . . 31
Abbildung 4: Zugriff über Impersonation . . . . . . . . . . . . . . . . . . 31
Abbildung 5: Zugriff über eine Pool-Identität . . . . . . . . . . . . . . 32
63
11 Referenzen
I
Microsoft
Microsoft Security Developer Center:
http://msdn.microsoft.com/security
Microsoft Security Developer Center Germany:
http://www.microsoft.com/germany/msdn/security/default.mspx
I
OWASP
The Open Web Application Security Project:
http://www.owasp.org
I
Vulnerabilities
SANs TOP 20 List:
http://www.sans.org/top20
CERT (Computer Emergency Response Team):
http://www.cert.org
SecurityFocus:
http://www.securityfocus.com
I
World Wide Web Security FAQ
http://www.w3.org/Security/faq/www-security-faq.html
64
12 Index
Ablauffrist für Passwörter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Abstreitbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34,50
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 12, 13, 39, 40
Angriffsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11, 12, 56
Angriffssimulationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Angriffsvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41, 58
Anmeldeversuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 39
Anwendungsarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Anwendungskonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 20
Ausfallzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Auslieferung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 13, 57, 59
Authentisierung . . . . . . . . . . . . . 19, 20, 21, 25, 26, 27, 31, 50, 54
Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 40, 58
Benutzereingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 22, 32, 47
Benutzergruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Benutzerkonto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 22, 57
Berechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 28, 30
Betriebssystem-kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
biometrische Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Black Box Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Brute-Force-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 50, 54
Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Bug-Fixing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 58
Bundesamt für Sicherheit in der Informationstechnik . . . . . . . . 34
65
Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . . 50, 61
CIA-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Code Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 52
Command Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Connection Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28, 29
Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 33, 35, 41, 52, 55
Cross-Site Malicious Content . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Cross-Site Scripting . . . . . . . . . . . . . . . 10, 22, 41, 56, 61, 62, 66
Dateizugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Datenbankzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 39
Dateneingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 22
Datenklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 36, 57
Denial-of-Service . . . . . . . . . . . . . . . . . . . . . . . . 10, 25, 36, 37, 55
DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 61
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 11, 13, 18, 40, 41
Design Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 40
Digital Signature Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 34, 61
Distributed Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Einfachheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Eingabeprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 22, 43, 55
Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 53
Fehlermeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 37, 56
Fehlerprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36, 37
Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 11
Formularfeldparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 61
66
Gerätedateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
geschlossene Bereiche . . . . . . . . . . . . . . . . . . . . . . 27, 50, 51, 52
Hash-based Message Authentication Code . . . . . . . . . . . . . . . . 34
Hash-Wert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 55, 56, 61, 64
HTTP . . . . . . . . . . . . . 20, 24, 26, 27, 33, 34, 35, 41, 47,52, 61, 64
HTTP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 41
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 47, 51, 52, 61
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Impersonation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 63
Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 40, 60
Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intrusion-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31, 32, 36, 38, 61
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42, 44
Kodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 41
Konto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 38
Kryptographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 48, 51
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45, 61
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28, 38
Modularität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Netzwerkzugang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
NNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
öffentlicher Bereich . . . . . . . . . . . . . . . . . . . . . . . . . 27, 50, 51, 52
67
Parametermanipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 24
Passwörter . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 26, 32, 37, 54, 55
Passwortrichtlinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15, 26, 54
Patch-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 58
Pool-Identität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30, 63
Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
positives Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Prinzip der minimalen Rechtevergabe . . . . . . . . 18, 19, 31, 37, 38
Produktivbetrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 36
Public-Key-Infrastrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Quoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Reguläre Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Remote-Administration . . . . . . . . . . . . . . . . . . . . . . . . . 30, 31, 38
Replay-Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 21, 28, 29, 38
Revisionsbelege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Rivest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 61
Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Salted Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Sammelrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Säuberung von Ausgabewerten . . . . . . . . . . . . . . . . . . . . . . . . 55
Schadensbegrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 26
Schlüssellänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 50
Secure Hash Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 61
Security by Obscurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Service-oriented Architectures (SOA) . . . . . . . . . . . . . . . . . . . . 21
Session . . . . . . . . . . 20, 21, 24, 35, 36, 41, 42, 50, 51, 52, 55, 57
68
Session Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Session-Management . . . . . . . . . . . . . . . . . . . . . . . 21, 35, 50, 55
Sichere Standardeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 19
Sicherheitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Sicherheitsanforderungen . . . . . . . . . . . . 9, 14, 15, 25, 34, 53, 59
Sicherheitsbewusstsein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Sicherheitsgrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15, 16
Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 13
Sicherheitslücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Sicherheitsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 14
Smartcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 62
Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 22, 42, 45, 46, 55, 56, 62
SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 22, 42, 45, 56
Stack Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Standardkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 13, 57, 58
symmetrische Schlüssel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Systemwiederherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Systemzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 13, 54, 55, 56, 58
Thread Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Time-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51, 52
TripleDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Überlastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20, 58
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
URI/URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41, 46, 47
69
Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 22, 60
Versagensfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Verschlüsselung . . . . . . . . . . . . . 21, 26, 31, 33, 34, 42, 48, 49, 51
Vertrauensbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30
vertrauliche Daten . . . . . . . . . . . . . . . . . 24, 27, 32, 33, 37, 51, 55
Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 60
Virenscanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
VIV-Dreieck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11, 13, 23, 53, 57
Wartungsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 58
Web-Anwendungen . . . . . . . . . . . . . . . . 9, 11, 20, 35, 36, 42, 44
WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Wertebereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43, 44
White Box Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Zeitstempeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 31, 49, 50
Zertifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56, 59
Zufallszahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48, 50
Zugriff über Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Zugriffsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14, 29, 47, 52
70
Das SAP Pocketseminar
„Sicheres Programmieren“
Die Entwicklung leistungsfähiger und sicherer Software ist eine
anspruchsvolle und zunehmend komplexe Aufgabe. Alle
Softwareentwickler stehen bei der Programmierung von
Software und Webapplikationen vor der Herausforderung, mit
der schnellen Aufdeckung neuer Angriffsmöglichkeiten auf
Software und Systeme Schritt zu halten.
Microsoft und SAP haben sich deshalb verpflichtet, Softwareentwicklern und Studenten an deutschen Hochschulen ihre langjährigen Erfahrungen und die daraus resultierenden Konzepte
zur sicheren Software-Entwicklung und zum Umgang mit
Sicherheitsschwachstellen in Form von Veranstaltungsreihen an
Universitäten und in Form von Entwicklertreffen im Dialog zu
vermitteln und die Ergebnisse zu publizieren.
Dieser Leitfaden soll für Software-Bauer jeder Art (Architekten,
Programmierer, Tester usw.) eine erste, übersichtliche Hilfestellung geben, was beim Bau von sicheren Software-Applikationen zu bedenken ist. Das Werk ist entstanden anlässlich der
Initiative „Deutschland sicher im Netz“ im Jahr 2005, und es hat
den Anspruch, die internen Richtlinien von Microsoft und SAP
auf wenigen Seiten verständlich und allgemein wiederzugeben.
Bestandteil des Handlungsversprechen „Sichere
Programmierung“ in Zusammenarbeit mit
www.sicher-im-netz.de