Löchrige Abwehrmechanismen

Dürftige Zugangskontrolle: Wer schon mal zu Hause eine offene Party gefeiert hat, kennt das Problem, dass Freunde ihre Freunde mitbringen. Im Haus streunen schließlich viele unbekannte Gesichter herum, und während der Gastgeber sich einzelnen Gästen zuwendet, können die Anderen ungehindert den Kühlschrank plündern oder in Schränken wühlen. Eine ungeeignete Zugangskontrolle zu Applikationen kann vergleichbare Probleme auslösen, die Konsequenzen können im schlimmsten Fall größeren finanziellen Schaden anrichten als ein geleerter Kühlschrank. Eine saubere Autorisierung ist daher Pflicht für jede Software.

Man kann Angriffen vorbeugen, indem man Daten und Funktionen sorgfältig bestimmten Benutzerrechten zuordnet. Wenn anonyme User zugelassen werden, muss auf deren Rechte besonderes Augenmerk gelegt werden.

Schwache Verschlüsselungs-Algorithmen: Kritische Daten werden üblicherweise verschlüsselt übertragen. Manch ehrgeiziger Programmierer hat es sich zur Aufgabe gemacht, eine eigene Verschlüsselungs-Routine zu schreiben, in der Hoffnung, sie könne Hacker besser abwehren. Kryptografie ist schwierig und eine eigene Wissenschaft. Wenn schon brillante Mathematiker und Wissenschaftler sich an unknackbaren Codes die Zähne ausbeißen, sollte dies Hinweis genug sein, sich nicht selbst daran zu versuchen.

Vielmehr empfiehlt sich die Verwendung einer weit verbreiteten und gestesteten Implementierung eines starken Verschlüsselungsverfahrens.

Fest programmierte Passwörter: Fest programmierte Passwörter in Authentifizierungs-Modulen sind sehr bequem etwa für Testroutinen, laden aber auch Hacker ein und führen damit jede Sicherheitsbarriere ad absurdum. Wird das Passwort öffentlich und handelt es sich dabei um dasselbe Codewort, sind alle Anwender der Software bedroht. Systemverwalter können in solchen Fällen nur wenig unternehmen, wenn das Passwort im Binärcode eingebettet ist.

Ungesicherter Zugang zu kritischen Ressourcen: Hacker sind unhöfliche Leute, denn sie fragen nicht um Erlaubnis, wenn sie sich etwas nehmen. Das tun sie gerne wenn kritische Programme, Daten und Konfigurations-Files frei zugänglich les- und veränderbar sind. Die Zugangsbeschränkung wird in der Implementierung und im Design gerne hintangestellt - und dann vergessen. Diese Sicherungslücke zu erkennen, der Aufmerksamkeit des Systemadministrators zu überlassen, ist keineswegs optimal.

Vorhersehbare Zufallsergebnisse: Benötigt ein Sicherheitssystem Zufallszahlen, um etwa eine Session-IDs oder temporäre File-Namen zu erzeugen, dann sollten sie nicht einfach vorhersehbar sein. Üblicherweise kommen dabei Pseudozufallsgeneratoren zum Einsatz (Pseudo-Random Number Generators; PRNG), dennoch ist Vorsicht geboten. Wenn Angreifer den verwendeten Algorithmus finden, können sie die folgende Zahlenkombinationen errechnen oder zumindest die Trefferwahrscheinlich verbessern.

Zufallsgeneratoren, die nicht als kryptographisch sicher bewerben werden, sind möglicherweise statische Generatoren und sollten daher nicht zum Einsatz kommen. Wer unschlüssig ist, sollte mit dem Test "FIPS 140-1" die Verlässlichkeit prüfen.

Programmausführung mit zu vielen Rechten: Programme benötige oft spezielle Rechte, um bestimmte Operationen ausführen zu können. Zu weit gefasste Zugriffsmöglichkeiten bergen Risiken. Applikationen mit Extraprivilegien können zum Teil auf Ressourcen zugreifen, die dem Nutzer der Anwendung eigentlichen verwehrt bleiben sollten. Beispielsweise kann die Software andere Programme starten und damit dem User Zugriff auf geschützte Daten einräumen. Die Vergabe von Rechten sollte daher sehr eng begrenzt sein. Vor allem der Zugang zu Betriebssystem-Ressourcen, die mit weit gefassten Rechten versehen sind, muss stark kontrolliert werden.

Verlagerung von Security-Aufgaben vom Server zum Client: Gefährlich wird es auch, dem Client Security-Aufgaben zu übertragen, die eigentlich dem Server vorbehalten sind (etwa Authentifizierung, Authentisierung, Eingabeprüfung). Hacker finden hier möglicherweise einen Angriffspunkt, indem sie einen eigenen Client entwickeln, der auf Authentifizierung verzichtet. Die Folgen sind kaum absehbar, das Ausmaß hängt mit den Aufgaben ab, die dem Client aufgebürdet wurden.

Sicherheitsroutinen gehören auf den Server, mahnt das SANS-Institut. Interaktionen und Eingaben auf dem Client sollte man nie bedingungslos vertrauen. Allenfalls können Security-Mechanismen auf dem Client zusätzlich implementiert werden.