Neu Das Whitepaper zur kontinuierlichen Sicherheitsvalidierung 2026 ist verfügbar. Whitepaper lesen →

Web — Angriff & Verteidigung kanonisch.

Jede Schwachstellenklasse als Angriffs-/Verteidigungs-Paar, mit Briefing-Übersicht und den Protokoll-/Header-/Encoding-Punkten, an denen Schwächen wiederkehren.

Klasse für Klasse — Angriff / Verteidigung / Detektionssignal

XSS

  • Angriff. HTML oder JS in eine Sink injizieren (innerHTML, document.write, Attribut, JS-String).
  • Verteidigung. Kontext-bewusstes Output-Encoding, strenge CSP (script-src 'self', kein unsafe-inline), Trusted Types in modernen Browsern.
  • Detektion. CSP-report-uri-Violations steigend, WAF-Regel OWASP CRS 941xxx feuernd, Requests mit <script oder onerror= in Parametern.

SQL Injection

  • Angriff. Unescaped-Konkatenation in SQL-String.
  • Verteidigung. Parameterized Queries. ORMs helfen nur, wenn du ihre Raw-Query-Escape-Hatches meidest.
  • Detektion. DB-Tier-Errors mit syntax error near; WAF-Regeln 942xxx; Queries mit UNION SELECT, SLEEP( oder '; --.

SSRF

  • Angriff. Server fetcht angreifer-gelieferte URL → interne Services, Cloud-Metadata.
  • Verteidigung. Allow-List von Destination-Hosts am Egress-Layer. RFC1918, 169.254/16, ::ffff:0:0/96, Link-Local denyen. Einmal auflösen, validieren, dann connecten — schlägt DNS-Rebinding.
  • Detektion. Outbound HTTP vom App-Tier zu 169.254.169.254, localhost, RFC1918. DNS-Queries auf Angreifer-Domains.

CSRF

  • Angriff. State-ändernder Request cross-origin getriggert.
  • Verteidigung. SameSite=Lax-Cookies (default in modernen Browsern), Anti-CSRF-Token an Session gebunden, Custom-Header-Requirement für JSON-APIs (erzwingt Preflight).
  • Detektion. Sensitive POSTs mit Origin/Referer von unerwarteten Hosts.

Deserialisierung

  • Angriff. Untrusted serialisiertes Objekt erreicht einen Deserialisierer mit verfügbaren Gadgets.
  • Verteidigung. Untrusted-Input nicht deserialisieren. Wenn nötig, format-only Serializer (JSON ohne typed Binding) und vor Unmarshaling validieren.
  • Detektion. JVM-/CLR-Exceptions mit InvocationTargetException; Child-Process gestartet aus App-Server-JVM.

File-Upload zu RCE

  • Angriff. Upload mit executable Extension, URL requesten, Server executes.
  • Verteidigung. Uploads auf einer Domain speichern, die nicht serverseitig ausführt; mit Content-Disposition: attachment ausliefern; niemals client-gelieferter MIME oder Extension trauen.
  • Detektion. Erstmalig gesehene File-Extensions in Upload-Dirs; Web-Server-Access-Logs hitten .php / .jsp / .aspx in User-Upload-Pfaden.

Protokoll- / Header- / Encoding-Hotspots

  • Set-Cookie-Attribute. Fehlendes Secure, HttpOnly oder falsches SameSite auf Session-Cookies. Domain-Attribut zu breit gescoped.
  • CSP-Lücken. script-src 'self' 'unsafe-inline' ist ein Feigenblatt. script-src https: trivial umgehbar via angreifer-kontrollierte HTTPS-Origin.
  • Content-Type-Sniffing. Browser ignoriert falschen Content-Type und rendert user-uploaded HTML. Verteidigung: X-Content-Type-Options: nosniff.
  • Reverse-Proxy-Encoding-Mismatch. nginx normalisiert ..%2f anders als Backend. Backend bekommt einen Path-Traversal, den Proxy-Normalisierung vor der WAF versteckt hat.
  • HTTP/2 → HTTP/1.1-Konvertierung. Pseudo-Header-Smuggling zwischen Front- und Back-End. Verteidigung: End-to-End H/2 oder strikte Re-Codierung am Gateway.
FaustregelVerteidigung ist eine System-Eigenschaft, keine Feature-Liste. Eine CSP ohne upgrade-insecure-requests und SameSite-Policy und Origin-Check ist keine CSP — sie ist ein Placebo. Beim Review die fehlende Schicht suchen.

Von der Referenz zum Befund

Validieren Sie das in Ihrer eigenen Umgebung.