Testkonzept - Teststufe Securitytest

Ziele der Teststufe

Ein Securitytest dient zur Überprüfung eines Systems oder einer Applikation im Hinblick auf das Vorhandensein von „Sicherheitslöchern“, durch die ein Angreifer das System und/oder Daten ausspähen und/oder manipulieren kann.

Die Ergebnisse des Securitytests sind zu dokumentieren.

Testarten des Securitytests

Whiteboxtest

Der Whiteboxtest besteht aus zwei Teilen

Die Prüfung der korrekten Implementierung von Sicherheitsmechanismen, welche den Funktionstests sehr ähnlich ist.

Wie beim Erstellen von Modultests für die Businesslogik wird auch hier geprüft, ob ausschließlich eine bestimmte Menge von Eingabewerten akzeptiert wird, korrekte Ergebnisse zurückgeliefert werden und das Verhalten insgesamt dem Erwarteten entspricht.

Das Testen der Sicherheitslücken zur Beurteilung der Qualität von Sicherheitsmaßnahmen.

Welchen Bedrohungen die Anwendung ausgesetzt sein wird, kann man jedoch nur Annehmen. Einen endgültigen Beweis für die Sicherheit einer Anwendung können solche Tests niemals liefern.

Um die größtmögliche Anzahl von Bedrohungen abzudecken sollten folgende Bereiche getestet werden:

Authentisierung

» Ablehnung schwacher Passwörter

» Umsetzung einer Passwortrichtlinie

» Erkennung von Brute-Force Angriffen

» Limitierung von Anmeldeversuchen in einem bestimmten Zeitrahmen

» Minimierung der Gefahr von Denial-of-Service Angriffen

» Verhinderung des Cachens lokaler Passwörter

» Vermeiden von Fehlermeldungen, aus denen Angreifer interne Informationen erhalten können

Session-Management

» Sinnvolle Wahl und Funktion von Time-Out Zeiten

» Definierte Abmeldung nach abgelaufener Session

» Verschlüsselung von Cookies mit vertraulichen Daten

» Verschlüsselte Übermittlung von Benutzernamen und Passworten

Eingabeprüfung

» Verhalten bei Überschreiten der maximalen Eingabelänge

» Verhalten, wenn HTML-Tags enthalten sind

» Verhalten, wenn SQL Befehle enthalten sind

» Verhalten, wenn Javascriptcode enthalten ist

Säuberung von Ausgabewerten

» Definierte Fehlerausgabe bei falscher Anzahl von Parametern und falschen Parametertypen

» Keine internen Informationen in HTML-Seiten

» Standardfehlermeldung auch bei internen Fehlern

Beim Erstellen eines Testplans für eine komplexe Anwendung sollte der Schwerpunkt auf die Komponenten gelegt werden, die am einfachsten angegriffen werden können. Zu diesem Zweck sollte für jede Komponente eine Rangliste der potentiellen Risiken angelegt werden.

Designtest

Nach Abschluss der Designphase wird ein Review durchgeführt, um Schwachstellen in der Konzeption noch vor Beginn der eigentlichen Implementierungsphase erkennen und beheben zu können.

Grundsätzliche Fragestellungen beim Designtest

» Entspricht die gewählte Architektur den Sicherheitsanforderungen?

» Sind die Schnittstellen richtig definiert?

» Sind die Architekturdokumente verständlich geschrieben?

Das Hauptmittel des Designtests ist ein Peer-Review der Architekturdokumentation.

Code Review

Code Reviews bestehen vor allem aus dem Lesen des erstellten Codes.

Grundsätzliche Fragestellungen beim Code Review

» Sind die Coding-Richtlinien zur Formatierung eingehalten worden?

» Ist der Code vollständig, ausreichend und korrekt kommentiert worden?

» Sind anderweitige Coding-Richtlinien z.B. zum Secure Coding umgesetzt worden?

» Sind Geheimnisse (z.B. Passwörter, User IDs) in den Code geschrieben worden?

Code Reviews können im Rahmen der Extreme Programming-Entwicklungsmethode als Pair Programming aufgesetzt werden.

Penetrationstest

Penetrationstests fallen aus dem Rahmen der üblichen Entwicklungstests. Sie werden am lebenden Objekt ausgeführt und sollen darstellen, ob und wie man eine Anwendung durch Hacker-Techniken manipulieren oder stören kann.

Dazu gibt es eine Vielzahl von Methoden, die die gesammelte Kreativität der Hacker-Gemeinde
widerspiegeln sollen. Auf diese Weise wird klar, wie es um die Sicherheit einer Anwendung bestellt ist.