Es handelt sich hierbei um die Forführung der Beiträge aus diesem Thread.


Falls jemand vorhaben sollte, einen Exchange aufzumachen, möchte ich ein paar kleine Tipps loswerden (nicht vollständig):
1. Überlegt euch vor der Implementation, welche Sachen unbedingt in den Exchange verbaut werden müssen. Je weniger verbaut wird, desto kleiner ist die Angriffsfläche. Je kleiner die Angriffsfläche, desto weniger Informationsgewinn für einen Angreifer.
2. Sucht euch Leute, die schonmal sicherheitskritische Systeme implementierten. Solltet ihr diese nicht finden können, dann achtet darauf, dass ihr möglichst wenige aber dafür für eure Anforderungen am besten geeignete Bibliotheken einbaut. Im Zweifelsfall entscheidet euch für die Bibliothek, welche den größeren Anteil aktiver Entwickler, Tester und dokumentierte Testfälle hat.
3. Wenn ihr Bibliotheken verbaut, so vergesst bitte SaaS (Software as a Service). Ihr baut ein sicherheitskritisches System und eben keine Werbeplattform für externe Dienstleister. Der zusätzliche Code darf aber wegen der besseren Isolier- und Modularisierbarkeit durchaus von einem anderen Server kommen. Dieser sollte aber exakt in derselben Domäne stehen, wie die aufgerufene Seite.
Sinn dahinter: Ein Angreifer erhält so gut wie keine Informationen frei Haus geliefert. Das erschwert die Planung eines Angriffs und erhöht den Aufwand.
4. Misstraut grundsätzlich allen Komponenten, die Teil eures Designs sind. Und jetzt betrachtet euer Vorhaben erneut! Wie schottet ihr die Komponenten gegeneinander ab? In welche Richtung fließen die Daten? In welcher Richtung werden die Steuerungsbefehle gelenkt? Wie sollte es möglichst nicht aussehen, wenn jemand euer Netzwerk übernommen hat? Was würde einem Angreifer so richtig die Suppe versalzen, wenn dieser euer Netzwerk übernommen haben sollte?
5. Investiert mehr als die Hälfte aller eurer Mittel (sowohl Zeit als auch Geld und jegliche andere Ressourcen) in Fehler! D.h. geht davon aus, dass mehrere Tage lang alles schief gehen würde, was nur irgendwie schief gehen kann. Wie sollte das System in der Situation reagieren? Wie schlimm wirken sich Userfehler aus? Was kann durch fehlerhafte Bedienung schief gehen?
Kommt es z.B. durch Bedienfehler zum Datenverlust oder Rechenfehlern, dann wisst ihr bereits ganz genau, dass ihr auf dem Holzweg seid. Testet das System. Rollt nur getestete Komponenten aus und seid euch nicht zu fein dafür, sowohl Unittests als auch Integrationtests einzufordern. Sollte strikt das MVC-Prinzip beibehalten worden sein, dann könnt ihr die kritischen Komponenten fast immer vollautomatisiert testen. Für Integrationstests im Modell eignen sich z.B. expect (Tcl) und pexpect (Python). Greift im Testbetrieb euer eigenes System an! Sabotiert es! Trachtet danach, es zu zerstören! Nutzt Fuzzing (d.h. schmeißt Zufallswerte in die Eingabemasken!). Wenn euer System das alles verdaut, dann kann es in den Produktionsbetrieb gehen und wird ausschließlich netzwerkbasierte DoS-Attacken zu fürchten haben.

Wenn ihr das alles zusammennehmt, kommt ihr zu der goldenen Regel: Designt euer System grundsätzlich als Default-Deny und macht es dennoch fehlertolerant! D.h. das System sollte keinem Client trauen. Ganz besonders dann nicht, falls ein Aufruf nicht ganz sauber sein sollte. Der Server darf möglichst keine Informationen über den internen Aufbau herausgeben. Besonders auf Fehlerfälle darf dieser nach außen nur mit Schweigen und "Business as usual" reagieren.

Verschlüsselung erwähnte ich bisher nicht, weil ich diese als Standard voraussetze. Es versteht sich von selbst, dass diese nur in begründeten Einzelfällen selbst implementiert werden sollte. Das Risiko, Timings nicht richtig gegeneinander abzuwägen oder Speicherbereiche nicht sauber zurückzusetzen ist meistens größer, als die zusätzliche Angriffsfläche durch eine bekannte Bibliothek.