Sicher programmieren – aber wie?

Viele Gefahren lauern im Internet – doch jeder und jede kann daran helfen, diese zu minimieren und zu entschärfen: Die Userin, die nicht auf den verdächtigen Link in der Email klickt, der Netzwerktechniker, der die Firewalls entsprechend konfiguriert, die Administratorin, die auf eine robuste Authentifizierung setzt und zu guter Letzt auch die Entscheidungsträger, die das Geld dafür freigeben müssen. (Um nur einige zu nennen.)

Ein weiterer, wichtiger Punkt ist aber auch die sichere Software und wie diese erstellt wird. Wir wollen hier einige grundlegende Entscheidungen und den Prozess der Entwicklung betrachten, weniger den eigentlichen Vorgang des Codens. Dabei werden wir als Betreiber von Webservern natürlich im Speziellen auf Webanwendungen eingehen. Da das Thema sehr umfangreich ist, dürfen sich unsere Leser auf eine Serie zu diesem Thema freuen.

Was ist Sicherheit eigentlich?

Behalte Sie immer im Hinterkopf, dass Sicherheit ein Zustand ist, der sich jederzeit ändern kann.

Etwas, das wir heute noch für sicher halten, kann morgen schon als unsicher gelten. Ein Beitrag kann also schon zum Zeitpunkt der Veröffentlichung veraltet sein. Wir sind also nie „fertig mit Sicherheit“

Was darf das kosten?

Sicherheit kostet auch Geld, unabhängig davon, ob es der Security Mitarbeiter vor einer Bank ist oder das Code Audit einer Software. Aber wie viel soll in die Sicherheit investiert werden?

Die Obergrenze ist recht einfach zu ermitteln: Nicht mehr, als der Wert der Sache beträgt, die beschützt werden soll. Das Schloss sollte nicht mehr kosten, als das Fahrrad – meist sind die verfügbaren Ressourcen aber leider ohnehin deutlich geringer.

Aber wo liegt die Untergrenze? Nun: Sicherheit soll ihren Zweck erfüllen.

Ein einfaches Beispiel:
Caesar hat – der Überlieferung nach – mit seinen Truppen verschlüsselt kommuniziert (Link). Wenn nun der Feind um 08:02 die Nachricht „Angriff um 08:00“ entschlüsselt hätte, dann hat dieser Chiffre seinen Zweck offensichtlich erfüllt und das mit verhältnismäßig geringem Aufwand. Es ist also sinnvoll, zuerst die „low hanging fruits“ umzusetzen, wo schon mit wenig Aufwand viel erreicht werden kann.

Und, was ist der Zweck in der Datenverarbeitung?

Aufgabe der Security in der Datenverarbeitung ist ganz klar, die Daten und Systeme zu beschützen, dass nur Berechtigte Zugriff darauf haben, sodass sie nicht manipuliert werden können.

Welchen Wert haben diese Ziele?
Das lässt sich am besten mit ein paar Gegenfragen beantworten:

  • Wie viel kostet es, wenn der Webshop auch nur einen Tag lang nicht läuft? Zum Beispiel der Vertriebsausfall, das Nachtragen der verlorengegangenen Daten.
  • Wie viel kostet es, wenn das Netzwerk auch nur einen Tag nicht läuft und viele Mitarbeiter nicht arbeiten können?
  • Wie teuer ist der Image-Verlust, wenn der Firmenname öffentlich mit dem Wort „Datendiebstahl“ in Verbindung gebracht wird?

Ein Ziel dieser Reihe ist es, einen Überblick zu geben, wie die vorhandenen Ressourcen möglichst effektiv eingesetzt werden können – aus Sicht der IT-Security.

Konkret beginnt das bereits bei der Entwicklungsumgebung und der Versionsverwaltung, dem Zugriff auf den Server und der Art der Passwort-Speicherung.

Wir werden über HTTP-Header und Cookies schreiben und warum eine gute .htaccess-Datei wichtig ist. Was sind XSS und CSRF und wie lassen sich die vermeiden? Warum ist es sinnvoll, ein Framework einzusetzen und was bedeutet „verbesserungswürdiger defensiver Programmierstil“ in einem Pentest?
Das sind nur einige Themen auf die ich eingehen möchte. Beginnen werden wir mit Headers und Cookies.

Zum Abschluss möchte ich noch anmerken, dass manche Themen zur besseren Verständlichkeit vereinfacht erklärt werden, auf Kosten der Vollständigkeit und Detailtreue.

Jan Thomasberger