Sicherheit von Webanwendungen
Lerne die fundamentalen Sicherheitskonzepte für Webanwendungen: Authentifizierung, Verschlüsselung, OWASP Top 10 und Security Testing.
Einführung
Du entwickelst eine Webanwendung für ein Startup. Alles läuft reibungslos, bis eines Morgens die Alarmglocken schrillen: Ein Angreifer hat sich Zugang zur Benutzerdatenbank verschafft. Tausende Passwörter, E-Mail-Adressen und persönliche Daten sind kompromittiert.
Wie konnte das passieren? Die Anwendung schien doch sicher zu sein.
Dieses Szenario ist keine Seltenheit. Viele Sicherheitslücken entstehen nicht durch fehlende Technologie, sondern durch fehlendes Wissen über Authentifizierung, Verschlüsselung und Security Testing. Die gute Nachricht: Diese Lücken lassen sich mit den richtigen Methoden und Best Practices schließen.
In dieser Lerneinheit lernst du, wie du Webanwendungen gegen die häufigsten Angriffe absicherst. Du erfährst, wie Authentifizierung und Autorisierung funktionieren, wie Verschlüsselung deine Daten schützt und welche Werkzeuge dir helfen, Sicherheitslücken zu finden, bevor es Angreifer tun.
Lernziele
Nach dieser Lerneinheit kannst du:
- Authentifizierung und Autorisierung implementieren und verstehen, wie sie zusammenwirken, um Benutzer zu verifizieren und Zugriffsrechte zu kontrollieren
- Verschlüsselung mit SSL/TLS und HTTPS einsetzen, um sensible Daten während der Übertragung zu schützen
- Die OWASP Top 10 Schwachstellen erkennen und verstehen, welche Sicherheitsrisiken in Webanwendungen am häufigsten auftreten
- Security Testing mit Tools wie OWASP ZAP und Burp Suite durchführen, um Sicherheitslücken frühzeitig zu identifizieren
Überleitung
Wie im Eingangs-Szenario gesehen, kann ein Datenleck verheerende Folgen haben. Der erste Schritt zur Absicherung deiner Webanwendung ist es zu verstehen, wie Benutzer sich authentifizieren und wie ihre Zugriffsrechte kontrolliert werden.
In den folgenden Abschnitten erfährst du, wie Authentifizierung und Autorisierung funktionieren und wie du sie sicher implementierst.
Was ist Authentifizierung?
Authentifizierung ist der Prozess, bei dem überprüft wird, ob ein Benutzer wirklich der ist, für den er sich ausgibt. Dies ist die erste Verteidigungslinie deiner Webanwendung gegen unbefugten Zugriff.
“Authentifizierung beantwortet die Frage: Wer bist du?”
Es gibt verschiedene Methoden zur Authentifizierung:
- Passwort-basiert: Der Klassiker. Der Nutzer gibt Benutzername und Passwort ein. Einfach zu implementieren, aber anfällig für Brute-Force-Angriffe und gestohlene Passwörter.
- Biometrische Authentifizierung: Fingerabdruck, Gesichtserkennung oder Iris-Scan. Schwer zu fälschen, aber teuer in der Implementierung.
- Token-basiert: Der Nutzer erhält nach erfolgreicher Anmeldung einen Token (z.B. JWT), den er bei nachfolgenden Anfragen mitsendet.
Warum ist Authentifizierung wichtig? Ohne sie könnte jeder auf geschützte Ressourcen zugreifen. Ein Angreifer könnte sich als Admin ausgeben und die gesamte Datenbank manipulieren. Die Authentifizierung ist daher der Grundpfeiler jeder sicheren Webanwendung.
Mehr-Faktor-Authentifizierung (MFA)
Eine einzelne Authentifizierungsmethode ist oft nicht sicher genug. Wenn ein Passwort gestohlen wird, hat der Angreifer sofortigen Zugriff. Mehr-Faktor-Authentifizierung (MFA) fügt zusätzliche Sicherheitsebenen hinzu.
Die drei Faktoren:
- Wissen (Something you know): Passwort, PIN
- Besitz (Something you have): Smartphone, Hardware-Token
- Sein (Something you are): Fingerabdruck, Gesichtserkennung
Zwei-Faktor-Authentifizierung (2FA) kombiniert zwei dieser Faktoren. Das klassische Beispiel: Passwort (Wissen) + SMS-Code (Besitz).
SMS-basierte 2FA gilt heute als unsicher. SMS können abgefangen werden durch SIM-Swapping-Angriffe.
Moderne Alternative: WebAuthn/FIDO2
WebAuthn ist ein Web-Standard für passwortlose Authentifizierung. Statt SMS nutzt er Hardware-Sicherheitsschlüssel (z.B. YubiKey) oder Biometrie (Face ID, Touch ID). WebAuthn ist deutlich sicherer und benutzerfreundlicher als SMS-2FA.
Best Practice: Implementiere immer MFA für sensible Bereiche wie Admin-Panels und Zahlungsfunktionen. Empfehle WebAuthn statt SMS.
JWT: Sichere Token-Authentifizierung
JSON Web Tokens (JWT) sind eine moderne Methode zur Authentifizierung. Nach erfolgreicher Anmeldung erhält der Nutzer einen Token, der seine Identität und Berechtigungen enthält.
Das Problem mit unsicheren JWT-Implementierungen:
Viele Entwickler machen diesen kritischen Fehler:
const token = jwt.sign({ username: "user1" }, "secretKey");Wenn dieser Code veröffentlicht wird, kann jeder gültige Tokens erstellen.
Sichere Implementierung:
const secret = process.env.JWT_SECRET;
const token = jwt.sign(
{ username: "user1" },
secret,
{ algorithm: "HS256", expiresIn: "1h" }
);Was macht dieser Code?
process.env.JWT_SECRET: Lädt das Secret aus einer Umgebungsvariable statt es im Code zu speichernalgorithm: "HS256": Legt den Verschlüsselungsalgorithmus explizit fest (verhindert “none”-Angriffe)expiresIn: "1h": Token läuft nach 1 Stunde ab (begrenzt Schaden bei Token-Diebstahl)
Best Practices:
- Secret niemals im Code (nutze Environment-Variablen)
- Secret mindestens 32 Zeichen lang
- Immer Expiry-Zeit setzen
- Algorithm explizit angeben
Wenn dein JWT-Secret kompromittiert wird, kann ein Angreifer sich als beliebiger Benutzer ausgeben.
Autorisierung: Wer darf was?
Nachdem ein Benutzer authentifiziert wurde (“Wer bist du?”), kommt die Autorisierung ins Spiel: “Was darfst du tun?”
“Autorisierung kontrolliert, welche Ressourcen und Aktionen ein authentifizierter Benutzer ausführen darf.”
Ohne Autorisierung hätten alle authentifizierten Nutzer die gleichen Rechte. Ein normaler Benutzer könnte Admin-Funktionen nutzen und die gesamte Anwendung manipulieren.
RBAC: Role-Based Access Control
RBAC weist Benutzern Rollen zu, und jede Rolle hat bestimmte Berechtigungen. Das ist die häufigste Autorisierungsmethode.
| Rolle | Berechtigungen | Beispiel |
|---|---|---|
| Admin | Volle Kontrolle (Erstellen, Lesen, Aktualisieren, Löschen) | Kann Benutzer verwalten, Einstellungen ändern |
| Moderator | Lesen, Aktualisieren eigener Inhalte, Löschen von Kommentaren | Kann unangemessene Kommentare entfernen |
| Benutzer | Lesen, Erstellen eigener Inhalte | Kann eigene Posts erstellen und lesen |
ABAC: Attribute-Based Access Control
ABAC ist flexibler als RBAC. Zugriffsentscheidungen basieren auf Attributen wie Standort, Uhrzeit oder Gerät.
Beispiel: Ein Nutzer darf nur von IP-Adressen innerhalb der EU auf sensible Daten zugreifen, und nur während der Arbeitszeit (9-17 Uhr).
Zugriffskontrolle: Jede Anfrage prüfen
Authentifizierung und Autorisierung sind nur wirksam, wenn sie bei jeder einzelnen Anfrage geprüft werden. Viele Sicherheitslücken entstehen genau hier: Der Server überprüft die Berechtigung einmal beim Login, aber nicht bei nachfolgenden Anfragen.
Server-seitige Validierung ist Pflicht
Die Zugriffskontrolle MUSS auf dem Server stattfinden. Client-seitige Prüfungen sind kein Schutz.
Warum? Ein Angreifer kann die Client-Logik manipulieren oder direkt die API aufrufen und alle Client-Prüfungen umgehen. Wenn du einen Button im Frontend versteckst, hindert das niemanden daran, die API direkt mit Tools wie curl oder Postman aufzurufen.
Der dreistufige Check bei jeder Anfrage:
- Authentifizierung prüfen: Ist der Nutzer eingeloggt?
- Autorisierung prüfen: Hat der Nutzer die nötige Berechtigung für diese Aktion?
- Erst dann: Aktion ausführen
Wenn eine dieser Prüfungen fehlschlägt, muss die Anfrage abgelehnt werden mit HTTP 401 (nicht authentifiziert) oder 403 (keine Berechtigung).
Principle of Least Privilege
Gib Benutzern nur die Rechte, die sie wirklich benötigen.
Ein Content-Editor braucht NICHT die Berechtigung, Benutzer zu löschen. Ein Backup-Service braucht NICHT Schreibrechte. Je weniger Berechtigungen ein Account hat, desto geringer der Schaden bei Kompromittierung.
SSL/TLS: Verschlüsselte Kommunikation
SSL (Secure Sockets Layer) und sein Nachfolger TLS (Transport Layer Security) verschlüsseln die Kommunikation zwischen Browser und Server. Dies verhindert, dass übertragene Daten von Dritten gelesen oder manipuliert werden.
Beim TLS-Handshake tauschen Browser und Server Zertifikate aus, validieren diese und einigen sich auf einen gemeinsamen Verschlüsselungsschlüssel. Dieser Prozess dauert nur Millisekunden, schützt aber die gesamte nachfolgende Kommunikation.
Detaillierte Informationen zum TLS-Handshake und den verschiedenen Phasen findest du im Modul “Transport Layer Security (TLS)“.
Wichtig: SSL 2.0 und 3.0 sowie TLS 1.0 sind veraltet und unsicher. Nutze mindestens TLS 1.2, besser TLS 1.3.
HTTPS mit Let’s Encrypt
HTTPS kombiniert HTTP mit TLS-Verschlüsselung. Das Schloss-Symbol im Browser zeigt: Die Verbindung ist verschlüsselt.
Warum HTTPS?
- Datenverschlüsselung: Passwörter, Kreditkartendaten und andere sensible Informationen sind geschützt
- Datenintegrität: Niemand kann die übertragenen Daten unbemerkt ändern
- Authentifizierung: Der Browser kann sicher sein, dass er mit dem echten Server kommuniziert
- SEO-Vorteil: Google bevorzugt HTTPS-Seiten im Ranking
Let’s Encrypt: Kostenlose SSL-Zertifikate
Let’s Encrypt ist eine Certificate Authority (CA), die kostenlose SSL-Zertifikate ausstellt. Die Einrichtung ist einfach mit certbot.
Statt das unsichere OpenSSL-Kommando aus dem Legacy-Content zu nutzen, solltest du immer Let’s Encrypt für Produktions-Systeme verwenden.
Vorteile:
- Kostenlos
- Automatische Erneuerung alle 90 Tage
- Einfache Installation
- Vertrauenswürdig (in allen Browsern)
Selbstsignierte Zertifikate sind nur für lokale Tests geeignet. Für Produktion immer Let’s Encrypt oder eine andere vertrauenswürdige CA nutzen.
TLS-Versionen: Was ist sicher?
Nicht alle TLS-Versionen sind gleich sicher. Ältere Versionen haben bekannte Schwachstellen und sollten deaktiviert werden.
| TLS-Version | Status | Empfehlung |
|---|---|---|
| SSL 2.0 | UNSICHER | Komplett deaktivieren |
| SSL 3.0 | UNSICHER | Komplett deaktivieren (POODLE-Angriff) |
| TLS 1.0 | VERALTET | Deaktivieren |
| TLS 1.1 | VERALTET | Deaktivieren |
| TLS 1.2 | SICHER | Mindeststandard |
| TLS 1.3 | SEHR SICHER | Empfohlen (schneller und sicherer) |
TLS 1.3: Die moderne Wahl
TLS 1.3 (veröffentlicht 2018) ist schneller und sicherer als TLS 1.2:
Vorteile:
- Schnellerer Handshake: Nur 1 Round-Trip statt 2 (50% schneller)
- Stärkere Verschlüsselung: Unsichere Algorithmen wurden entfernt
- Forward Secrecy: Selbst wenn der Private Key kompromittiert wird, bleiben alte Verbindungen geschützt
Best Practice: Konfiguriere deinen Server so, dass er TLS 1.3 und TLS 1.2 unterstützt, aber alle älteren Versionen ablehnt.
HSTS: HTTPS erzwingen
HTTP Strict Transport Security (HSTS) ist ein Security-Header, der Browser zwingt, IMMER HTTPS zu nutzen. Dies verhindert Downgrade-Angriffe.
Das Problem ohne HSTS:
Stell dir vor, ein Nutzer gibt example.com in die Adresszeile ein (ohne https://). Der Browser versucht zuerst HTTP. Ein Angreifer im selben Netzwerk (z.B. öffentliches WLAN) kann diese HTTP-Anfrage abfangen und den Nutzer auf eine gefälschte Seite umleiten.
Die Lösung: HSTS-Header
Der Server sendet beim ersten HTTPS-Besuch diesen Header:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Was bedeutet das?
max-age=31536000: Browser merkt sich 1 Jahr lang, dass nur HTTPS genutzt werden darfincludeSubDomains: Gilt auch für alle Subdomains (z.B.api.example.com)preload: Domain kann in Browser-Preload-Listen aufgenommen werden
Preload-Listen
Browser wie Chrome, Firefox und Safari haben eingebaute Listen von Domains, die IMMER über HTTPS aufgerufen werden müssen. Du kannst deine Domain auf hstspreload.org eintragen.
HSTS schützt nicht beim allerersten Besuch. Deshalb sind Preload-Listen wichtig.
OWASP Top 10: Die häufigsten Sicherheitsrisiken
Die OWASP Top 10 ist eine Liste der häufigsten Sicherheitsrisiken in Webanwendungen. Sie wird alle paar Jahre von der Open Web Application Security Project (OWASP) Community aktualisiert.
OWASP Top 10:2021
| Rang | Kategorie | Beschreibung |
|---|---|---|
| A01 | Broken Access Control | Nutzer können auf Ressourcen zugreifen, die sie nicht sehen sollten |
| A02 | Cryptographic Failures | Schwache oder fehlende Verschlüsselung sensibler Daten |
| A03 | Injection | SQL, NoSQL, OS-Command Injection Angriffe |
| A04 | Insecure Design | Fehlerhafte Architektur und fehlende Security Controls |
| A05 | Security Misconfiguration | Falsche Konfiguration von Frameworks, Datenbanken, Servern |
| A06 | Vulnerable Components | Nutzung von veralteten oder unsicheren Libraries |
| A07 | Auth & Session Management Failures | Schwache Authentifizierung, Session-Hijacking |
| A08 | Software & Data Integrity Failures | Unsichere CI/CD Pipelines, fehlende Code-Signierung |
| A09 | Security Logging & Monitoring Failures | Fehlende oder unzureichende Logging-Mechanismen |
| A10 | Server-Side Request Forgery (SSRF) | Server macht Anfragen an interne Systeme |
Warum ist das wichtig? Diese Top 10 decken 90% aller Sicherheitslücken in Webanwendungen ab. Wenn du diese kennst und vermeidest, ist deine Anwendung deutlich sicherer.
Security Testing: SAST, DAST und IAST
Um Sicherheitslücken zu finden, gibt es verschiedene Ansätze des Security Testings. Jeder hat seine Stärken und Schwächen.
Vergleich der Test-Methoden
| Methode | Zeitpunkt | Vorteil | Nachteil |
|---|---|---|---|
| SAST (Static) | Während der Entwicklung | Findet Fehler früh im Code | Viele False Positives, kennt Laufzeit-Kontext nicht |
| DAST (Dynamic) | Laufende Anwendung | Testet echte Angriffszenarien | Findet nur Laufzeit-Fehler, langsam |
| IAST (Interactive) | Während der Ausführung | Kombiniert SAST + DAST Vorteile | Benötigt Agent in der Anwendung |
SAST: Static Application Security Testing
SAST analysiert den Quellcode, ohne die Anwendung auszuführen. Es findet typische Code-Muster, die zu Sicherheitslücken führen.
Beispiel-Tools: SonarQube, Checkmarx, Fortify
Wann nutzen? In der CI/CD-Pipeline, bei jedem Commit.
DAST: Dynamic Application Security Testing
DAST testet die laufende Anwendung wie ein Angreifer. Es sendet bösartige Anfragen und prüft die Antworten.
Beispiel-Tools: OWASP ZAP, Burp Suite, Acunetix
Wann nutzen? Vor jedem Release, in Staging-Umgebung.
IAST: Interactive Application Security Testing
IAST kombiniert beide Ansätze. Ein Agent läuft innerhalb der Anwendung und überwacht Code-Ausführung UND Anfragen/Antworten.
Vorteil: Weniger False Positives, findet mehr echte Schwachstellen.
Best Practice: Nutze alle drei Methoden für maximale Sicherheit. SAST in der Entwicklung, DAST vor Releases, IAST für kritische Anwendungen.
Zusammenfassung und Ausblick
In dieser Lerneinheit hast du die wichtigsten Sicherheitskonzepte für Webanwendungen kennengelernt:
Authentifizierung und Autorisierung bilden das Fundament jeder sicheren Webanwendung. Du verstehst jetzt, wie Benutzer ihre Identität nachweisen (Authentifizierung) und wie Zugriffsrechte kontrolliert werden (Autorisierung). Moderne Ansätze wie JWT und MFA bieten zusätzliche Sicherheitsebenen.
SSL/TLS und HTTPS schützen die Kommunikation zwischen Browser und Server durch Verschlüsselung. Mit Let’s Encrypt kannst du kostenlose Zertifikate einsetzen, und HSTS stellt sicher, dass Browser immer HTTPS nutzen.
OWASP Top 10 geben dir einen systematischen Überblick über die häufigsten Sicherheitsrisiken. Diese Kategorien helfen dir, Schwachstellen frühzeitig zu erkennen und zu vermeiden.
Security Testing mit SAST, DAST und IAST ermöglicht es dir, Sicherheitslücken automatisiert zu finden, bevor Angreifer sie ausnutzen können.
Nächste Lerneinheit: Du hast nun eine sichere Webanwendung entwickelt. Aber wie stellst du sicher, dass sie auch unter hoher Last performant bleibt? In der nächsten Lerneinheit “Performance und Skalierbarkeit von Webanwendungen” lernst du Techniken wie Caching, Load Balancing und horizontale Skalierung kennen.