Ich bin Fullstack-Entwickler und Application Security Engineer und prüfe Webanwendungen auf Schwachstellen. Der Unterschied zu einem automatisierten Scan: Ich verstehe die Anwendungslogik, statt nur Signaturen abzugleichen.
HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8
set-cookie: SESSID=8f2a…; Path=/
↑ ohne Secure, HttpOnly und SameSite
↑ keine Content-Security-Policy
↑ kein Strict-Transport-SecurityHeader sind der einfachste Teil. Die teuren Funde liegen darunter: in Berechtigungsprüfungen, Objektreferenzen und Session-Handling.
Ein großer Teil neuer Anwendungen entsteht heute mit KI-Unterstützung. Das Ergebnis läuft meist einwandfrei - und genau das ist das Problem: Funktionale Tests schlagen nicht an, wenn eine Berechtigungsprüfung fehlt.
Modelle erzeugen zuverlässig plausiblen Code, aber sie kennen Ihr Rollenmodell oftmals nicht. Sie wissen nicht, welcher Datensatz wem gehört, welche Prüfung ins Backend statt ins Frontend gehören würde, und welche Annahmen aus dem letzten Sprint inzwischen nicht mehr gelten. Was dabei entsteht, sind selten exotische Lücken, sondern die teuren Klassiker: fehlende Zugriffskontrolle, ungeprüfte Objektreferenzen, Validierung nur auf der Oberfläche.
Ich prüfe Code gegen die Logik, die er eigentlich abbilden soll entlang Ihres Rollen- und Berechtigungsmodells.
Kompakte Prüfung einer Anwendung gegen die häufigsten und teuersten Fehlerklassen: Zugriffskontrolle, Authentifizierung, Session-Handling, Eingabeverarbeitung, Konfiguration.
Ergebnis: Bericht mit reproduzierbaren Schritten, Risikoeinschätzung und konkreten Fixes im Code.
Ausführlicher, meist als Grey-Box mit Testzugängen über alle Rollen hinweg. Schwerpunkt auf Logikfehlern, die nur jemand findet, der versteht, was die Anwendung in seinem Kontext eigentlich tun soll. Außerdem Randfälle die ich aus meiner mehrjährigen Tätigkeit als FullStack Entwickler abdecken kann.
Methodisch orientiert am OWASP Web Security Testing Guide und am BSI-Durchführungskonzept für Penetrationstests.
Prüfung dessen, was von außen sichtbar ist: exponierte Verzeichnisse und Repositories, TLS-Konfiguration, Security-Header, verräterische Versionsangaben, offene Dienste.
Ein Bericht, den niemand umsetzt, hat nichts verbessert. Deshalb endet meine Arbeit nicht beim Fund. Zu jeder Schwachstelle liefere ich eine Anweisung, die Ihr Team direkt umsetzen kann: an welcher Stelle im Code die Ursache liegt, was sich ändern muss, und woran Sie erkennen, dass es wirkt. Formuliert so, dass sie auch trägt, wenn Ihre Entwickler dabei mit KI-Werkzeugen arbeiten - die Anweisung enthält den Kontext, den ein Modell braucht, um nicht am Symptom herumzureparieren.
Danach prüfe ich gerne nach. Kritische Befunde teste ich innerhalb von vier Wochen kostenfrei erneut. Erst danach ist ein Befund geschlossen, und erst dann kann er gegenüber Kunden oder einem Auditor auch belegt werden.
Welche Werkzeuge Sie dabei einsetzen, entscheiden Sie. Falls interne Richtlinien, ISO 27001 oder TISAX die Weitergabe von Quellcode an externe Dienste einschränken, klären wir das vorher.
Beauftragte, schriftlich autorisierte Prüfungen an produktiv eingesetzten Anwendungen - keine Übungsumgebungen. Anonymisiert dargestellt.
Das Unternehmen war in Sicherheitsfragen kein Anfänger. Es hatte zuvor extern prüfen lassen, die Befunde lagen vor, der Pflicht war Genüge getan. Trotzdem fand ich in beiden Anwendungen Kritisches: im Frontend hinterlegte Zugangsdaten, über die sich das dahinterliegende System erreichen ließ, und eine Kontoübernahme, die ohne Kenntnis der bisherigen Zugangsdaten funktionierte.
Die Ursachen waren nicht exotisch. Für die Behebung der damaligen Befunde blieb wenig Zeit. Seither kamen neue Funktionen hinzu, Abläufe änderten sich, und ein wachsender Teil des Codes entsteht mit KI-Unterstützung, ohne dass jemand dafür geschult wurde. Ein Prüfbericht beschreibt einen Zeitpunkt - die Anwendung entwickelt sich danach weiter.
Weitere Befunde aus beiden Prüfungen:
Die kritischen Funde habe ich sofort gemeldet; mit meiner Anweisung waren
sie innerhalb weniger Minuten geschlossen. Beide Prüfungen sind als
nachvollziehbarer Bericht dokumentiert, mit Reproduktionsschritten und
priorisierten Maßnahmen. Für die Aufklärungsphase habe ich mir eigene
Skripte gebaut (recon.sh, parse_findings.py), um
die Ergebnisse verschiedener Werkzeuge zusammenzuführen.
Beide Prüfungen sind praktisch aufgebaut: gelöst wird in Laborumgebungen, nicht im Multiple-Choice-Verfahren. Inhaltlich reichen sie von Netzwerk- und Web-Grundlagen über Angriffstechniken bis zu Log-Auswertung, Active Directory und forensischer Analyse mit SIEM Anwendungen für SOC.
Laufend: AI Security (AI1) sowie Vorbereitung auf das OSCP.
Wenn Sie wissen wollen, wie Ihre Anwendung gegen die üblichen Angriffe dasteht: eine kurze Mail mit ein paar Sätzen zur Anwendung genügt. Ich melde mich mit Rückfragen und einem Vorschlag zum Umfang.