Webtechnologien für Cybersecurity verstehen

Web Security ist heute das zentrale Thema in der offensiven und defensiven IT-Sicherheit. OWASP Top 10, Bug Bounty, Pentesting, SOC-Arbeit - überall stehen Webanwendungen im Mittelpunkt. Wer die Grundlagen nicht kennt, behandelt Symptome, ohne die Ursache zu verstehen.

Ein einfaches Beispiel: Ein Pentester sieht in Burp Suite einen Request mit einem Set-Cookie-Header ohne HttpOnly-Flag. Wer nicht weiß, was das bedeutet, scrollt drueber weg. Wer es weiß, erkennt ein potenzielles Session-Hijacking-Risiko - und kann es im Bericht dokumentieren.

Die gute Nachricht: Du musst kein Frontend-Entwickler werden. Lese-Verständnis genügt. Dieser Guide zeigt genau, was du wissen musst - und was du getrost weglassen kannst.

• HTTP ist die Sprache, in der Browser und Server sprechen - du musst sie lesen können
• Cookies und Sessions sind die Schicht, auf der Authentifizierung basiert
• HTML und JavaScript bestimmen, was im Browser passiert - und wo XSS entsteht
• APIs sind der Hauptangriffspunkt moderner Webanwendungen
• Statuscodes, Header und Body sind die Rohdaten jeder Web-Analyse

Hinter jedem Klick auf einen Link steckt ein strukturierter Ablauf. Wer ihn Schritt für Schritt kennt, versteht, wo Angriffe ansetzen können.

1. 1DNS-Aufloesung: Der Browser fragt einen DNS-Server nach der IP-Adresse der Domain (z.B. example.com → 93.184.216.34).
2. 2TCP-Verbindung: Browser und Server etablieren eine TCP-Verbindung (Three-Way-Handshake: SYN, SYN-ACK, ACK).
3. 3TLS-Handshake (bei HTTPS): Zertifikat wird geprüft, ein gemeinsamer Sitzungsschlüssel wird vereinbart, ab jetzt ist alles verschlüsselt.
4. 4HTTP-Request: Der Browser sendet den Request (z.B. GET /login HTTP/1.1) mit Headern wie Host, Cookie, User-Agent.
5. 5Server-Verarbeitung: Webserver (z.B. nginx) und Applikation (z.B. Node.js, Python) verarbeiten die Anfrage, lesen ggf. aus einer Datenbank.
6. 6HTTP-Response: Der Server antwortet mit einem Statuscode (z.B. 200 OK), Response-Headern und einem Body (HTML, JSON usw.).
7. 7Rendering: Der Browser parst HTML, lädt CSS und JavaScript nach, baut den DOM auf und zeigt die Seite an.

Jeder dieser Schritte ist ein potenzieller Angriffspunkt: DNS kann vergiftet werden, TLS-Zertifikate können gefaelscht sein, HTTP-Header können fehlen, Applikationslogik kann Lücken haben.

HTTP (HyperText Transfer Protocol) ist das zustandslose Anfrage-Antwort-Protokoll des Webs. Jeder Request ist unabhaengig - der Server "erinnert" sich standardmäßig nicht an vorherige Anfragen. Cookies und Sessions sind der Mechanismus, der diesen Zustand kuenstlich herstellt.

HTTP-Methoden

Header und Body

Ein HTTP-Request besteht aus drei Teilen: der Startzeile (Methode, Pfad, HTTP-Version), Headern (Schlüsselpaar-Metadaten) und einem optionalen Body (Daten, z.B. JSON oder Formulardaten). Der Response hat dieselbe Struktur: Statuszeile, Header, Body.

Sicherheitsrelevante Request-Header: Authorization (traegt Token oder Basic-Auth), Cookie (Sitzungscookies), Origin (CORS-Herkunft), Content-Type (Dateiformat des Body). Response-Header wie Set-Cookie, Content-Security-Policy und Strict-Transport-Security steuern den Browser-Verhalten direkt.

Webanwendungen bestehen aus drei Schichten, die jeweils unterschiedliche Aufgaben haben - und unterschiedliche Security-Relevanz.

XSS (Cross-Site Scripting) - defensiv verstehen: Wenn eine Webanwendung Nutzereingaben ungefiltert in HTML ausgibt, kann schadhafter JavaScript-Code im Browser eines anderen Nutzers ausgeführt werden. Beispiel: Ein Kommentarfeld gibt <script>alert(1)</script> ungefiltert aus. Die Verteidigung besteht in Output-Encoding (z.B. < statt <) und einer strengen Content Security Policy. Das Konzept zu kennen hilft, beim Code-Review oder im Lab entsprechende Muster zu erkennen.

Statuscodes sind dreistellige Zahlen im HTTP-Response. Sie sagen, ob eine Anfrage erfolgreich war, wohin umgeleitet werden soll oder warum etwas fehlgeschlagen ist. In Burp Suite, DevTools und Logs sind sie die erste Orientierung.

Da HTTP zustandslos ist, braucht es einen Mechanismus, um Nutzer über mehrere Requests hinweg zu erkennen. Cookies erledigen das: Der Server setzt ein Cookie per Set-Cookie-Header, der Browser sendet es bei jedem weiteren Request automatisch mit. Sessions speichern den eigentlichen Zustand serverseitig; das Cookie enthält nur eine Session-ID.

Cookie-Attribute und ihre Schutzwirkung

Zwei Begriffe, die häufig verwechselt werden, aber grundverschiedene Konzepte sind:

• Authentifizierung (AuthN): Wer bist du? - Pruefe die Identität (Passwort, Token, Zertifikat)
• Autorisierung (AuthZ): Was darfst du? - Pruefe die Berechtigung nach erfolgreicher Identifikation

Typischer Login-Ablauf mit Session-Cookie:

1. Nutzer sendet POST-Request mit Benutzername und Passwort
2. Server prüft Credentials gegen Datenbank (Passwort-Hash)
3. Bei Erfolg: Server erzeugt Session-ID, speichert sie serverseitig, sendet sie als Cookie an den Browser
4. Browser sendet Cookie bei jedem weiteren Request automatisch mit
5. Server prüft Session-ID, lädt zugehörige Nutzerdaten, entscheidet über Autorisierung

JWT (JSON Web Token) als Alternative: Statt einer Session-ID auf dem Server wird ein signiertes Token an den Client gegeben, das alle relevanten Informationen enthält. Vorteil: Server muss keinen Zustand halten. Nachteil: Token-Invalidierung ist komplex; Implementierungsfehler (z.B. schwache Signaturen, fehlende Prüfung des alg-Headers) können kritisch sein.

Moderne Webanwendungen kommunizieren meist über REST-APIs. Statt HTML-Formulare direkt an den Server zu senden, schickt JavaScript Daten als JSON per fetch()-API - und verarbeitet die JSON-Antwort, ohne die Seite neu zu laden.

REST-Grundidee: Ressourcen (z.B. /api/users/42) werden per HTTP-Methoden manipuliert: GET zum Lesen, POST zum Erstellen, PATCH zum Ändern, DELETE zum Löschen. Jede URL repraesentiert eine Ressource.

Input-Validierung: Jeder Wert, der vom Nutzer kommt - Formularfelder, URL-Parameter, JSON-Body-Felder - muss serverseitig validiert werden. Client- seitige Validierung (z.B. per HTML-required) ist kein Schutz, sondern nur UX. Ein Angreifer mit Burp Suite umgeht sie trivial.

Output-Encoding: Bevor Nutzerdaten in HTML ausgegeben werden, müssen Sonderzeichen kodiert werden (z.B. < wird zu <). Das ist der primaere Schutz gegen XSS. Beim Ausgeben in JSON-Kontexte, SQL-Queries oder Shell-Kommandos gelten andere Encoding-Regeln.

Diese Begriffe begegnen dir in jedem Web-Security-Kontext. Wer sie verinnerlicht hat, liest Writeups, CVEs und Lab-Aufgaben viel schneller.

Alles, was in diesem Guide erklärt wurde, wird in der Praxis mit Burp Suite sichtbar gemacht. Burp Suite Community Edition ist kostenlos und funktioniert als HTTP-Proxy: Jeder Request und Response läuft durch Burp, wird angezeigt und kann manipuliert werden.

• Burp Proxy zeigt alle HTTP-Requests in Echtzeit - Header, Body, Cookies sichtbar
• Repeater erlaubt das Wiederholen und Modifizieren einzelner Requests
• Intruder automatisiert Fuzzing und Brute-Force in eigenen legalen Labs
• PortSwigger Web Security Academy bietet kostenlose Labs zu allen großen Schwachstellenklassen
• Jedes Lab in der Academy setzt genau das Wissen aus diesem Guide voraus

Die PortSwigger Academy (portswigger.net/web-security) ist der empfohlene Einstiegspunkt. Die Labs sind nach Schwierigkeit gestaffelt, die Erklärungen sind detailliert und auf dem Stand der Technik. Wer hier methodisch vorgeht, erreicht in wenigen Wochen ein solides Web-Security-Fundament.

Diese Denkfehler kosten Zeit und führen zu blinden Flecken - fruehzeitig ausräumen spart spätere Frustration.

Richte OWASP Juice Shop oder DVWA lokal per Docker ein. Öffne danach die Browser-DevTools (F12) und wechsle zum Netzwerk-Tab. Navigiere durch die Anwendung und beobachte jeden Request: Welche Methode? Welche Header? Welcher Statuscode? Was steht im Cookie? Danach installiere Burp Suite Community Edition als Proxy - jetzt siehst du dieselben Requests nochmals, kannst sie pausieren, verändern und wiederholen. Alles im eigenen Lab, völlig legal.