Skip to content

Der SDL am Beispiel eines Gästebuchs, Teil 9

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 Phase wurden die nötigen Anforderungen an die Webanwendung festgelegt.

In der dritten Phase (Design/Entwurf) musst ein Bedrohungsmodell für die Anwendung entwickelt werden. Theoretisch sah das ziemlich schwierig aus, praktisch was es aber durchaus zu schaffen. Danach galt es, die dadurch identifizierten Bedrohungen zu minimieren. Die Bedrohungsmodellierung ist ziemlich aufwendig, lässt sich aber zumindest für Webanwendungen vereinfachen.

In der vierten Phase kommt dann endlich die Implementierung sowie die Vorbereitung der sicheren Default-Installation und -Konfiguration an die Reihe. In Phase 5 muss das alles dann noch mal kontrolliert werden, und dann ist die Anwendung endlich bereit für

Phase 6: Die Auslieferung

In Phase 5 evtl. gefundene Schwachstellen müssen Sie natürlich beheben. Wenn Sie keine Schwachstellen mehr finden ist die Anwendung bereit zur Auslieferung. Sie haben nun alles Machbare getan, um sie möglichst Schwachstellenfrei auszuliefern.

I.A. reicht das aber nicht, und es werden nach der Veröffentlichung Schwachstellen gefunden. Sie wissen ja: Es ist einfach nicht möglich, ein absolut fehlerfreies Programm zu entwickeln. Wenn man mal von ganz einfachen Fällen wie "Hello World" absieht, und natürlich denen, bei denen der formale Beweis der Fehlerfreiheit möglich ist. Gehen Sie also einfach davon aus, dass es Fehler gibt. Und manche Fehler lassen sich für Angriffe ausnutzen, und die nennt man dann bekanntlich Schwachstellen.

Damit Sie auf die angemessen reagieren können brauchen Sie zum einen einen Plan, den sog. Incident Response Plan: Wie wollen Sie reagieren, wenn eine Schwachstelle gefunden und privat gemeldet wird? Wie, wenn sie veröffentlicht wird? Wie, wenn es Angriffe darauf gibt? Und was tun Sie, wenn Angriffe bekannt werden, Sie die dabei ausgenutzte Schwachstelle aber noch gar nicht kennen? Dann brauchen Sie Hinweise darauf, wo sie nach der Schwachstelle suchen müssen, also z.B. die Logfiles angegriffener Installationen ihrer Anwendungen.

Was Sie dann auch brauchen sind die Quelltexte, Entwicklungsdokumentation etc., deren Archivierung deshalb auch zur Auslieferungsphase gehört: Erstellen Sie ein Archiv aller während der Entwicklung angefallenen Dokumente, damit Sie im Notfall darauf zugreifen können und nicht in einigen Jahren überlegen müssen, weshalb sie etwas genau so implementiert haben.

Und dann können Sie ihre Anwendung unter die Leute bringen und der Dinge harren, die da kommen könnten. In diesem Fall natürlich die Entdeckung von Schwachstellen oder Angriffen. Wenn es dazu kommt, greift die letzte Phase des SDL:

Phase 7: "Kommunikation"

Schwachstellen entstehen nicht, wenn sie gefunden werden, sondern wenn sie programmiert werden. Es gilt also sinngemäß "Ihre Anwendung, Ihr Fehler, Ihre Schwachstelle!", also akzeptieren Sie ihre Verantwortung dafür und versuchen Sie gar nicht erst, sie zu vertuschen.

Wenn eine Schwachstelle gefunden wird, sind Sie u.U. der letzte, der davon erfährt. Kaum jemand wird sich z.B. die Mühe machen, sich in Ihrem Forum zu registrieren, nur um eine Schwachstelle zu melden. Machen Sie das Melden von Schwachstellen einfach, eine entsprechende E-Mail-Adresse ist schnell eingerichtet und an passenden Stellen, z.B. dem Impressum oder der Kontaktseite Ihrer eigenen Website oder der der Webanwendung veröffentlicht.

Warten Sie nicht, bis die Schwachstelle zu Ihnen kommt. Beobachten Sie zumindest die Exploit-Database - nicht jeder, der eine Schwachstelle findet, meldet sie an die Entwickler der betroffenen Anwendung, selbst wenn die diese Meldung einfach machen.

Wird Ihnen eine Schwachstelle bekannt, informieren Sie die Benutzer (bevor es ein anderer tut). Veröffentlichen Sie eine entsprechende Meldung sowohl auf der Website der Anwendung als auch ggf. einer existierenden Mailingliste. Es empfiehlt sich, für diesen Zweck eine spezielle Mailingliste einzurichten. Wenn auf der dann nie Schwachstellen oder Sicherheitsupdates veröffentlicht werden müssen, ist das wunderbar, niemand wird sich über zu wenig Traffic beklagen.

Wichtig ist auch, dass Sie die Benutzer ausführlich informieren: Was kann passieren? Gibt es einen Workaround? Wann erscheint ein Patch?

Lassen Sie die Benutzer Ihrer Software nicht im Regen stehen. Sorgen Sie dafür, dass sie vor Schwachstellen und den darauf drohenden Angriffen gewarnt werden und beseitigen Sie die Schwachstellen so schnell wie möglich. Und wenn Sie irgendwann den Support für eine Version oder die komplette Anwendung einstellen wollen geben Sie auch das rechtzeitig bekannt, damit die Benutzer sich eine Alternative suchen können.

Das ist doch gar nicht so schwer, oder?

Sie sehen: Es ist gar nicht so schwer, bei der Entwicklung einer (Web)anwendung von Anfang an auf deren Sicherheit zu achten. Wie Sie diese Schritte am besten in Ihre Arbeitsweise integrieren, sofern Sie sie nicht sowieso schon berücksichtigen, können nur Sie selbst beurteilen. Und schon entwickeln Sie quasi automatisch sichere Webanwendungen.

Womit es in der nächsten Folge weitergeht habe ich noch nicht endgültig entschieden.

Carsten Eilers

>

        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Keine Trackbacks