Web Security

Webanwendungen verarbeiten Eingaben, Sessions, persönliche Daten und Berechtigungen. Dadurch entstehen Risiken. Gute Webentwicklung denkt Sicherheit nicht erst am Ende, sondern bei jeder Eingabe, jedem Request und jeder Ausgabe mit.

Grundprinzipien

Wichtige Sicherheitsprinzipien:

• Benutzereingaben nie blind vertrauen
• serverseitig validieren
• Ausgaben korrekt escapen
• Berechtigungen im Backend prüfen
• geheime Schlüssel nicht ins Frontend legen
• sichere Defaults verwenden
• Fehler nicht mit sensiblen Details anzeigen
• Abhängigkeiten aktuell halten
• Logs ohne Passwörter und Tokens schreiben

Cross-Site Scripting

XSS entsteht, wenn Angreifer JavaScript in eine Seite einschleusen können.

Gefährlich:

output.innerHTML = userInput

Sicherer:

output.textContent = userInput

Besonders kritisch sind Kommentare, Profilnamen, Suchparameter, Markdown-Inhalte und Admin-Oberflächen. Alles, was von außen kommt, muss kontrolliert verarbeitet werden.

Cross-Site Request Forgery

CSRF nutzt aus, dass ein Browser Cookies automatisch mitsendet. Eine fremde Seite kann versuchen, im Namen eines eingeloggten Benutzers eine Aktion auszulösen.

Gegenmaßnahmen:

• CSRF-Token bei zustandsändernden Aktionen
• SameSite-Cookie-Attribut
• wichtige Aktionen mit POST, PATCH oder DELETE statt GET
• Origin- und Referer-Prüfung bei sensiblen Endpunkten

Cookies und Sessions

Session-Cookies sollten defensiv konfiguriert sein.

Tokens im localStorage sind bei XSS besonders gefährdet, weil JavaScript sie direkt lesen kann.

Authentifizierung und Autorisierung

Authentifizierung beantwortet: Wer bist du?

Autorisierung beantwortet: Was darfst du?

Beide Prüfungen müssen im Backend passieren. Ein versteckter Button im Frontend ist keine Zugriffskontrolle.

Beispiel:

• Ein Benutzer darf sein eigenes Profil bearbeiten.
• Ein Moderator darf Beiträge aus seinem Bereich löschen.
• Ein Administrator darf Rollen vergeben.

Diese Regeln gehören in API-Endpunkte, Datenbankabfragen und serverseitige Logik.

CORS

CORS steuert, welche fremden Ursprünge im Browser auf eine API zugreifen dürfen.

Wichtig:

• Access-Control-Allow-Origin: * ist für öffentliche, nicht sensible APIs möglich.
• Für APIs mit Cookies oder privaten Daten sollte nur eine konkrete Domain erlaubt sein.
• CORS ersetzt keine Authentifizierung.

Content Security Policy

Eine Content Security Policy kann einschränken, welche Skripte, Styles, Bilder und Frames geladen werden dürfen.

Beispielhafte Idee:

Content-Security-Policy: default-src 'self'; script-src 'self'

Eine CSP verhindert nicht alle Fehler, reduziert aber die Auswirkungen bestimmter XSS-Angriffe.

OWASP Top 10

Die OWASP Top 10 fassen häufige Risikoklassen für Webanwendungen zusammen. Dazu gehören unter anderem kaputte Zugriffskontrolle, kryptografische Fehler, Injection, unsichere Konfiguration und verwundbare Abhängigkeiten.

Für den Unterricht ist wichtig: Viele reale Sicherheitsprobleme entstehen nicht durch komplizierte Exploits, sondern durch fehlende Prüfungen, falsche Annahmen und unsichere Standardkonfigurationen.