Dipl.-Inform. Carsten Eilers

Ja, es muss. Aber es ist gar nicht so schlimm, wie es auf den ersten Blick aussieht. Denn der SDL enthält ja viele Schritte, die im Rahmen einer "unsicheren" Entwicklung sowieso gemacht werden. Es kommen lediglich jeweils ein paar zusätzliche Probleme hinzu, die berücksichtigt werden müssen. Dafür ist der SDL wie schon in der ersten Folge erwähnt sehr erfolgreich (Link zu archive.org, Microsoft hat seine Seiten mal wieder umsortiert):

• Das erste vollständig nach dem SDL entwickelte System war Windows Vista, in dem im ersten Jahr nach seiner Veröffentlichung 45% weniger Schwachstellen gefunden wurden als im ersten Lebensjahr von Windows XP: 119 Schwachstellen in XP und "nur" 66 Schwachstellen in Vista.
• Noch besser sieht es beim SQL Server aus: Während im "unsicher" entwickelten SQL Server 2000 in den drei Jahren nach der Veröffentlichung 34 Schwachstellen gefunden wurden, waren es im nach dem SDL entwickelten SQL Server 2005 ganze 3 - eine Reduzierung um 91%.

Wieso als Beispiel eine Webanwendung?

Der SDL wurde zwar mit Blick auf Desktop-Anwendungen und Betriebssysteme entworfen, aber es spricht nichts dagegen, ihn an die eigenen Bedürfnisse anzupassen, also auch an Webanwendungen. Und mit denen habe ich deutlich mehr zu tun als mit Desktop-Anwendungen oder Betriebssystemen. Warum sollte ich bei den Webanwendungen auf die Vorteile des SDL verzichten?

Grundlage des SDL sind wie schon in der ersten Folge erwähnt vier "Best Practices":

1. "Secure by Design" (Sicherheit als Entwurfsziel)
   Schon beim Entwurf des Programms wird seine Sicherheit berücksichtigt, z.B. indem mögliche Angriffe ermittelt und möglichst verhindert, zumindest aber erschwert werden.
2. "Secure by Default" (Sichere Default-Konfiguration)
   Egal wie sicher ein Programm auch entworfen und implementiert wird, es wird immer Schwachstellen enthalten. Daher müssen die Standardeinstellungen so gewählt werden, dass ein Angriff möglichst erschwert und seine Folgen gemindert werden. Im Fall von Webanwendungen sind die Datenbankzugriffe ein guter Kandidat für die sichere Default-Konfiguration: Wenn die Anwendung nur lesend auf die Datenbank zugreifen muss sollte der entsprechende Datenbankbenutzer auch nur Lese-Rechte erhalten. Und nur wenn Lesen und Schreiben erforderlich sind Lese- und Schreibrechte. Keinesfalls aber weitergehende Rechte, es sei denn, Sie möchten, dass irgendwann ein Cyberkrimineller die Konfiguration der Datenbank übernimmt.
3. "Secure by Deployment" (Sichere Default-Installation)
   Das fertige Programm wird so ausgeliefert, dass es möglichst sicher installiert und konfiguriert wird. Was bei Webanwendungen z.B. leicht übersehen wird ist das Löschen der Installationsskripte nach der erfolgreichen Installation. Bleiben die auf dem Server, könnte ein Angreifer die Installation erneut durchführen und dabei z.B. eigene Zugangsdaten setzen.
4. "Communications" ("Reden Sie über Schwachstellen!")
   Es bleibt nicht aus, dass im fertigen Programm Schwachstellen entdeckt werden. Wenn das passiert, müssen die Benutzer darüber informiert und Workarounds und Patches entwickelt und verteilt werden.

Der SDL ist keine Garantie für ein Schwachstellenfreies Programm, wie sie schon an den vielen "möglichst" oben und am Beispiel von Windows Vista sehen. Das soll er auch gar nicht sein, er soll "nur" dafür sorgen, dass das Programm bei der Auslieferung keine bekannten und damit vermeidbaren Schwachstellen oder Schwachpunkte enthält. Im Fall von Webanwendungen wären z.B. XSS oder SQL Injection solche Schwachstellen: Jeder Webentwickler sollte sie kennen und wissen, wie er sie verhindert (was gar nicht so schwer ist), trotzdem treten sie immer wieder auf.

Los gehts: Phase 1 - Training

Dann fangen wir mal an, den SDL auf Webentwicklungen zu übertragen. Die erste Phase des SDL ist das Training. Denn die Grundvoraussetzung sicherer Entwicklung ist, dass Sie wissen, was für Schwachstellen und Angriffe es überhaupt gibt und wie Sie die verhindern bzw. abwehren. Nur was Sie kennen, können Sie auch verhindern.

Dazu zwei Beispiele:

• Wenn Sie in ihrer Webanwendung keine SQL-Injection-Schwachstellen haben, sind auch keine Angriffe darüber möglich. Weder bereits bekannte noch evtl. in der Zukunft neu entwickelte. Hier reicht es also zu wissen, wie SQL Injection verhindert wird.
• 2008 wurde das Clickjacking entdeckt. Damals enthielt keine Webanwendung Schutzmaßnahmen gegen den neuen Angriff (wenn man mal davon absieht, das anfangs Framebuster Schutz boten und die in manchen Anwendungen aus anderen Gründen vorhanden waren). Niemand wusste, dass man die Webanwendungen vor manchen Mausklicks bzw. dem unerwünschten Einbinden im Frames schützen musste. Erst nach Bekanntwerden des Angriffs konnten Gegenmaßnahmen entwickelt und implementiert werden.

Wichtig ist also zunächst, dass Sie ein Grundwissen über mögliche Schwachstellen und Angriffe erwerben. Einen guten Überblick (der aber natürlich nicht vollständig ist, da es mehr als 10 Risiken gibt) liefern die OWASP Top 10 mit den 10 kritischsten Sicherheitsrisiken für Webanwendungen.

Auch hier im Blog finden Sie entsprechende Informationen, und auch mein neues Buch "You’ve been hacked! Alles über Exploits gegen Webanwendungen" gibt einen guten Überblick über die möglichen Schwachstellen und Angriffe. Und dann gibt es ja noch genug andere Quellen im Internet, Buchhandel, evtl. auch Funk und Fernsehen, ... .

Aber mit dem ersten Überblick ist es nicht getan: Nachdem Sie sich einmal ein Grundwissen verschafft haben, müssen Sie danach auf dem laufenden bleiben. Denn es werden immer mal wieder neue Angriffe oder Schwachstellen entdeckt, denen Ihre Anwendungen schutzlos ausgeliefert sind, solange Sie keine Schutzmaßnahmen implementieren - siehe das Beispiel Clickjacking.

Nachdem Sie sich über die möglichen Schwachstellen und Angriffe informiert haben können Sie mit der nächsten Phase fortfahren und die nötigen Anforderungen an die Webanwendung festlegen. Damit geht es in der nächsten Folge weiter.

Carsten Eilers