Der SDL am Beispiel eines Gästebuchs, Teil 6
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht weiter. In der ersten Phase haben Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert, und in der zweiten die nötigen Anforderungen an die Webanwendung festgelegt. Dann kam Phase 3, Design. Dazu haben ich Ihnen erklärt, wie Sie theoretisch ein Bedrohungsmodell erstellen können und gezeigt, wie das Bedrohungsmodell für das Beispiel entwickelt wird. Danach galt es, die dadurch identifizierten Bedrohungen zu minimieren. Das ist alles ziemlich aufwendig und unübersichtlich. In dieser Folge zeige ich Ihnen für Webanwendungen eine
Vereinfachung der Bedrohungsmodellierung
Die Modellierung lässt sich im Fall von Webanwendungen stark vereinfachen. Sie kennen ja den alten Grundsatz der Websicherheit "Traue nie dem Client". Etwas abgewandelt wird daraus "Traue keinen Daten von Dritten": Alle Daten, die Sie nicht selbst prüfen, können potentiell bösartig sein. Was im Umkehrschluss bedeutet, dass Sie alle Daten, die Sie von Dritten erhalten, auf mögliche Angriffe prüfen müssen. Und dabei sind die "Dritten" nicht nur die Benutzereingaben, sondern auch z.B. von anderen Servern gelieferte Daten. Ggf. müssen Sie auch alle selbst gespeicherten Daten, auf die außer der eigenen auch eine weitere Anwendung zugreifen kann, entsprechend prüfen.
Für Webanwendungen lässt sich die Bedrohungsmodellierung also vereinfachen:
- Für jeden Parameter, der Daten von Dritten aufnimmt, STRIDE durchgehen
- Dafür eine Liste mit Angriffen aufstellen (und aktuell halten!) und diese durchgehen. Vor allem beim Tampering hilft das ungemein, um den Überblick zu behalten
- Sofern vorhanden die Authentifizierung und Autorisierung absichern
Ein (ggf. nur virtuelles) Formular wie in Tabelle 1 kann dabei helfen, den Überblick zu behalten. Für jedes Skript muss das Formular für jeden von Dritten stammenden Parameter ausgefüllt werden.
Skript: _________________________________ |
Parameter: _________ |
|
Kategorie | Angriffe/Schwachstellen | Schutzmaßnahmen |
Spoofing | ||
Tampering | ||
Repudiation | ||
Information Disclosure | ||
Denial of Service | ||
Elevation auf Privilege |
Tabelle 1: Das "STRIDE-Formular"
Eine (nicht vollständige) Liste mit Angriffen für den Punkt "Tampering" sieht z.B. so aus:
- Zustandsbasierte Angriffe
- Cookie Poisoning
- URL Jumping
- Session Hijacking
- Session Fixation
- ...
- Angriffe über Benutzereingaben
- Cross-Site Scripting/XSS (reflektiert, persistent, DOM-basiert)
- SQL Injection, SQL Injection 2. Ordnung
- Directory Traversal
- Local und Remote File Inclusion
- File Uploads
- OS Command Injection
- Scriptcode Injection
- XPath Injection
- SOAP Injection
- SMTP Injection
- LDAP Injection
- Pufferüberlauf-Schwachstellen
- Integer-Schwachstellen
- Formatstring-Schwachstellen
- ...
- Angriffe auf die
Authentifizierung
und Autorisierung
- SQL Injection zum Umgehen der Authentifizierung
- Brute-Force-Angriffe
- Angriffe auf die verschiedenen Funktionen der Authentifizierung: Passwortänderung, Passwort-Reset, "Remember me", ...
- "User Impersonation" (fällt ggf. auch unter Spoofing oder Elevation of Privilege)
- Cross-Site Request Forgery (CSRF)
- Unsichere Zugriffe
- ...
- Sonstiges
- DoS- und DDoS-Angriffe (das D in STRIDE)
- Unsicherere Kryptographie (z.B. ungesalzene Hash-Werte, normale Hashfunktion statt Passworthashfunktion)
- Angriffe auf den Presentation Layer
- Clickjacking
- HTTP Response Splitting
- HTTP Request Smuggling
- ...
Das sieht nach mühsamer Erbsenzählerei aus? Das ist es im Grunde auch. Aber nur so können Sie sicher sein, alle möglichen Angriffe wirklich berücksichtig zu haben. Aber keine Angst, es sieht schlimmer aus, als es ist. Für die meisten Angriffe können Sie einen mehr oder weniger großen Teil der Angriffe sofort streichen.
Wird ein Parameter nicht für SQL-Abfragen verwendet, ist natürlich keine SQL Injection möglich, das gleiche gilt entsprechend für alle Injection-Angriffe. Und wie Sie hier beim Gästebuch gesehen haben fallen teilweise auch Kategorien komplett weg. Wie z.B. "Elevation of Privilege", wenn es gar keine Privilegien gibt, die sich ein Angreifer verschaffen könnte. Sie werden am Ende also viele Formulare haben, in denen nur wenige Angriffe eingetragen sind.
Und bei den bereits im "Formular" berücksichtigten Schutzmaßnahmen wird es dann noch einfacher, da sie natürlich nur dort Schutzmaßnahmen ermitteln müssen, wo es überhaupt Angriffe bzw. Schwachstellen gibt.
Sie können auch auf die Bedrohungsmodellierung für die einzelnen Anwendungen verzichten und das Ganze quasi aus der Gegenrichtung angehen. Wie, erkläre ich in der nächsten Folge.
Kategorien: Grundlagen
Trackbacks
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 7
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 8
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 9
Vorschau anzeigen