Webanwendungen prüfen
Frontend, Backend und die Schnittstellen dahinter, manuell geprüft entlang des OWASP Web Security Testing Guide. Mit Reproduktionsschritten und Nachtest.
Frontend, Backend und alles dazwischen
Ein Web-Penetrationstest ist der beauftragte Versuch, in eine Webanwendung einzudringen. Geprüft werden die Anwendung selbst, die Schnittstellen dahinter und die Dienste, auf denen beide laufen. Geprüft wird auf denselben Wegen, die ein Angreifer nehmen würde. Andere Namen für dasselbe: Web-Pentest, Web Application Penetration Testing, Pentest für Webanwendungen und APIs.
Ein Web-Pentest prüft die Anwendung, die Dienste dahinter und die Wege, auf denen beide miteinander sprechen. Frontend, Backend, Datenbank und Schnittstellen, weil eine Lücke selten dort liegt, wo die Oberfläche sie vermuten lässt.
Wir arbeiten manuell und mit Werkzeugen. Der automatisierte Durchlauf findet das Bekannte und liefert die Fläche; die Befunde, auf die es ankommt, entstehen danach von Hand. Als Prüfrahmen dienen der OWASP Web Security Testing Guide, die BSI-Vorgaben und OSSTMM.
Ob wir den Quelltext sehen, entscheiden Sie. Ohne Einblick prüfen wir wie ein externer Angreifer, mit Einblick kommen wir tiefer und schneller. Für Eigenentwicklungen ist der zweite Weg meistens der wirtschaftlichere.
Eine Eingabe, die zur Abfrage wird
Ein Suchfeld in einem Shop nimmt entgegen, was jemand hineinschreibt, und reicht es an die Datenbank weiter. Steht dort statt eines Artikelnamens ein Anführungszeichen und eine immer wahre Bedingung, antwortet die Datenbank mit allem, was sie hat.
Das ist der Klassiker, und er kommt weiterhin vor, meistens an der einen Stelle, die jemand später nachgerüstet hat: ein Filter, ein Export, eine Suche über zwei Tabellen. Der Rahmen dafür sind die OWASP Top 10 und der ASVS, an dem sich auch nachweisen lässt, welche Prüftiefe erreicht wurde.
Was ein Web-Pentest abdeckt
Der OWASP Web Security Testing Guide gliedert die Prüfung in elf Kategorien. Hier stehen sie in fünf Gruppen, damit die Liste lesbar bleibt; im Bericht ist jeder Befund seiner Kategorie zugeordnet. Was in Ihrem Fall schwerer wiegt, hängt von der Anwendung ab.
Anmeldung, Sitzung, Berechtigung
Ob sich eine Sitzung übernehmen lässt, ob ein Benutzer an fremde Daten kommt, ob eine administrative Funktion ohne die passende Rolle erreichbar ist. Dazu Kennwortregeln, zweiter Faktor und die Frage, wie viele Versuche eine Anmeldung zulässt. Hier liegen die Befunde mit den größten Folgen.
Eingaben und Daten
SQL- und NoSQL-Injection, Cross Site Scripting in allen drei Formen, Angriffe auf XML, Path Traversal, Datei-Uploads, Deserialisierung, Server Side Request Forgery. Alles, was aus einer Eingabe eine Anweisung macht, dazu Fehlermeldungen, die mehr verraten als nötig.
Anwendungslogik und Client
CSRF und Clickjacking, die Fälle, in denen ein Ablauf sich in einer Reihenfolge durchlaufen lässt, die niemand vorgesehen hat, und die clientseitige Hälfte: DOM-basierte Angriffe, CORS-Regeln, Nachrichten zwischen Fenstern. Für diese Klasse gibt es keinen Scanner.
Konfiguration und Bereitstellung
Server- und Frameworkkonfiguration, Sicherheits-Header, Verzeichnislisten, vergessene Verwaltungsoberflächen, Sicherungsdateien und Testumgebungen, die mit ausgeliefert wurden. Der häufigste Befund, der nichts mit dem Code zu tun hat.
Kryptographie und Komponenten
Transportverschlüsselung und ihre Einstellungen, der Umgang mit Geheimnissen und Sitzungsmerkmalen, veraltete Verfahren. Dazu der Aktualisierungsstand der eingesetzten Bibliotheken und Frameworks, weil eine bekannte Lücke in einer Abhängigkeit genauso zählt wie eine eigene.
Einzeln harmlos, verkettet die Übernahme
Drei Befunde mit niedriger Bewertung können zusammen zur Ausführung von Code auf dem Server führen. Ein Upload ohne Typprüfung. Ein Pfad, der sich manipulieren lässt. Eine Fehlermeldung, die den Speicherort verrät. Für sich genommen steht jeder dieser Punkte weit unten in der Liste.
Deshalb enden unsere Tests nicht mit dem Befund, sondern mit dem Versuch, ihn weiterzuverwenden. Im Bericht steht dann die Kette mit ihren Schritten und die Bewertung richtet sich nach dem, was am Ende erreichbar war.
Ein Scanner kann das nicht leisten. Er bewertet jeden Fund für sich und genau die Verbindung dazwischen ist der Teil, für den ein Mensch am Test sitzt.
Wie ein Web-Pentest abläuft
Fünf bis zehn Tage, abhängig von Umfang und Anzahl der Rollen.
Verstehen
Die Anwendung wird zuerst benutzt: welche Funktionen gibt es, welche Rollen, wo entstehen Daten. Ohne diesen Schritt prüft man Formulare statt Abläufe.
Einstiegspunkte aufnehmen
Jeder Parameter, jeder Upload, jede Schnittstelle. Bei modernen Anwendungen liegt der größere Teil in der API dahinter.
Prüfen und verketten
Die Klassen aus dem OWASP Web Security Testing Guide, jeweils manuell nachgestellt und bestätigt. Anschließend der Versuch, die Funde zu verbinden.
Bericht
Jeder Befund mit Reproduktionsschritten, Bewertung nach vereinbartem Schema und einem Weg zur Behebung, der zur Anwendung passt.
Nachtest
Nach der Behebung prüfen wir dieselben Befunde erneut. Erst das macht aus dem Bericht einen Nachweis.
Von der Eigenentwicklung bis zum Shop
Selbst entwickelte Anwendungen und Portale, Content-Management-Systeme wie Drupal, TYPO3 oder WordPress, Shop-Systeme, Progressive Web Apps und die Schnittstellen, die dahinter liegen. Bei Standardsoftware verschiebt sich der Schwerpunkt auf Konfiguration, Erweiterungen und Aktualisierungsstand, weil der Kern von vielen geprüft wird und Ihre Anpassungen von niemandem.
Ist die Schnittstelle der größere Teil, prüfen wir sie im selben Auftrag mit.
Ein Bericht, mit dem Ihr Team weiterarbeiten kann.
Jeder Befund kommt eingeordnet: mit Risiko, Aufwand und dem Weg zur Behebung.
Management Summary
Die Lage auf einer Seite, verständlich für Geschäftsführung und Aufsicht.
Technische Findings
Jeder Befund mit eindeutiger Befund-ID, Nachweis und Reproduktionsschritten.
Risikobewertung nach BSI
Eine nachvollziehbare Einstufung jedes Funds nach anerkanntem Schema.
Priorisierte Empfehlungen
Konkrete Handlungsempfehlungen in der Reihenfolge, in der sie wirken.
Abschlussgespräch
Auf Wunsch eine gemeinsame Durchsprache der Ergebnisse mit Ihren Fachteams.
Retest
Auf Wunsch die erneute Prüfung der behobenen Schwachstellen, mit Bestätigung des Stands.
Was wir brauchen und was nicht dazugehört
Von Ihnen brauchen wir die Adressen der zu prüfenden Anwendung, ein Benutzerkonto je Rolle, einen Ansprechpartner für die Dauer des Tests und eine schriftliche Freigabe. Liegt die Anwendung bei einem Betreiber, holen wir dessen Erlaubnis gemeinsam mit Ihnen ein. Gibt es eine Testumgebung, prüfen wir dort; sonst im Produktivsystem mit abgestimmten Einschränkungen.
Nicht enthalten sind Angriffe auf Menschen und Verfügbarkeit. Phishing-Simulationen und Social Engineering sind eigene Leistungen, Lasttests und Denial-of-Service führen wir nicht durch. Der Server unter der Anwendung gehört in den externen Penetrationstest, eine Schnittstelle, die für sich steht, in den API-Test. Eine Quelltextprüfung ist kein Pentest, sondern eine eigene Leistung, die sich gut damit verbindet.
Häufige Fragen zu Web-Pentests
Der gezielte Versuch, in eine Webanwendung einzudringen, unter Auftrag und in einem abgestimmten Rahmen. Geprüft werden Anwendung, Schnittstellen und die Dienste dahinter und zwar entlang derselben Wege, die ein Angreifer nehmen würde.
Das Ergebnis ist eine Liste von Befunden mit Reproduktionsschritten und einer Bewertung, was damit erreichbar war. Die Prüfung führen zertifizierte Testerinnen und Tester durch, die Befunde entstehen von Hand.
Selbst entwickelte Anwendungen und Portale, Progressive Web Apps, Schnittstellen wie REST und GraphQL, Content-Management-Systeme wie Drupal, TYPO3 oder WordPress, Shop-Systeme und Baukästen.
Bei Standardsoftware verschiebt sich der Schwerpunkt: Der Kern wird von vielen geprüft, Ihre Erweiterungen, Ihre Konfiguration und Ihr Aktualisierungsstand von niemandem. Dort liegen die Befunde.
Die Klassen aus dem OWASP Web Security Testing Guide. Am häufigsten: SQL- und NoSQL-Injection, Cross Site Scripting in allen drei Formen, Cross Site Request Forgery, Fehler in Anmeldung und Berechtigung, Path Traversal, ungeprüfte Datei-Uploads, Deserialisierung und Server Side Request Forgery.
Der Befund mit den größten Folgen ist meistens die Berechtigung: ein angemeldeter Benutzer, der an Daten kommt, die ihn nichts angehen.
Vor dem Produktivgang einer neuen Anwendung, nach größeren Änderungen an Funktionen oder Architektur, nach einem Sicherheitsvorfall und danach wiederkehrend einmal jährlich.
Bei Anwendungen, die häufig ausgeliefert werden, ist ein kleinerer Test je Release wirksamer als ein großer im Jahr. Für Nachweise nach NIS-2 oder gegenüber Kunden zählt der wiederkehrende Rhythmus.
In sechs Schritten. Kennenlernen: Ziele, Umfang und Rahmen werden festgelegt, samt der Frage, welches System wie geprüft wird. Aufklärung: Aufbau, eingesetzte Technik und Funktionen werden aufgenommen. Prüfung: Die Einstiegspunkte werden gezielt angegriffen, Befunde bestätigt und miteinander verkettet.
Dokumentation: Jeder Befund mit Reproduktionsschritten, Bewertung und Weg zur Behebung. Präsentation: Vorstellung für Team und Leitung, mit Raum für Rückfragen. Nachtest: Nach der Behebung prüfen wir dieselben Befunde erneut.
An nachweisbarer Praxis. Im Web-Umfeld sind OSCP und OSWE die Zertifizierungen mit praktischer Prüfung: Wer sie hat, musste Schwachstellen unter Zeitdruck finden und ausnutzen, statt Fragen anzukreuzen.
Dazu die Fragen, die ein Angebot beantworten sollte: Wird manuell geprüft oder ein Scanner ausgeliefert, gibt es eine Gegenprüfung des Berichts, ist ein Nachtest enthalten und werden Referenzen aus vergleichbaren Umgebungen genannt.
Sie beantworten eine Frage, die sich sonst nur im Schadensfall beantwortet: Was ist mit dieser Anwendung tatsächlich erreichbar. Ein Scanner liefert eine Liste möglicher Probleme, ein Test zeigt, welche davon zusammen zu einem Zugriff führen.
Konkret entsteht daraus dreierlei: eine Reihenfolge für die Behebung statt einer Liste, ein Nachweis gegenüber Kunden und Aufsicht und für Ihr Entwicklungsteam der Befund samt Weg dorthin, an dem sich dieselbe Klasse von Fehlern künftig vermeiden lässt.
Wenn es eine vollständige Testumgebung gibt, dort. Sonst im Produktivsystem mit abgestimmten Einschränkungen: keine Massenmails, keine Bestellungen, keine Lasttests. Was wir verändern, protokollieren wir und machen es rückgängig.
Ja und am besten je Rolle eines. Ohne Anmeldung lässt sich nur prüfen, was ohnehin öffentlich ist. Die Befunde zur Berechtigung entstehen erst im Vergleich zwischen zwei Konten.
Bei einer modernen Anwendung ist sie der größere Teil und wir prüfen sie im selben Auftrag mit, wenn Frontend und Backend zusammengehören. Steht die Schnittstelle für sich, etwa als Produkt für Partner, ist ein eigener API-Test der passendere Weg.
Der Aufwand richtet sich nach der Zahl der Funktionen, der Rollen und der Schnittstellen. Eine kleinere Anwendung liegt bei fünf Tagen, ein Portal mit mehreren Mandanten und Schnittstellen deutlich darüber.
Für eine erste Einordnung genügt ein Gespräch von dreißig Minuten, in dem wir uns die Anwendung zeigen lassen. Auf der Übersichtsseite zu Penetrationstests steht außerdem ein Rechner für einen Richtwert.
Zertifizierungen und Mitgliedschaften.
Sprechen Sie mit uns.
Ein erstes Gespräch dauert in der Regel 30 Minuten. Wir schauen uns Ihre Ausgangslage an und sagen offen, ob wir der passende Partner sind.