Security Audit: worauf wir bei Webanwendungen schauen
Die Befunde wiederholen sich. Die Prüfpunkte, mit denen wir jede Anwendung beginnen – und die Klassen von Fehlern, die dabei fast immer auftauchen.
Ein Audit ist kein Werkzeugdurchlauf. Automatische Scanner finden veraltete Bibliotheken und fehlende Kopfzeilen – die teuren Lücken liegen in der Fachlogik, und die kennt kein Scanner. Wir beginnen deshalb immer mit der Frage: Wer darf was, und wo wird das geprüft?
1. Zugriffskontrolle auf Objektebene
Der häufigste ernste Befund. Die Anwendung prüft, ob jemand angemeldet ist, aber nicht, ob dieser Datensatz ihm gehört. Eine fremde Kennung in der Adresszeile genügt dann. Geprüft wird das nicht in der Oberfläche, sondern an jedem Endpunkt einzeln – inklusive Exporten, Anhängen und Vorschaubildern.
2. Mandantentrennung unter Last der Sonderfälle
- Hintergrundprozesse, die mit erweiterten Rechten laufen.
- Auswertungen und Zähler, die über Mandantengrenzen aggregieren.
- Geteilte Ressourcen wie Vorlagen, Anhänge oder Suchindizes.
- Administrative Oberflächen, die versehentlich für Kundenkonten erreichbar sind.
3. Serverseitige Prüfung aller Eingaben
Jede Prüfung, die nur im Browser stattfindet, existiert nicht. Auf dem Server gehört zu jeder Schnittstelle ein Schema, das Typ, Länge und Wertebereich festlegt, und eine Fehlermeldung, die nichts über interne Strukturen verrät.
4. Dateiuploads
- Dateityp anhand des Inhalts prüfen, nicht anhand der Endung.
- Größenbegrenzung serverseitig durchsetzen.
- Dateien außerhalb des ausgelieferten Verzeichnisses ablegen und nur über kontrollierte, zeitlich begrenzte Links ausliefern.
- Dateinamen neu vergeben, niemals den vom Nutzer gelieferten Namen für den Pfad verwenden.
5. Abhängigkeiten und Lieferkette
Veraltete Pakete sind einfach zu finden und einfach zu beheben, werden aber selten systematisch gepflegt. Wichtiger als der einmalige Durchlauf ist der Prozess: automatische Prüfung bei jedem Bau, feste Versionen und eine benannte Person, die auf Meldungen reagiert.
6. Nachvollziehbarkeit
Zum Schluss die forensische Frage: Wenn morgen der Verdacht besteht, dass Daten abgeflossen sind – ließe sich das mit den vorhandenen Protokollen belegen oder widerlegen? Eine Anwendung, die diese Frage nicht beantworten kann, ist unabhängig von ihrer technischen Härte nicht prüfbar.
Häufige Fragen
Klingt nach Ihrem Thema?
Wir bauen und betreiben Software für Branchen, die von großen Anbietern übersehen werden – und prüfen sie selbst auf Sicherheit. Schildern Sie uns Ihre Ausgangslage.
Projekt besprechenPassend dazu
Die ersten 24 Stunden nach einem IT-Vorfall
In den ersten Stunden wird entschieden, ob ein Vorfall später aufklärbar ist. Eine Reihenfolge, die Spuren sichert, statt sie zu vernichten.
Logging, das im Ernstfall trägt
Die meisten Systeme protokollieren viel und beweisen wenig. Welche Ereignisse tatsächlich gebraucht werden, wie lange sie aufbewahrt werden dürfen und warum die Uhr entscheidend ist.