Skip to content

Der SDL am Beispiel eines Gästebuchs, Teil 7

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 die dritte Phase, in der ich Ihnen erklärt habe, wie Sie theoretisch ein Bedrohungsmodell erstellen können und wie das Bedrohungsmodell für das Beispiel entwickelt wird. Danach galt es, die dadurch identifizierten Bedrohungen zu minimieren.

Die Bedrohungsmodellierung ist ziemlich aufwendig und unübersichtlich, lässt sich aber zumindest für Webanwendungen vereinfachen. Und dafür gibt es sogar noch eine weitere Möglichkeit.

Man kann es sich auch noch einfacher machen...

Sie können auch auf die Bedrohungsmodellierung für die einzelnen Anwendungen verzichten und das Ganze quasi aus der Gegenrichtung angehen. Dazu legen Sie zunächst fest, welche Angriffe Sie verhindern wollen, und danach, durch welche Schutzmaßnahmen dies geschehen soll.

Das könnte z.B. so aussehen, dass Sie festlegen, dass die Angriffe aus den aktuellen OWASP Top 10 sowie deren Vorgängern verhindert werden sollen, außerdem das darin nicht enthaltene Clickjacking.

Als Schutzmaßnahme legen Sie z.B. fest, dass zum Schutz vor SQL Injection entweder ein von Haus aus sicheres Framework verwendet werden muss oder alle Abfragen durch parametrisierte Aufrufe von Prepared Statements erfolgen müssen. Und zum Schutz vor Clickjacking muss jede Seite, die nicht in einen Frame geladen werden soll, sowohl einen Framebuster als auch einen passend gesetzten X-Frame-Options-Header enthalten. Usw. usf., so dass Sie am Ende eine Liste nötiger Schutzmaßnahmen erstellt haben. Und die müssen dann nur noch konsequent umgesetzt werden.

Der Nachteil dieses Ansatzes: Angriffe, die nicht berücksichtig wurden, werden auch nicht verhindert. Sie müssen daher darauf achten, dass die Vorgaben aktuell bleiben, sonst ist ihre Anwendung durch neu entdeckte Angriffe gefährdet.

Ein klassisches Beispiel für einen neuen Angriff ist das Clickjacking. Als das entdeckt wurde war keine Webanwendung davor sicher, wenn man mal davon absieht, dass die in manchen Anwendungen aus anderen Gründen vorhandenen Framebuster die Angriffe erschwerten. Erst nachdem die Gefahr bekannt war, konnten Gegenmaßnahmen entwickelt werden.

Und Sie müssen sich natürlich bewusst sein, dass die OWASP Top 10 eben nur die 10 größten Risiken für Webanwendungen sind und nicht die Auflistung aller möglichen Angriffe. Wenn Sie festlegen

"Alles, was jemals in den OWASP Top 10 war, wird verhindert"

ist das natürlich gleichbedeutend mit

"Alles, was nie in den Top 10 enthalten war, bleibt eine Gefahr"

Sie müssen Ihre Liste zu verhindernder Angriffe und Schwachstellen also soweit erweitern, bis sie mit dem verbleibenden Risiko leben können. Oder eben doch für jede Anwendung eine reguläre Bedrohungsmodellierung durchführen und danach die zu ergreifenden Schutzmaßnahmen festlegen.

Aber kommen wir zurück zum SDL. Auf den Entwurf folgt die Implementierung.

Phase 4: Implementierung

Bei der Implementierung müssen Sie einige Grundsätze beachten:

  • Verwenden Sie möglichst bewährte Lösungen. Neu- und/oder Eigenentwicklungen müssen Sie sorgfältig testen.
  • Ein wichtiger Punkt, der oft übersehen wird: Seien Sie konsequent. Wenn Sie sich für eine Lösung entschieden haben, bleiben Sie dabei.
    Ein Beispiel dazu: Um SQL Injection zu verhindern, können Sie die Eingaben entweder Escapen oder Prepared Statements verwenden. Mischen Sie nicht beide Lösungsansätze, bei späteren Änderungen besteht die Gefahr, mit dem falschen Ansatz weiterzuarbeiten und dadurch eine Schwachstelle zu erzeugen.
  • Versuchen Sie, die Schutzmaßnahmen möglichst zu bündeln und immer an der gleichen Stelle in den Skripten zu platzieren. Das macht die Kontrolle der Schutzmaßnahmen und mögliche Anpassungen einfacher.

Bei der Implementierung müssen Sie ansonsten nur den Ergebnissen des Bedrohungsmodells folgen: Alle ermittelten Schutzmaßnahmen müssen implementiert werden.

Oft werden Sie dabei weitere Funktionen und/oder Parameter einführen, z.B. wenn Sie eine eigene Authentifizierungsfunktion implementieren oder eine Session-Verwaltung einsetzen. Für diese neuen Funktionen und/oder Parameter müssen Sie dann wieder eine Bedrohungsmodellierung durchführen und deren Ergebnis bei der Implementierung berücksichtigen.

Ggf. können Sie nun schon die Implementierung prüfen. Einfacher ist es jedoch, erst noch die Default-Installation und -Konfiguration festzulegen und erst dieses Gesamtergebnis zu prüfen.

Die sichere Default-Installation und -Konfiguration ist das Thema der nächsten Folge.

Carsten Eilers

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

Trackbacks

Keine Trackbacks