Skip to content

Der SDL am Beispiel eines Gästebuchs, Teil 5

Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die fünfte Runde. 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 haben ich Ihnen erklärt, wie Sie in der dritten Phase, Design, theoretisch ein Bedrohungsmodell erstellen können und gezeigt, wie das Bedrohungsmodell für das Beispiel entwickelt wird. Sie wissen ja: Gefahr erkannt, Gefahr gebannt. Jedenfalls fast. Denn als nächstes gilt es, die Bedrohungen zu minimieren.

Minimierung der Bedrohungen

Sie müssen nun prüfen, ob sich die möglichen Bedrohungen bündeln lassen. Sind Bedrohungen über mehrere Komponenten verstreut, müssen Sie sie an allen diesen Stellen abwehren. Können Sie sie in einer oder wenigen Komponenten bündeln, müssen Sie nur diese schützen.

Mit der Bündelung von Bedrohungen sieht es beim Beispiel-Gästebuch schlecht aus, siehe Abbildung 1. Die Anwendung ist so minimal, dass sie sich nicht weiter zusammenschrumpfen lässt. Jedenfalls so lange man nicht auf die Speicherung der E-Mail- und IP-Adressen verzichtet, was auch die Funktion zur Abfrage aller Daten des Eintrags durch den Administrator und damit auch den privilegierten Administrator-Benutzer obsolet macht.

In Ihrer Webanwendung haben Sie vielleicht mehr Glück bei der Suche nach Verbesserungen.

Das Ergebnis der Bedrohungsmodellierung
Abb. 1: Das Bedrohungsmodell

Danach müssen für alle im STRIDE-Modell erkannten Angriffe Gegenmaßnahmen festgelegt werden. Gibt es keine Möglichkeit, einen Angriff zu verhindern, müssen seine möglichen Folgen minimiert werden. Z.B. ist es nicht möglich, einen DDoS-Angriff, der die Überlastung des Webservers zum Ziel hat, zu verhindern. Es ist aber möglich, seine Folgen z.B. durch das Bereitstellen entsprechender Rechenleistung oder das Abweisen von bestimmten Request zu mildern.

Idealerweise werden die möglichen Angriffe schon im Vorfeld verhindert, wo das nicht möglich ist, müssen sie abgewehrt werden. Los geht es wieder mit dem Eintragen des Gästebucheintrags:

  • Spoofing:
    Ob die übermittelte IP-Adresse gefälscht wurde lässt sich nicht feststellen.
  • Tampering:
    Alle Parameter müssen auf mögliche SQL-Injection- und XSS-Angriffe geprüft bzw. möglicher Schadcode entfernt werden.
    • $titel, $eintrag, $name:
      Zur Abwehr von SQL-Injection-Angriffen sollte die Eingabe über ein Prepared Statement mit parametrisierten Aufruf eingetragen werden. Ist das nicht möglich, muss sie zumindest escaped werden.
      Bei der Abwehr von XSS-Angriffen wird davon ausgegangen, dass der Eintrag kein HTML enthalten darf, enthaltene HTML-Tags können also einfach ausgefiltert werden. Soll HTML erlaubt sein, müssen alle potentiell gefährlichen Tags und Attribute ausgefiltert oder eine andere Auszeichnungssprache wie BBCode verwendet werden.
    • $link: Der URL kann entweder wie $titel, $eintrag und $name behandelt oder auf seine Korrektheit geprüft werden.
    • $mail: Prinzipiell kann die E-Mail-Adresse zur Abwehr von SQL-Injection und XSS ebenfalls wie die anderen Parameter behandelt werden, es bietet sich aber an, sie auf Korrektheit zu prüfen. Damit entfällt eine sonst nötige Prüfung auf einen möglichen SMTP-Injection-Angriff.
    • $_SERVER['REMOTE_ADDR']: Die IP-Adresse kann auf ihre Korrektheit geprüft werden. Dabei muss ggf. darauf geachtet werden, dass sowohl IPv4- als auch IPv6-Adressen berücksichtigt werden. Dann sind weder SQL-Injection- noch XSS-Angriffe möglich.
  • Denial of Service:
    Alle Daten sollten vor einer möglichen Prüfung auf ihre Größe geprüft und überlange Eingaben verworfen oder entsprechend gekürzt werden.
    Ein CAPTCHA kann verhindern, dass das Gästebuch automatisch mit einer großen Anzahl unsinniger Einträge (über)füllt wird.

Kommen wir zur Abfrage der Daten, bei der nur die ID zur Auswahl des Eintrags manipuliert werden kann:

  • Tampering:
    Die ID ist per Definitionem eine Zahl, kann also einfach in den entsprechenden Wertebereich umgewandelt werden. Dann ist weder SQL-Injection noch XSS möglich.
  • Information Disclosure:
    Falls die Einträge moderiert werden und erst nach einer Freischaltung durch den Administrator zugänglich sind, ist zu prüfen, ob der angeforderte Eintrag freigegeben wurde.
  • Denial of Service:
    Ein CAPTCHA kann DoS-Angriffe durch eine große Anzahl schnell aufeinander folgender Abfragen mit unterschiedlichen IDs erschweren.

Und schon kommen wir zum letzten Punkt: Der Abfrage der erweiterten Einträge durch einen Administrator:

  • Spoofing:
    Die Authentifizierung muss so abgesichert werden, dass ein Angreifer sich nicht als Administrator ausgeben kann.
  • Tampering:
    Die ID kann in einen Zahlenwert umgewandelt werden, s.o..
  • Denial of Service:
    Ein CAPTCHA kann DoS-Angriffe durch eine große Anzahl schnell aufeinander folgender Abfragen mit unterschiedlichen IDs erschweren.
  • Elevation of Privilege:
    Wie beim Spoofing muss die Authentifizierung und ggf. die Session-Verwaltung so abgesichert werden, dass ein Angreifer sich nicht als Administrator ausgeben kann. Die Formulare im Administrationsbereich müssen gegen CSRF-Angriffe geschützt werden.

Damit sind wir mit der Ermittlung alle Bedrohungen sowie ihrer Abwehr fertig. Zu guter Letzt muss das Ergebnis noch überprüft werden: Wurden alle möglichen Bedrohungen berücksichtigt? Hier "sieht man das", bei komplexeren Anwendungen ist aber eine gewissenhafte Prüfung aller Schritte angebracht. Das Ganze kann doch ziemlich unübersichtlich werden, so dass man leicht einen der STRIDE-Punkte oder auch einen Parameter oder eine Funktion übersieht.

In der nächsten Folge zeige ich Ihnen, wie sich die Bedrohungsmodellierung im Fall von Webanwendungen vereinfachen lässt.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 4

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die vierte Runde. Im ersten Schritt müssen Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informieren, und im zwe

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 6

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht weiter. Im ersten Schritt haben Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert, und im zweiten die nötig

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 7

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht weiter. Im ersten Schritt haben Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert, und im zweiten die nötig

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 8

Vorschau anzeigen
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&amp;o

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 9

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs hat die letzten beiden Phasen erreicht. Los ging es in der ersten Phase mit der Schaffung der nötigen Grundlagen für die sichere Entwicklung. In der zweiten Ph