Webanwendungen als Angriffsziel Was Scanner nicht sehen können

Anbieter zum Thema

FTAPI Software GmbH

Automatische Scanner finden Signaturen. Die Schwachstellen, die Engagements wirklich entscheiden, haben keine Signatur. Sie entstehen aus Anwendungslogik, aus vergessenen Endpunkten, aus Fehlern, die kein Regelwerk abbildet. Wer nur scannt, misst die Oberfläche.

Professionelles Pentesting beginnt nicht mit Scanning. Es beginnt damit, die Anwendung zu verstehen: Was soll sie tun, und was hat jemand dabei stillschweigend vorausgesetzt? Dabei ist es nicht das Ziel, möglichst viele technische Befunde zu produzieren, sondern die tatsächlichen Vertrauensgrenzen der Anwendung zu erkennen: Welche Daten, Funktionen und Systeme setzt sie als vertrauenswürdig voraus? Die relevante Angriffsfläche liegt oft nicht in offensichtlichen Formularfeldern, sondern in vergessenen Komponenten, impliziten Berechtigungen und technischen Details, die im Betrieb sichtbar werden.

Gerade Response-Header liefern oft mehr als erwartet. Server: Apache/2.4.29 gibt sofort verwertbare CVE-Informationen, X-Powered-By: PHP/7.2 schränkt die Angriffsfläche ein. Das Interessanteste taucht aber woanders auf: im JavaScript-Bundle versteckte API-Endpunkte, alte /api/v1/-Routen neben der aktuellen Version, exponierte Swagger-Dokumentationen. Manchmal ein Jenkins-Panel auf einer Subdomain, das nie öffentlich sein sollte. Burp Suite läuft währenddessen passiv mit.

API-Schwachstellen

3 API-Sicherheitsrisiken, die jeder Entwickler kennen muss

SQL Injection: Vertrauen in Eingaben, die niemand hinterfragt hat

SQL Injection taucht auf nahezu jedem Engagement auf. Selten in den Feldern, die das Entwicklungsteam für sensibel hält. Fast immer dort, wo die Logik komplizierter wird: Export-Endpunkte, interne Suchfunktionen, Admin-Backends. Genau dort, wo die Abfrage dynamisch zusammengebaut wird und niemand mehr genau weiß, wie.

ORM-Frameworks geben Entwicklern das Gefühl, automatisch geschützt zu sein. Sobald raw queries für Flexibilität eingebaut werden, öffnet sich das Fenster wieder. Das ist kein Ausnahmefall. Was regelmäßig übersehen wird sind Second-Order SQLi, JSON-basierte Injection in REST-APIs und GraphQL-Endpunkte mit aktivierter Introspection, die die vollständige interne Datenstruktur liefern. Das Problem ist nicht der Eingabekanal. Das Problem ist, dass die Anwendung Vertrauen auf Strings aufbaut, die der Benutzer kontrolliert.

Endpunkte ohne Authentifizierung

Hacker knachen McKinsey-KI „Lilli“ in nur 2 Stunden

Local File Inclusion: Wenn Dateilesen zur Credential-Harvest wird

LFI wird interessant, wenn die Validierung vorhanden zu sein scheint, aber nicht ausreicht. Der entscheidende Sprung ist nicht vom Dateilesen zum Payload, sondern zu den Credentials: .env-Dateien, SSH-Keys, Cloud-Credentials. Die Schwachstelle ist der Einstieg in das, was daneben liegt.

Die eigentliche Eskalation kommt durch Log Poisoning. PHP-Code wird über den User-Agent injiziert und über LFI eingebunden. Aus einer Dateilese-Schwachstelle wird Remote Code Execution:

Advens Threat Status Report

Neue Tricks beim Diebstahl von Zugangsdaten

XXS: Der Impact, den niemand modelliert hat

Cross-Site Scripting wird als niedriges Risiko eingestuft, bis jemand zeigt, was damit möglich ist. Stored XSS in einem internen Ticketsystem stiehlt Session-Cookies von Administratoren, die nie auf externe Links klicken würden. Die Schwachstelle kommt zu ihnen.

In modernen SPAs, die Tokens in localStorage ablegen statt in HttpOnly-Cookies, ist XSS direkter Zugriff auf den Auth-Token. DOM-basiertes XSS erkennen klassische Scanner kaum, weil der Payload nie den Server erreicht. Content-Security-Policy mit unsafe-inline bietet keinen Schutz. Diese Fehlkonfiguration ist in gewachsenen Anwendungen häufiger als erwartet, weil CSP irgendwann mit Ausnahmen aufgeweicht wurde.

Cloudflare Threat Report 2026

Session-Token-Diebstahl macht MFA wirkungslos

Wie Remote Code Execution wirklich auftaucht

Wenn Betriebssystembefehle auf dem Zielsystem ausführbar sind, ist das Testziel erreicht. Klassisch sind Funktionen, die Eingaben direkt an System-Calls übergeben. Häufiger in der Praxis ist Server-Side Template Injection:

Antwortet der Server mit 49, ist die Engine bestätigt. Datei-Uploads sind oft der direkteste Weg. Filter scheitern an doppelten Erweiterungen oder Content-Type-Manipulation. Daneben existiert manchmal noch ein „/debug/“-Endpunkt aus der Entwicklungsphase, der nie entfernt wurde. Kein Exploit nötig. Nur ein Endpunkt, den niemand mehr auf dem Radar hatte.

IDOR und JWT: Wenn Designannahmen zur Schwachstelle werden

Insecure Direct Object Reference ist eine Designentscheidung, die nie hinterfragt wurde. Die Anwendung gibt Objektreferenzen preis und vertraut darauf, dass Benutzer nur das anfragen, was ihnen gehört. In Legacy-Mobile-APIs, die formal abgekündigt sind, aber noch aktiv laufen, taucht das besonders oft auf.

JWT-Fehlkonfigurationen mit schwachen Secrets ermöglichen direkte Rollenmanipulation im Payload: JSON Web Token mit manipuliertem role-Claim, privilegierte Admin-API-Route, vollständige Rechteerweiterung. Kein Exploit nötig, nur ein Secret, das niemand als sensitiv behandelt hat. Viele SIEMs haben dafür keine aktive Regel.

Wenn Maschinen zu Zielen werden

Hacker hacken nicht mehr, sie loggen sich einfach ein

SSRF: Wenn der Server zum Angreifer wird

Server-Side Request Forgery zwingt den Zielserver, Anfragen im Namen des Angreifers auszuführen. Webhook-Funktionen, PDF-Generatoren und Import-Features sind die häufigsten Vektoren:

Ohne erzwungenes IMDSv2 liefert das IAM-Credentials zurück. Auch mit aktivem IMDSv2 ist der Vektor nicht vollständig geschlossen. In ECS- und Lambda-Umgebungen sowie bei SSRF über HTTP-Redirects greift der Hop-Limit-Schutz nicht. Ein realer Angriffspfad: SSRF auf eine EC2-Instance, Metadata ohne IMDSv2, IAM-Credentials mit S3-Berechtigung, Bucket mit Produktionsdaten. Drei konfigurative Versäumnisse, kein ausgefeilter Exploit. Diese Pfade bestehen aus Schritten, die einzeln wie Kleinkram wirken.

Neuer Ansatz für Cyber-Risikomanagement

Warum Exposure Management das Schwachstellen-Management ablöst

Die reale Angriffsfläche 2026

Die Unternehmen, bei denen Pentests heute den größten Impact haben, sind nicht die ohne Sicherheitskonzept. Es sind die mit einer Infrastruktur, die schneller gewachsen ist als die Inventur. Das kann bedeuten, dass Staging-Umgebungen öffentlich erreichbar sind, API-Versionen formal abgekündigt aber aktiv sind, CI/CD-Panels versehentlich aus dem Internet erreichbar sind.

Laut Bitkom-Wirtschaftsschutz-Studie 2025 verursachen Cyberangriffe auf die deutsche Wirtschaft jährlich Schäden von über 202 Milliarden Euro, der Gesamtschaden durch Datendiebstahl, Spionage und Sabotage liegt bei 289 Milliarden Euro. Der BSI-Lagebericht 2024 nennt Webanwendungen explizit als zentrale Angriffsziele neben Firewalls und VPN-Systemen. Das seit Dezember 2025 geltende NIS2-Umsetzungsgesetz verpflichtet betroffene Unternehmen zu Risikomanagementmaßnahmen und zur Meldung erheblicher Sicherheitsvorfälle.

Interview mit Dr. Jürgen Dürrwang, Head of Pentesting bei ITK Engineering

Pentesting ist geduldiges Handwerk und ein bisschen Kunst

Was CISOs und Sicherheitsverantwortliche jetzt tun sollten

• 1. Attack-Surface-Management systematisch betreiben. Wer nicht weiß, welche Endpunkte öffentlich erreichbar sind, kann sie nicht schützen. Dazu gehört eine vollständige Inventur aller exponierten Endpunkte, API-Versionen und Subdomains, auch der vergessenen. Einen praxisnahen Überblick bietet HackIta zu die häufigsten Angriffsvektoren auf Webanwendungen.

• 2. Manuelles Testing nicht durch Scanner ersetzen, sondern ergänzen. Logikfehler, Second-Order-Injection und IDOR haben keine Signatur. Sie entstehen aus Anwendungskontext, den nur ein erfahrener Tester rekonstruieren kann.

• 3. Endpunkt-Inventur regelmäßig aktualisieren. Staging-Umgebungen, abgekündigte API-Versionen und Debug-Routen bleiben oft aktiv, weil kein Prozess ihre Abschaltung erzwingt. Ein einfaches Inventar mit Verantwortlichkeit und Ablaufdatum reduziert diese Angriffsfläche strukturell.

• 4. Content-Security-Policy regelmäßig auditieren. Eine CSP mit unsafe-inline bietet keinen Schutz gegen XSS. In gewachsenen Anwendungen ist das die Regel, nicht die Ausnahme. Ein CSP-Audit kostet wenig und schließt eine der am häufigsten ausgenutzten Fehlkonfigurationen.

Webanwendungen scheitern nicht, weil ein Kontrollmechanismus fehlt. Sie scheitern, weil der Mechanismus im falschen Layer sitzt, zu spät greift oder nur die Oberfläche prüft. Der Angreifer findet das nicht durch Zufall. Er findet es, weil niemand sonst danach gesucht hat.

Über den Autor: Canio Campaniello ist Penetrationstester und Gründer von HackIta, einem Blog für offensive IT-Sicherheit. Schwerpunkte: Webanwendungen, Netzwerke und Active Directory.

Sicherheitslücken identifizieren und schließen

14 Tools für Penetrationstests von Webanwendungen

(ID:50903199)