🔒 Sicherheit im Web

1. Was bedeutet Web-Sicherheit?

Web-Sicherheit schützt Anwendungen, Benutzerkonten, Daten und Geschäftsprozesse vor unbefugtem Zugriff, Manipulation, Offenlegung und Ausfall. Sie umfasst Code, Konfiguration, Infrastruktur, Berechtigungen, Betrieb und Reaktion auf Vorfälle.

Die drei Säulen der Web-Sicherheit

• Prävention: Sichere Architektur, Code, Konfiguration und Updates
• Detektion: Überwachung, Logging, Alarmierung und Schwachstellenscans
• Reaktion: Notfallplan, Backups, Isolation, Analyse und Wiederherstellung

2. Schutzziele und Defense in Depth

Die Sicherheit einer Webanwendung lässt sich anhand der klassischen Schutzziele bewerten. Diese sollten bei jeder Entscheidung mitgedacht werden.

Defense in Depth – Mehrere Schutzschichten

Beispiel für Defense in Depth bei einer Anmeldung

• HTTPS schützt die Verbindung (Transportebene)
• Passwort-Hashing schützt die gespeicherten Daten (Speicherebene)
• MFA bietet zusätzliche Absicherung (Authentifizierungsebene)
• Rate Limiting schützt vor automatisierten Angriffen (Betriebsebene)
• Logging und Alarmierung erkennen Auffälligkeiten (Überwachungsebene)

3. OWASP Top 10:2025 im Detail

Die OWASP Top 10 ist ein Sensibilisierungsdokument für bedeutende Risiken von Webanwendungen. Sie ist ein guter Einstieg, ersetzt aber keine vollständige Risikoanalyse oder einen Prüfstandard.

Wie du mit der OWASP Top 10 arbeitest

1. 1
   VerstehenLies die Beschreibungen und Beispiele der einzelnen Risiken.
2. 2
   BewertenPrüfe, ob das Risiko für deine Anwendung relevant ist.
3. 3
   PriorisierenBehandle zuerst die Risiken mit hoher Auswirkung und hoher Wahrscheinlichkeit.
4. 4
   UmsetzenPlane konkrete Gegenmaßnahmen – nicht nur technisch, sondern auch organisatorisch.
5. 5
   PrüfenTeste die Wirksamkeit und überwache kontinuierlich – Sicherheit ist ein Prozess.

4. HTTPS, TLS und HSTS

HTTPS verwendet TLS, um die Verbindung zwischen Browser und Server zu verschlüsseln, ihre Integrität zu schützen und die Identität des angesprochenen Servers anhand des Zertifikats zu prüfen.

Wie TLS funktioniert (vereinfacht)

HSTS als zusätzliche Transportregel

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS weist Browser an, zukünftige Verbindungen zu diesem Host nur per HTTPS aufzubauen. includeSubDomains darf erst aktiviert werden, wenn wirklich alle Subdomains dauerhaft HTTPS unterstützen.

HSTS-Preloading

Für noch mehr Sicherheit kann die Domain in die HSTS-Preload-Liste der Browser aufgenommen werden. Dann vertrauen Browser schon beim ersten Besuch darauf, dass die Seite nur HTTPS verwendet – ohne jemals einen HTTP-Request zu senden.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

5. Authentifizierung und Zugriffskontrolle

Authentifizierung prüft, wer jemand ist. Autorisierung entscheidet, was diese Identität tun darf. Jede geschützte Aktion benötigt eine serverseitige Berechtigungsprüfung.

Grundregeln für Zugriffsschutz

• Standardmäßig verweigern und nur benötigte Rechte erlauben.
• Jede Anfrage serverseitig prüfen, nicht nur Menüpunkte verstecken.
• Objektberechtigungen prüfen: Darf Benutzer A genau Datensatz B sehen?
• Administrative Funktionen getrennt und besonders stark schützen.
• Berechtigungsänderungen protokollieren und regelmäßig überprüfen.
• Fehler sicher schließen: Bei Unsicherheit Zugriff ablehnen.

Rollenbasierte Zugriffskontrolle (RBAC)

6. Passwörter und Mehrfaktor-Anmeldung

Passwörter bleiben ein zentraler Bestandteil der Authentifizierung – aber sie allein reichen nicht mehr aus. Eine Kombination aus starken Passwörtern und Mehrfaktor-Authentifizierung (MFA) ist heute der Mindeststandard.

Passwörter sicher speichern

Passwörter werden niemals im Klartext oder reversibel verschlüsselt gespeichert. Verwende die etablierte Passwort-API des Frameworks mit einem langsamen Passwort-Hashing-Verfahren wie Argon2id, bcrypt oder PBKDF2 und individuellen Salts.

NICHT: datenbank.passwort = passwort_im_klartext
NICHT: datenbank.passwort = sha256(passwort)

RICHTIG: hash = framework.password_hash(passwort)
PRÜFEN: framework.password_verify(passwort, hash)

Was ist ein gutes Passwort?

• Länge: Mindestens 12 Zeichen, besser 16 oder mehr
• Einzigartigkeit: Für jeden Dienst ein eigenes Passwort
• Passphrasen: Mehrere Wörter kombiniert (z.B. BlauerHimmel22!Hund)
• Keine persönlichen Informationen: Namen, Geburtsdaten oder häufige Wörter vermeiden
• Passwortmanager: Empfohlen, um starke, einzigartige Passwörter zu verwalten

Mehrfaktor-Authentifizierung (MFA)

• Wissen: Passwort, PIN oder Sicherheitsfrage
• Besitz: Smartphone (TOTP), Sicherheits-Key (FIDO2) oder SMS (weniger sicher)
• Inhärenz: Fingerabdruck, Gesichtserkennung oder Iris-Scan

MFA kombiniert mindestens zwei dieser Faktoren. Besonders sicher sind FIDO2/WebAuthn (phishing-resistente Sicherheitsschlüssel).

7. Sitzungen und Cookies

Nach der Anmeldung hält eine Sitzung den authentisierten Zustand. Eine gestohlene Sitzungskennung kann deshalb ähnlich kritisch sein wie gestohlene Zugangsdaten.

Set-Cookie: session=zufaelliger_wert; Secure; HttpOnly; SameSite=Lax; Path=/

Weitere Sitzungsregeln

• Framework-Sitzungsverwaltung statt Eigenbau verwenden.
• Sitzungskennung nach Anmeldung und Rechtewechsel erneuern.
• Leerlauf- und absolute Zeitbegrenzung serverseitig durchsetzen.
• Abmeldung und Ablauf müssen die Sitzung serverseitig ungültig machen.
• Sitzungskennungen nicht in URLs, Logs oder Fehlermeldungen aufnehmen.
• Bei sensiblen Aktionen (z.B. Passwortänderung) erneute Authentifizierung verlangen.

8. Eingabevalidierung und kontextbezogene Ausgabecodierung

Validierung prüft, ob eine Eingabe fachlich und technisch zulässig ist. Ausgabecodierung sorgt dafür, dass Daten im jeweiligen Ausgabekontext als Text und nicht als ausführbarer Code interpretiert werden.

Beispiele für kontextbezogene Codierung

Eingabevalidierung – Best Practices

• Erlaubnislisten (Allowlists): Definiere, was erlaubt ist – lehne alles andere ab.
• Typ-Prüfung: Stelle sicher, dass Zahlen wirklich Zahlen sind, E-Mails dem Format entsprechen, etc.
• Längenbegrenzung: Begrenze Eingaben auf sinnvolle Längen, um Pufferüberläufe und Denial-of-Service zu verhindern.
• Format-Prüfung: Nutze reguläre Ausdrücke für erwartete Formate (z.B. Postleitzahl, Telefonnummer).
• Serverseitige Validierung: Client-seitige Validierung ist nett – aber die serverseitige ist entscheidend.

9. SQL-Injection verhindern

SQL-Injection entsteht, wenn unvertrauenswürdige Daten durch Stringverkettung Teil der SQL-Syntax werden. Die wichtigste Abwehr ist die Trennung von Abfragestruktur und Daten über parametrisierte Abfragen.

# Unsicher: Eingabe wird Teil des SQL-Strings
sql = "SELECT id, name FROM kunden WHERE email = '" + email + "'"
cursor.execute(sql)

# Sicherer Ansatz: Platzhalter und getrennte Parameter
sql = "SELECT id, name FROM kunden WHERE email = ?"
cursor.execute(sql, (email,))

Weitere Beispiele für sichere Abfragen

-- PHP mit PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$email]);

-- Java mit JDBC
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE email = ?");
stmt.setString(1, email);
ResultSet rs = stmt.executeQuery();

-- C# mit ADO.NET
SqlCommand cmd = new SqlCommand("SELECT * FROM Users WHERE Email = @email", conn);
cmd.Parameters.AddWithValue("@email", email);

-- Node.js mit mysql2
const [rows] = await connection.execute(
    'SELECT * FROM users WHERE email = ?',
    [email]
);

Zusätzliche Schutzmaßnahmen

• ORM oder Datenbank-API korrekt und parametrisiert verwenden.
• Dynamische Tabellennamen oder Sortierspalten über feste Erlaubnislisten wählen.
• Datenbankkonto nach Minimalprinzip berechtigen (nur SELECT, INSERT, UPDATE, DELETE, was wirklich nötig ist).
• Detaillierte Datenbankfehler nicht an Besucher ausgeben (verwende generische Fehlermeldungen).
• Validierung ergänzen, aber nicht als Ersatz für Parameterbindung betrachten.
• Regelmäßige Schwachstellenscans durchführen.

10. XSS – Cross-Site Scripting verhindern

Bei XSS werden unvertrauenswürdige Inhalte so in eine Seite eingebunden, dass der Browser sie als aktiven Inhalt interpretiert. Mögliche Folgen reichen von manipulierten Ansichten bis zur Übernahme angemeldeter Aktionen.

Arten von XSS

• Reflektiert (Non-Persistent): Die schädliche Eingabe wird sofort in der Antwort reflektiert – z.B. über URL-Parameter.
• Gespeichert (Persistent): Die schädliche Eingabe wird in der Datenbank gespeichert und bei jedem Seitenaufruf ausgeliefert – z.B. in Kommentaren.
• DOM-basiert: Die Schwachstelle liegt im client-seitigen JavaScript, nicht auf dem Server – z.B. bei unsicherer Verwendung von document.write oder innerHTML.

const ausgabe = document.getElementById("ausgabe");

// Unsicher bei unvertrauenswürdigen Daten
ausgabe.innerHTML = benutzertext;

// Sicher für reine Textausgabe
ausgabe.textContent = benutzertext;

Schutzschichten gegen XSS

• Automatische Ausgabecodierung des Frameworks nicht umgehen.
• Kontextbezogen codieren: HTML ist nicht dasselbe wie URL oder JavaScript.
• Für reinen Text sichere DOM-APIs wie textContent verwenden.
• Wenn HTML fachlich nötig ist, eine bewährte Sanitizing-Lösung einsetzen (z.B. DOMPurify im Frontend, HTMLPurifier im Backend).
• Eine strenge CSP als zusätzliche Schadensbegrenzung einführen.
• HttpOnly-Cookies für Sitzungskennungen verwenden (erschwert Diebstahl durch XSS).

// Erlaubtes HTML bereinigen
const sauberesHTML = DOMPurify.sanitize(rohesHTML, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
    ALLOWED_ATTR: ['href', 'target']
});
ausgabe.innerHTML = sauberesHTML;

11. CSRF verhindern

Cross-Site Request Forgery nutzt aus, dass ein Browser Authentifizierungs-Cookies automatisch mitsendet. Eine fremde Seite versucht dadurch, im Namen eines angemeldeten Benutzers eine zustandsändernde Aktion auszulösen.

CSRF-Schutzmaßnahmen

• Eingebauten CSRF-Schutz des Frameworks verwenden.
• CSRF-Token bei zustandsändernden Anfragen serverseitig validieren.
• SameSite-Cookies passend konfigurieren (Strict oder Lax).
• Origin, Fetch Metadata oder geeignete benutzerdefinierte Header als zusätzliche Ebene prüfen.
• GET nur für lesende, nebenwirkungsfreie Operationen verwenden.
• Besonders kritische Aktionen erneut bestätigen beziehungsweise reauthentisieren.
• Double-Submit-Cookies als zusätzliche Schutzebene.

<form method="post" action="/profil/aktualisieren">
    <input type="hidden" name="csrf_token" value="SERVER_GENERATED_TOKEN">
    <!-- weitere Formularfelder -->
</form>

// Beispiel: CSRF-Token prüfen (Konzept)
if (request.method === 'POST') {
    const token = request.body.csrf_token;
    if (!token || token !== session.csrf_token) {
        throw new Error('CSRF-Schutz: Ungültiges Token');
    }
    // Aktion ausführen
}

12. Sicherheits-Header und Content Security Policy

HTTP-Antwortheader können Browserfunktionen begrenzen und zusätzliche Schutzschichten aktivieren. Sie müssen zur Anwendung passen und sollten zunächst in einer Testumgebung geprüft werden.

Content Security Policy (CSP) im Detail

CSP ist ein mächtiger Mechanismus, der festlegt, welche Ressourcen die Seite laden darf. Eine gut konfigurierte CSP kann XSS, Clickjacking und andere Angriffe erschweren.

Strenger Ausgangspunkt für eine einfache Seite

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  style-src 'self';
  img-src 'self' data:;
  font-src 'self';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  form-action 'self'

CSP mit Nonces für dynamische Skripte

Content-Security-Policy:
  script-src 'nonce-ABC123' 'strict-dynamic';

CSP-Reporting

Mit Content-Security-Policy-Report-Only kannst du CSP ohne Blockierung testen. Verletzungen werden an eine konfigurierte Report-URI gesendet.

Content-Security-Policy-Report-Only:
  default-src 'self';
  report-uri /csp-report

13. Datei-Uploads absichern

Datei-Uploads verbinden unvertrauenswürdige Inhalte mit Dateisystem, Parsern und späteren Downloads. Dateiendung und vom Browser gemeldeter Content-Type reichen für eine sichere Entscheidung nicht aus.

1. 1
   Berechtigung prüfenNur authentisierte und autorisierte Benutzer dürfen hochladen.
2. 2
   Erlaubnisliste verwendenNur fachlich benötigte Dateitypen, Größen und Mengen akzeptieren.
3. 3
   Inhalt prüfenEndung, erkannter Typ, Signatur (Magic Bytes) und erwartete Struktur gemeinsam bewerten.
4. 4
   Namen neu vergebenServerseitig erzeugte Namen verwenden und Pfade nicht aus Benutzereingaben bilden.
5. 5
   Getrennt speichernMöglichst außerhalb des Webroots oder auf getrenntem Speicherdienst ohne Ausführungsrechte.
6. 6
   Auslieferung kontrollierenBerechtigungen erneut prüfen und sichere Content-Type- sowie Download-Header senden.
7. 7
   ScannenWenn möglich, Dateien mit Virenscanner oder Malware-Erkennung prüfen.

Dateityp-Prüfung – Magic Bytes

# Magic-Bytes für häufige Dateitypen
MAGIC_BYTES = {
    b'\xFF\xD8\xFF': 'jpg',
    b'\x89\x50\x4E\x47\x0D\x0A\x1A\x0A': 'png',
    b'\x25\x50\x44\x46': 'pdf',
    b'\x50\x4B\x03\x04': 'zip',
}

def pruefe_dateityp(datei_pfad):
    mit open(datei_pfad, 'rb') als f:
        header = f.read(8)
    für magic, typ in MAGIC_BYTES.items():
        wenn header.startswith(magic):
            gib typ zurück
    gib None zurück  # Unbekannter Typ

14. Secrets und Software-Abhängigkeiten

Moderne Webanwendungen bestehen aus vielen Komponenten – jede davon kann eine Schwachstelle sein. Secrets und Abhängigkeiten müssen aktiv verwaltet werden.

Secrets sicher verwalten

• Secrets niemals im Quellcode oder in Versionskontrolle ablegen.
• Umgebungsvariablen oder Secrets-Management-Dienste verwenden (z.B. HashiCorp Vault, AWS Secrets Manager).
• Regelmäßig rotieren – besonders bei Personalwechsel oder vermutetem Kompromiss.
• Zugriff auf Secrets protokollieren und nach Minimalprinzip beschränken.
• Automatische Scans auf Secrets in Commits (z.B. git-secrets, truffleHog).

Abhängigkeiten sicher verwalten

• Ein Lockfile (z.B. package-lock.json, poetry.lock) sorgt für reproduzierbare Builds.
• Regelmäßige Schwachstellen-Scans (z.B. npm audit, Dependabot, Snyk).
• Abhängigkeiten nur aus vertrauenswürdigen Quellen beziehen (z.B. offizielle Registry).
• Veraltete oder nicht mehr gewartete Pakete ersetzen.
• Transitive Abhängigkeiten im Blick behalten – sie enthalten oft die meisten Schwachstellen.

Wenn ein Secret veröffentlicht wurde

1. 1
   Sofort sperren oder rotierenNicht darauf vertrauen, dass das Löschen aus dem aktuellen Code genügt.
2. 2
   Nutzung untersuchenProtokolle auf unbekannte oder missbräuchliche Verwendung prüfen.
3. 3
   Ursache beseitigenSecrets-Verwaltung, Zugriffsrechte und Prüfungen verbessern.
4. 4
   Historie bewertenRepository-Geschichte und Kopien fachkundig behandeln; Rotation bleibt zwingend.

15. Logging, Backups und Notfallplan

Prävention allein reicht nicht. Ein Betrieb muss relevante Ereignisse erkennen, untersuchen und kontrolliert darauf reagieren können.

Was gehört in ein Sicherheitslog?

• Authentifizierung: Erfolgreiche und fehlgeschlagene Anmeldeversuche, Abmeldungen.
• Autorisierung: Zugriffsverweigerungen, Rechteänderungen, administrative Aktionen.
• Eingaben: Auffällige oder unerwartete Eingaben (z.B. SQL-Injection-Versuche).
• Systemereignisse: Start/Stop, Konfigurationsänderungen, Updates.
• Fehler: Ausnahmen, die auf Angriffe oder Fehlkonfiguration hinweisen könnten.

NICHT: log.info("Benutzer " + email + " hat sich angemeldet")
RICHTIG: log.info("Benutzer " + user_id + " hat sich angemeldet")

NICHT: log.error("SQL-Fehler: " + sql_abfrage)
RICHTIG: log.error("SQL-Fehler bei Abfrage " + query_id)

Backup-Strategie

• 3-2-1-Regel: 3 Kopien, 2 verschiedene Medien, 1 Kopie außerhalb
• Vollständige Sicherungen: Dateien + Datenbank + Konfiguration
• Regelmäßige Tests: Wiederherstellung in einer Testumgebung durchführen
• Aufbewahrungszeit: Gesetzliche Anforderungen prüfen (z.B. DSGVO, Steuerrecht)
• Verschlüsselung: Backups verschlüsseln, insbesondere wenn sie extern gespeichert werden

16. WordPress sicher betreiben

Bei WordPress umfasst die Angriffsfläche Core, Plugins, Themes, Benutzerkonten, Hosting, Dateien und Datenbank. Sicherheit ist deshalb eine laufende Betriebsaufgabe.

WordPress-Härtung – Erweiterte Maßnahmen

• wp-config.php schützen: Verschiebe die Datei eine Ebene höher und setze starke Salt-Strings.
• Standard-Admin-Benutzer entfernen: Erstelle einen individuellen Administrator-Namen.
• Verzeichnisberechtigungen: 755 für Ordner, 644 für Dateien, außer wp-config.php (600).
• wp-admin schützen: Zugriff über IP-Whitelist oder zusätzliche HTTP-Authentifizierung.
• Login-URL ändern: Erschwert automatisierte Angriffe auf /wp-login.php.
• XML-RPC deaktivieren: Wenn nicht benötigt, schließt es eine häufige Angriffsfläche.
• File-Editor deaktivieren: define('DISALLOW_FILE_EDIT', true); in wp-config.php.

Praxisablauf vor einem Update

1. 1
   Änderungen und Kompatibilität prüfenChangelog, aktive Abhängigkeiten und Hosting-Voraussetzungen betrachten.
2. 2
   Dateien und Datenbank sichernBeide Teile gehören zu einem wiederherstellbaren Stand.
3. 3
   Wenn möglich in Staging testenFunktionen, Formulare, Darstellung und Anmeldung prüfen.
4. 4
   Produktiv aktualisierenWartungsfenster und Rückfallplan bereithalten.
5. 5
   Nachkontrolle durchführenWebsite, Logs, Cache und kritische Geschäftsprozesse testen.

17. Interaktiver Sicherheitsplaner

Wähle den Bereich, den du absichern möchtest. Der Planer liefert einen defensiven Startpunkt – keine automatische Sicherheitsprüfung.

18. Sicherheits-Checkliste für Webseiten

Die Liste ist ein Einstieg und ersetzt keine anwendungsbezogene Sicherheitsprüfung. Die Auswahl bleibt nur während dieses Seitenaufrufs erhalten.

0 von 12 Punkten erledigt

19. Häufige Sicherheitsirrtümer

20. Übungen zum Mitmachen

Arbeite nur mit eigenen Testprojekten oder ausdrücklich autorisierten Umgebungen.

Lösungshinweise

21. Passende nächste Themen

22. Offizielle Quellen und Vertiefung

Stand dieser Zusammenfassung: August 2026. Prüfe bei konkreten Projekten immer die aktuelle Dokumentation des eingesetzten Frameworks und Hostings.

23. Häufige Fragen zur Web-Sicherheit