Warum unauthentifizierte Scans die Hälfte übersehen

Die Fassade trügt

Ein unauthentifizierter Scan prüft, was ein anonymer Besucher sieht: die öffentliche Startseite,

ein paar Endpunkte, vielleicht ein Login-Formular. Das ist nützlich — aber es ist die Fassade.

Die wirklich kritischen Schwachstellen — **Broken Access Control, IDOR, Privilege Escalation,

Business-Logik-Fehler — leben dort, wo Funktionalität ist: hinter der Anmeldung.**

Was hinter dem Login passiert

Eingeloggt wird die Angriffsfläche um ein Vielfaches größer: Profil-Endpunkte, Admin-Funktionen,

Datei-Uploads, API-Aktionen, Mehrschritt-Workflows. Genau hier entstehen die Lücken mit dem höchsten

Schadenspotenzial — und genau hier ist ein anonymer Scanner blind.

Wie agentschmitz hinter die Anmeldung kommt

Sie geben dem Agenten einfach Login-URL, Benutzername und Passwort. Der Agent:

1. ruft die Login-Seite auf und erkennt die Felder sowie einen eventuellen CSRF-Token automatisch,

2. meldet sich an und übernimmt das Session-Cookie,

3. testet anschließend als eingeloggter Nutzer weiter.

Alternativ lässt sich auch ein fertiges Session-Cookie oder ein Bearer-Token hinterlegen.

Der Unterschied im Ergebnis

In der Praxis ist der Sprung enorm: Erst mit gültiger Session findet der Agent IDORs in

/api/users/{id}, erreichbare Admin-Bereiche und Daten, die für anonyme Besucher unsichtbar sind.

Wer nur von außen testet, übersieht die Hälfte — oft die wichtigere Hälfte.

Den Test-Zugang richtig vorbereiten

Für einen authentifizierten Test brauchen Sie einen Zugang — aber bitte nicht Ihren eigenen

Admin-Account. Bewährt hat sich:

• Eigenes Testkonto anlegen, das nur für den Pentest genutzt wird.
• Realistische Rolle wählen: Testen Sie mit den Rechten eines normalen Nutzers, denn genau

dort entstehen die meisten Lücken bei der Zugriffskontrolle.

• Zwei Konten für Zugriffstests: Mit zwei gleichberechtigten Testkonten lässt sich prüfen, ob

ein Nutzer an die Daten eines anderen herankommt.

• Testdaten statt Echtdaten: Befüllen Sie die Testkonten mit Beispieldaten.
• Zugang danach deaktivieren oder das Passwort ändern, wenn der Test abgeschlossen ist.

Typische Lücken hinter dem Login

Hinter der Anmeldung liegen oft die sensibelsten Funktionen einer Anwendung: Profile,

Bestellungen, Rechnungen, Dokumente und Einstellungen. Typische Schwachstellen dort sind:

• Fehlende Zugriffskontrolle: Ein Nutzer sieht oder ändert Daten eines anderen.
• Erreichbare Admin-Funktionen: Verwaltungsbereiche sind nicht ausreichend abgesichert.
• Unsichere Sitzungen: Sessions laufen nicht ab oder sind schlecht geschützt.
• Zu viele Daten in API-Antworten: Die Oberfläche zeigt wenig, die API liefert mehr.

Häufige Fragen

Ist es riskant, Zugangsdaten zu hinterlegen?

Nutzen Sie ein eigenes Testkonto mit begrenzten Rechten und Testdaten. So bleibt das Risiko

gering, und Sie können den Zugang nach dem Test einfach deaktivieren.

Was ist mit Zwei-Faktor-Authentifizierung?

Für automatisierte Tests sollte das Testkonto ohne zweiten Faktor auskommen oder alternativ ein

gültiges Session-Cookie hinterlegt werden.

Testet der Agent dann auch den Login selbst?

Ja, Anmelde- und Registrierungsabläufe gehören zu den geprüften Bereichen — auch ohne Zugang.