Herr Dr. Sams, auf Antihacking-Seminaren ist das Einbrechen in Online-Shops eine beliebte Demonstration. Sind die meisten Internetläden wirklich so schlecht programmiert?
Ich will und kann hier keine statistische Aussage machen, aber Tatsache ist, dass das größte Sicherheitsproblem in der IT in den Anwendungen selbst liegt. Es gibt eine Studie des National Institute for Standards and Technology (NIST) in den Vereinigten Staaten, die besagt, dass über 77 Prozent aller Sicherheitsprobleme auf Anwendungen zurückzuführen sind, nicht auf Lücken bei der Verschlüsselung oder bei den Netzwerkprotokollen.

Wo hapert es am meisten bei der Anwendungssicherheit?
Eines der Hauptprobleme heutzutage besteht darin, dass bei vielen Webapplikationen eine vernünftige Validierung fehlt. Benutzereingaben werden einfach akzeptiert.

Ist das nicht stark übertrieben? Sie sagen, dass kaum jemand, der professionell im Internet Waren oder Dienst­leistungen anbietet, seine Bestell- und Abrechnungssysteme gegen Witzbolde oder Bösewichte immunisiert hat?
So ist es aber. Natürlich sind manche Branchen besser als andere. Der Banken- und Versicherungsbereich ist beispielsweise deutlich besser als andere Branchen. Trotzdem würde ich schätzen, dass im Schnitt und querbeet durch alle Branchen gerade einmal 50 Prozent der Webanwendungen vom Sicherheitsstandpunkt ordentlich programmiert sind. Was allerdings nicht heißen soll, dass sie fehlerfrei sind.

Was zeichnet sichere Webanwendungen aus?
Die gesamte Architektur muss sicher gestaltet sein. Die Authentisierung ist so durchzuführen, dass sich niemand einschmuggeln kann, desgleichen die Autorisierung. Ebenso muss die Datenübertragung wasserdicht sein, beispielsweise beim Hoch- und Herunterladen. Das Parsing der XML-Dateien muss fälschungssicher ablaufen. Das sind nur einige Punkte. Und all dies muss schon ganz am Anfang, bei der Ausgestaltung des Programmier-Frameworks, richtig angepackt werden.

Ich gebe ja zu, de facto wird oft schlampig programmiert. Aber Sie suggerieren ja, so scheint es mir wenigstens, dass Anwendungssicherheit beim zugrunde liegenden Fachkonzept selten eine Rolle spielt…
…in der Tat spielt Sicherheit in den Fachkonzepten immer noch viel zu ­selten eine Rolle. Dort wird meist nur genau definiert, wie die Anwendung sich fachlich zu verhalten hat. Was die Eingabefelder bedeuten, was eine ­Monatseingabe und was eine Jahreseingabe ist und welches einstellige und welches zweistellige Eingaben sind. Über Sicherheit wird in diesen Fachkonzepten selten gesprochen. Entweder glauben die Vertragspartner, dass sie von Heinzelmännchen erzeugt wird oder sie glauben, dass nichts passieren kann, weil die Anwendung hinter einer Firewall sitzt.

Sicherheit muss also im Fachkonzept beziehungsweise in einem Auftrag an einen externen Programmierer nicht nur erwähnt, sondern auch genau spezifiziert werden?
So ist es. Oft ist Sicherheit ein bloßes Lippenbekenntnis. Es reicht nicht, in ­einem solchen Vertrag zu sagen, dass der Partner eine sichere Anwendung schreiben soll, sondern man muss klar sagen, dass die fertige Anwendung gegen Angriffe wie SQL-Injection, LDAP-Injection, Cross-Site-Scripting, Header-Manipulationen und so weiter explizit getestet wird.

Sie haben vorhin darauf aufmerksam gemacht, dass Sicherheitsmerkmale möglichst ganz am Anfang der Softwarearchitektur eingebracht werden sollten. Sie sprachen vom Framework, also der abstraktesten Ebene überhaupt. Sollte das nicht etwas codenäher passieren?
Zunächst einmal: Sicherheit muss auf allen Ebenen eine Rolle spielen. Auf der Ebene der Frameworks und der Entwurfsmuster wird ein Standardrahmen festgelegt, in dem die Implementierung stattfinden kann. Man schafft Standardklassen, Standardverhältnisse zwischen Klassen, um eine gute Programmierung zu erleichtern. Da gehört Sicherheit ­dazu, das ist doch keine Frage. Natürlich muss später auch der Code auf ­Sicherheit sehr genau durchgesehen werden. Was kann man aber auf dieser abstrakten Ebene konkret für eine sichere Anwendungsprogrammierung tun? Das Wichtigste ist erst einmal, ein gemeinsames Vokabular zu entwickeln. Sehen Sie, wenn vor sieben, acht Jahren Programmentwickler miteinander gesprochen haben, dann hatten sie Schwierigkeiten, sich wechselseitig verständlich zu machen, ihre Designs zu erklären. Der Grund war, dass zu diesem Zeitpunkt noch nicht sehr viele Entwurfsmuster allgemein akzeptiert waren beziehungsweise verwendet wurden. Konstrukte wie Singleton, Adapter, Bridge, Template Method oder Factory wurden von einigen benutzt, von anderen nicht. Das hat sich, glaube ich, geändert. Dieses Begriffsvokabular müssen wir jetzt auf die Sicherheitsaspekte in der Programmierung ausdehnen. Das hilft später bei der Implementierung ungemein.

Hinter dem Standardvokabular stehen dann Standardmethoden?
Genau so ist es. Das muss keine Standardsprache für die Implementierung sein, sollte aber eine Standardmethode sein, um Sicherheit in die Entwicklung zu integrieren. Das nenne ich Secure Design Pattern.

Sie haben es schon angeschnitten. Trotz aller Vorbereitung auf den abstrakten Architekturebenen muss auch der Code letztlich Zeile für Zeile auf ­Sicherheitsaspekte hin überprüft werden. Gibt es da keine Automatismen? Es gibt doch schon seit langem automatische Code-Verifizierer.
Diese Tools entdecken aber eher Syntaxfehler auf oder Variablen, die nicht einer bestimmten Konvention entsprechen. Bei Optimabit haben wir aber in der Tat ein sehr leistungsfähiges Werkzeug für interne Zwecke entwickelt. Damit lassen sich sehr komplexe Systeme analysieren. Wir können eine Anwendung mit 100000 oder 200000 Codezeilen, die auf verschiedenen Anwendungsservern läuft, auf Applikationssicherheit überprüfen und je nach Applikationsserver richtig einstellen.

Wie läuft das ab?
Unser Bytecode-Scanner verfolgt beispielsweise alle Werte, die aus einer Abfrage übernommen und in der Session gespeichert werden. Danach können wir prüfen, ob eine Benutzung dieser Werte stattfindet, ohne dass sie zuvor validiert worden sind. Dies zu erkennen ist gar nicht so einfach. Aber es geht.

Ähnelt Ihr Werkzeug einem HTML-/XML-Filter? Manche bezeichnen diese Filter auch als Applikations-Firewall.
Nein, das ist was ganz anderes. Die von Ihnen genannten Produkte versuchen http-Anfragen so zu analysieren, dass erkannt wird, ob die Benutzereingabe von Haus aus gültig sein könnte. Und wenn etwas nicht stimmt, wenn also das System ungültige Eingaben feststellt, dann wird die Anfrage zurückgewiesen. Im Allgemeinen halte ich wenig von dieser Methode. Diese Filter haben die Wirkung, dass manche meinen, die Entwickler könnten ruhig etwas schlampig programmieren, da man sich ja wegen der Sicherheit keine Gedanken machen müsse. Man schaltet dieses Tool davor und alles ist in Ordnung.

Die Wirkung dieser Filter auf die Programmierer mag ja durchaus so sein, wie Sie beschreiben. Trotzdem arbeiten diese Filter doch sehr effizient. Sie stellen ja sozusagen eine zweite Programmierungsschicht dar, die über die erste Programmierung gelegt wird.
Na ja, die Praxis ist sehr viel komplizierter. Wenn Sie so eine Applikations-Firewall einsetzen, müssen Sie dieser Firewall beibringen, welche Felder Sie in der Anwendung haben. Manche haben eine Länge von 10, manche von 100 Zeichen. In manchen Kommentarfeldern darf man zum Beispiel Symbole wie > oder < benutzen, nicht aber in einem Datumsfeld. Das bedeutet, dass es eine sehr starke Kopplung gibt zwischen den Einstellungen der Firewall und denen der Anwendung. Das heißt, jedes Mal, wenn Sie eine Änderung an der Anwendung machen, müssen Sie auch eine Änderung an der Firewall machen. Sie dürfen sicher sein, dass es nur eine kurze Zeit dauert, bis die Anwendungsentwickler und die Firewall-Betreuer kein freundliches Wort mehr miteinander reden können. Im Übrigen wird das Problem bei den viel zitierten serviceorientierten Architekturen noch gravierender.

Warum?
Dort werden ja bestimmte Anwendungen nicht nur von einer bestimmten Anwendergruppe aufgerufen, sondern sie werden miteinander verkettet. Wenn Sie vor jede Anwendung und vor alle anderen Anwendungen, die diese aufrufen, dann wieder eine Applikations-Firewall schalten müssen, und jede Applikations-Firewall muss wissen, wie diese Anwendungen, die dahinter stehen, eingestellt sind, dann bekommt man eine Ahnung davon, dass das in der Praxis nur schwer durchführbar ist.

Herr Dr. Sams, vielen Dank für das Gespräch!