Web Application Testing
Sicherheit von Webanwendungen gegen Missbrauch und Schwachstellen
Frontend und API, gemeinsam getestet
Eine moderne Webanwendung besteht aus zwei Komponenten: der Benutzeroberfläche, die Ihre Nutzer sehen, und der dahinterliegenden API-Schicht. Wenn Sie nur eine davon testen, entsteht ein falscher Eindruck hinsichtlich der Testabdeckung.
Jeder CREDS-Webanwendungstest deckt beides ab. Wir testen das Frontend auf Schwachstellen, die über den Browser sichtbar werden, und wir testen die API-Schicht direkt, einschließlich Endpunkten, die vom Frontend niemals aufgerufen werden, Autorisierungslogik, die ausschließlich serverseitig durchgesetzt wird, sowie Funktionen, die ohne Umweg über die Benutzeroberfläche erreichbar sind.
In der Praxis lassen sich die schwerwiegenderen Schwachstellen in der Regel im API feststellen. Fehlerhafte Berechtigungen auf Objektebene, fehlende Zugriffskontrollen an einzelnen Endpunkten sowie Geschäftslogik, die in eine falsche Reihenfolge gebracht werden kann, sind vom Frontend aus nicht erkennbar und werden bei einem Scan nicht entdeckt.
Frontend
Authentifizierung und Sitzungsverwaltung, Eingabeverarbeitung, clientseitige Logik, die in der Schnittstelle durchgesetzte Zugriffskontrolle sowie die Schwachstellen, die den Browser eines Benutzers betreffen.
API
Autorisierung auf Endpunkt-Ebene, Zugriffskontrolle auf Objektebene, Missbrauch der Geschäftslogik, verkettete Anfragen und Endpunkte, die nicht über die Schnittstelle zugänglich sind.
Wie wir testen
Ein Penetrationstest ist ein zeitlich begrenzter Vorgang. Daher lautet die eigentliche Frage nicht „Was kann getestet werden?“, sondern „Wo lässt sich die verfügbare Zeit am besten nutzen?“. Unser gesamter Ansatz ist darauf ausgerichtet, diese Frage zu beantworten.
Die Automatisierung leistet die Vorarbeit
Wir setzen vor und während des Tests in der gesamten Anwendung ein hohes Maß an Automatisierung ein: die Erfassung der Angriffsfläche, die Ermittlung von Endpunkten und die Vorbereitung der Grundlagen – all dies erfordert keinen menschlichen Eingriff. Das ist nicht der eigentliche Test. Es ist das, was unsere Tester von sich wiederholenden Aufgaben befreit, sodass sie ihre Zeit den Aspekten widmen können, die die Automatisierung nicht abdecken kann: Geschäftslogik, verkettete Schwachstellen, Autorisierungsfehler und der Missbrauch der eigentlichen Funktionalität der Anwendung.
Überprüfung des Quellcodes, soweit dies möglich ist
Wir ziehen es vor, eine automatisierte Überprüfung des Quellcodes in den Auftrag einzubeziehen. Der Zugriff auf den Code bietet uns zwei Vorteile: einen klareren Überblick darüber, wo Schwachstellen tatsächlich ihren Ursprung haben – und nicht nur, wo sie zutage treten –, sowie eine deutlich effizientere Prüfung, da wir keine Zeit damit verbringen müssen, die Funktionsweise der Anwendung zu ergründen.
Mit Quellcodeanalyse tauchen wir in den Code ein, um potenzielle Schwachstellen zu identifizieren.
Manuelle Tests dort, wo es darauf ankommt
Die Automatisierung erkennt bekannte Muster. Sie erkennt jedoch nicht die Fehler, die ausschließlich darauf zurückzuführen sind, wie Ihre Anwendung einen bestimmten Geschäftsprozess abwickelt. Diese Arbeit erfolgt manuell durch einen Tester, der den Zweck Ihrer Anwendung versteht, und genau hier fließt der Großteil der Arbeitsstunden des Projekts ein.
Drei Prüfstufen
Wir unterteilen unsere Tests in Stufen, die auf den Reifegrad Ihrer Anwendung und Ihres Unternehmens abgestimmt sind. Welche Stufe die richtige ist, hängt davon ab, wie oft sich die Anwendung ändert, wie kritisch sie ist und in welchem Umfang sie bereits getestet wurde.
- 01
Grundlegender Penetrationstest
Der unverzichtbare Test, der für jede Webanwendung geeignet ist. Der Schwerpunkt liegt auf der Identifizierung häufiger Schwachstellen im Frontend und im API, wobei die Prüfung anhand anerkannter Standards erfolgt. Der richtige Ausgangspunkt für einen ersten Test, eine neu gestartete Anwendung oder regelmäßige, wiederkehrende Sicherheitsüberprüfungen.
Typical duration: 1 Woche
- 02
Erweiterter Penetrationstest
Geht tiefer und zielt auf komplexe Probleme ab, die bei einem Basistest nicht zutage treten: komplexe Angriffsketten, Missbrauch der Geschäftslogik, subtile Autorisierungsfehler und Schwachstellen, die erst dann auftreten, wenn mehrere kleinere Schwachstellen kombiniert werden. Geeignet für Anwendungen, die sensible Daten verarbeiten, oder für Fälle, in denen ein vorheriger Basistest relativ unauffällig ausgefallen ist.
Typical duration: 2 Wochen
- 03
Szenariobasierter Penetrationstest
Maßgeschneiderte Szenarien, die auf Ihre Betriebsumgebung und Bedrohungslage zugeschnitten sind und testen, was ein konkreter, realistischer Angreifer tatsächlich gegen Ihre Anwendung versuchen würde. Geeignet, wenn Sie eine bestimmte Frage klären möchten, anstatt eine umfassende Abdeckung anzustreben.
Typical duration: 2 bis 3 Wochen
Sie sind sich nicht sicher, welches Niveau das richtige ist? Das klären wir gemeinsam als Erstes im Rahmen der Bedarfsanalyse, und wir werden Ihnen mitteilen, wenn ein weniger umfangreicher Test die richtige Lösung ist.
Gemäß anerkannten Normen geprüft
Tests sind nur dann sinnvoll, wenn ihre Tiefe und ihr Umfang nachprüfbar sind. Wir arbeiten nach internationalen Standards, damit die Abdeckung Ihrer Tests vergleichbar, wiederholbar und gegenüber einem Auditor vertretbar ist – und nicht davon abhängt, welchen Tester Sie zufällig erhalten haben.
OWASP ASVS. Der „Application Security Verification Standard“ ist unser primäres Rahmenwerk zur Festlegung des Umfangs eines Webanwendungstests.
OWASP Top 10. Die grundlegenden Sicherheitsrisiken von Anwendungen.
OWASP – Leitfaden für Web-Sicherheitstests. Die Methodik, nach der unsere Tester vorgehen.
OWASP – Spickzettel zur Sicherheit von Webdiensten. Gilt gegebenenfalls für API-Prüfungen.
NCSC-Leitlinien zur IKT-Sicherheit. Für Webanwendungen und für Transport Layer Security (TLS).
BIO. „Baseline Informatiebeveiliging Overheid“ – für den Einsatz im öffentlichen Dienst.
Logius-Normen. Für DigiD-Prüfungen.
Zertifizierungen und Mitgliedschaften
Nichts verlässt das Haus, ohne dass ein zweites Paar Augen darauf geachtet hat
Jeder CREDS-Penetrationstest wird gemäß unserem Vier-Augen-Prinzip in zwei Bereichen einer Begutachtung durch Fachkollegen unterzogen, bevor er an Sie weitergeleitet wird.
Technische Überprüfung
Ein zweiter Tester prüft die Ergebnisse selbst: Ist die Sicherheitslücke tatsächlich vorhanden, wurde die Auswirkung korrekt eingeschätzt, ist der Reproduktionspfad zutreffend und wurde etwas im Untersuchungsumfang übersehen?
Inhaltsprüfung
Eine gesonderte Überprüfung des Berichts als Dokument: Wird jeder Befund klar genug erläutert, um darauf reagieren zu können? Ist die Risikoeinstufung nachvollziehbar? Sind die Empfehlungen zur Behebung konkret und nicht nur allgemein gehalten? Und ist der Bericht für den Entwickler, der die Fehler beheben muss, sowie für den Vorgesetzten, der die Arbeiten genehmigen muss, verständlich?
Dies gilt auch für große Projekte. Es gilt für jeden Test, auf jeder Ebene.
DigiD-Prüfungen, bei denen der Wirtschaftsprüfer bereits zu unserem Team gehört
Unternehmen, die sich einer DigiD-Prüfung unterziehen müssen, benötigen in der Regel zwei Dienstleister: einen Anbieter für die Durchführung des Penetrationstests und einen registrierten IT-Prüfer für die Erstellung des Prüfungsberichts. Dies erfordert zwei Verträge, zwei Zeitpläne und eine Übergabe zwischen den beiden Dienstleistern.
CREDS verfügt über eigene, registrierte IT-Auditoren (RE). Unser RE begleitet den Penetrationstest, arbeitet während des gesamten Prozesses direkt mit den Testern zusammen und erstellt im Rahmen desselben Auftrags das zusätzliche Kapitel, das als Grundlage für Ihr DigiD-Audit dient.
Wir integrieren Kontrollrahmenwerke wie DigiD direkt in den Test selbst, sodass die Prüfung von Anfang an auf die Anforderungen abgestimmt ist und nicht erst im Nachhinein an diese angepasst wird. Das Ergebnis ist ein einziger Anbieter, ein einziger Zeitplan und ein Prüfbericht, der von einer Person erstellt wird, die den Test live mitverfolgt hat.
Gilt für DigiD sowie für Organisationen, die nach BIO arbeiten.
Sie warten nicht im Dunkeln
Ein Penetrationstest sollte keine „Black Box“ sein, die erst drei Wochen später einen Bericht liefert. Hier erfahren Sie, was während der Durchführung des Tests geschieht.
Tägliche Start- und Stopp-Benachrichtigungen
Sie werden täglich darüber informiert, wann die Testaktivitäten beginnen und enden, sodass Ihr Team stets weiß, ob der Datenverkehr in der Anwendung von uns oder von jemand anderem stammt.
Befunde mit hohem Risiko werden umgehend übermittelt
Sollten wir etwas Ernstes feststellen, werden Sie darüber informiert, sobald dies bestätigt ist – und nicht erst im Bericht. Eine kritische Sicherheitslücke ist nichts, was man bis zur Abschlussbesprechung zurückhalten sollte.
Ergebnisse in Echtzeit sichtbar
Die Ergebnisse werden unmittelbar nach ihrer Erfassung im Kundenportal angezeigt, sodass Ihre Entwickler bereits vor Abschluss des Auftrags mit der Arbeit beginnen können, anstatt auf ein Dokument warten zu müssen.
Wir passen den Test gemeinsam mit Ihnen neu an
Ein Penetrationstest ist zeitlich begrenzt, was bedeutet, dass stets die Wahl besteht, wofür die verbleibenden Stunden eingesetzt werden sollen. Während des Tests führen wir gemeinsam mit Ihrem Team ein Brainstorming durch, um zu entscheiden, worauf wir uns als Nächstes konzentrieren sollen – basierend auf unseren bisherigen Erkenntnissen und Ihrem Wissen über die Anwendung. Ein Befund in einem Bereich macht oft einen anderen Bereich interessanter, als ursprünglich im Plan vorgesehen war.
Was Sie erhalten
Ein Berichtsentwurf, der vor seiner endgültigen Fertigstellung erörtert wird. Wir erläutern Ihnen die Ergebnisse und die Risikoeinstufungen, solange noch Zeit bleibt, etwaige Missverständnisse bezüglich Ihrer Umgebung auszuräumen. Kein Kunde sollte einen endgültigen Bericht zum ersten Mal lesen.
Der vollständige Bericht. Jeder Befund, dessen Auswirkungen, ein Nachverfolgungsweg sowie konkrete Empfehlungen zur Behebung.
Eine Kundenzusammenfassung für Ihre Stakeholder. Eine separate, leicht verständliche Zusammenfassung, die sich an diejenigen richtet, die das Ergebnis nachvollziehen und die Arbeit genehmigen müssen – nicht an diejenigen, die die Fehler beheben.
Ein Sanierungsplan, sofern sinnvoll. Sollten die Ergebnisse eher einen Plan als eine Aufgabenliste erfordern, werden wir diesen gemeinsam mit Ihnen ausarbeiten.
Weiterhin Zugang zu den Ergebnissen. Ihre Befunde bleiben im Kundenportal verfügbar, einschließlich der Anträge auf Wiederholungsuntersuchungen.
Ihre Ergebnisse – alles an einem Ort
Jedes CREDS-Webanwendungsprojekt umfasst den Zugriff auf das Kundenportal. Dort wird der Test nicht mehr nur ein Dokument, sondern zu einer Arbeitsgrundlage, mit der Ihr Team arbeiten kann.
Aktuelle Ergebnisse
Die Ergebnisse werden im Portal veröffentlicht, sobald sie während des Tests festgestellt werden, zusammen mit Angaben zu den Auswirkungen und Empfehlungen zur Behebung.
Anträge auf erneute Prüfung
Wenn eine Korrekturmaßnahme umgesetzt wurde, fordern Sie über das Portal direkt eine erneute Prüfung des ursprünglichen Befunds an, damit die Überprüfung dem jeweiligen Problem zugeordnet und nicht in einer Tabellenkalkulation erfasst wird.
Integration des Ticket-Systems
Die Ergebnisse fließen in die Tools ein, mit denen Ihre Entwickler bereits arbeiten, darunter Jira und ServiceNow, sodass die Behebung von Mängeln in Ihren bestehenden Sprint-Prozess integriert wird und nicht in einem parallelen Prozess erfolgt.
Verlauf über alle Aufträge hinweg
Frühere Tests und deren Ergebnisse bleiben verfügbar, sodass Sie nachvollziehen können, was sich von einem Test zum nächsten geändert hat.
Nachprüfungen sind im Auftrag enthalten. Die Überprüfung, ob eine Korrektur tatsächlich funktioniert hat, verursacht Ihnen keine zusätzlichen Kosten.
Security that moves with your release schedule
Wir glauben, dass das Testen von Webanwendungen eine gemeinsame Reise ist.
Wir befurworten periodische Tests, die auf Ihre Entwicklungssprints und Release-Zeitplane abgestimmt sind.
Because findings flow into your ticket system and retests are requested from the portal, recurring testing fits your existing sprint process rather than sitting alongside it.
Fragen zum Testen von Webanwendungen
Testen Sie sowohl den API als auch das Frontend?
Welche Prüfstufe benötigen wir?
Benötigen Sie Zugriff auf unseren Quellcode?
Handelt es sich hierbei um einen automatisierten Test?
Nutzen Sie die Plattform ART zum Testen von Webanwendungen?
Woher wissen wir, dass die Prüfung gründlich durchgeführt wurde?
Was geschieht, wenn wir die Feststellungen behoben haben?
Können die Ergebnisse direkt an unsere Entwickler weitergeleitet werden?
Wie lange dauert ein Test?
Können Sie unsere DigiD-Bewertung unterstützen?
Werden wir bereits vor der Veröffentlichung des Berichts von schwerwiegenden Ergebnissen erfahren?
Sind Sie bereit, Ihre Anwendung zu testen?
Teilen Sie uns mit, welche Funktionen die Anwendung erfüllt und wie oft sie geändert wird, und wir sagen Ihnen, welche Teststufe geeignet ist und was dafür erforderlich ist.