Interviewfragen zu Web Security

Nein. Clientseitige Validierung ist reiner UX-Komfort — ein Angreifer kann JavaScript abschalten, die Anfrage im Browser oder in Burp bearbeiten oder die API direkt mit curl aufrufen und sie so vollständig umgehen. Sicherheitsprüfungen (Validierung, Autorisierung, Bereinigung) müssen auf dem Server erzwungen werden, dem einzigen Ort, den du kontrollierst. Der Irrtum ist, den Browser für eine Vertrauensgrenze zu halten; das ist er nicht, denn der Client läuft auf dem Rechner des Angreifers. Clientprüfungen sind toll für schnelles Feedback, nie für Sicherheit.

Nein. Das Löschen des Cookies entfernt nur die Anmeldedaten aus deinem Browser — der Session-Datensatz (oder ein noch gültiges JWT) auf dem Server bleibt typischerweise nutzbar, bis er abläuft oder explizit invalidiert wird. Ein Angreifer, der das Token bereits abgegriffen hat, kann es weiter nutzen. Der Irrtum hält das Cookie für die Session selbst; es ist nur ein Zeiger auf serverseitigen Zustand. Echtes Abmelden muss die Session serverseitig invalidieren oder das Token widerrufen und mit kurzer TTL versehen.

Größtenteils nein. Der Ziel-Hostname wird im Klartext in der SNI-Erweiterung des TLS-ClientHello gesendet, und Ihre DNS-Abfrage verrät ihn meist ebenfalls, sodass ein Provider oder Netzwerk sehen kann, WELCHE Seite Sie besuchen — selbst über HTTPS. Sie können nur den Pfad und Inhalt nicht lesen. Encrypted ClientHello (ECH) und DNS-over-HTTPS können diese Lücke schließen, sind aber nicht universell. „HTTPS verbirgt alles“ ist der Irrtum.

Nein. TLS/HTTPS sichert Daten bei der Übertragung zwischen Client und Server; nach dem Empfang werden sie von der App entschlüsselt und im Klartext verarbeitet und dann je nach Datenbankkonfiguration gespeichert. Daten im Ruhezustand zu schützen ist ein eigenes Thema — Datenträger-/Spaltenverschlüsselung, ein KMS und Zugriffskontrolle. „Wir nutzen HTTPS“ mit „unsere gespeicherten Daten sind verschlüsselt“ zu verwechseln ist ein verbreiteter und gefährlicher Irrtum.

Nein. HTTPS verschlüsselt den Kanal, sodass Angreifer den Verkehr unterwegs nicht lesen oder manipulieren können, aber die bösartige Eingabe kommt an, wird entschlüsselt und von deiner App genau wie zuvor verarbeitet. SQL-Injection und XSS sind Fehler der Anwendungsschicht, die durch parametrisierte Abfragen und Output-Encoding behoben werden, nicht durch Transportverschlüsselung. Der Irrtum unterstellt, Verschlüsselung bereinige Inhalte — tut sie nicht; der Angreifer sendet die Payload einfach über die HTTPS-Verbindung.

Nein. Der private/Inkognito-Modus verhindert nur, dass der lokale Browser Verlauf, Cookies und Formulardaten nach der Sitzung speichert — am Netzwerkpfad ändert er nichts. Dein ISP, der Proxy deines Arbeitgebers, der DNS-Resolver und die Seiten, bei denen du dich anmeldest, sehen deine Aktivität weiterhin. Der Irrtum ist „Inkognito = unsichtbar”; tatsächlich ist es Privatsphäre vor anderen Nutzern desselben Geräts, nicht Anonymität vor dem Netzwerk.

Nein. POST trägt die Parameter einfach im Anfrage-Body statt in der URL; dieser Body ist Klartext und für jeden, der den Verkehr sieht, voll sichtbar, sofern kein HTTPS genutzt wird. POST ist vorzuziehen für zustandsändernde Aktionen und hält Parameter aus URLs, Logs und Verlauf heraus, bietet aber für sich keine Vertraulichkeit. Der Irrtum verwechselt „nicht in der URL” mit „verschlüsselt” — nur TLS verschlüsselt die Daten beider Methoden bei der Übertragung.

Nicht vertrauenswürdiger Inhalt, den das Modell aufnimmt, kann Anweisungen tragen — das ist indirekte Prompt-Injection. Sie können nicht vollständig verhindern, dass das Modell beeinflusst wird, also isolieren Sie abgerufenen Inhalt als Daten, begrenzen Sie die Tools/Berechtigungen des Agenten, verlangen Sie Bestätigung für sensible Aktionen und geben Sie ihm keine Geheimnisse, zu deren Preisgabe er gezwungen werden könnte. Anzunehmen, das Modell ignoriere injizierte Anweisungen einfach, ist genau der ausgenutzte Fehlermodus.

Das ist die „unsachgemäße Ausgabebehandlung

Ein Open Redirect in einem Authentifizierungsfluss erlaubt einem Angreifer, einen vertrauenswürdig wirkenden Login-Link zu basteln, der den Benutzer nach der Authentifizierung — und möglicherweise einen Autorisierungscode oder ein Token — an eine vom Angreifer kontrollierte Domain sendet und so Kontoübernahme und überzeugendes Phishing ermöglicht. Beheben Sie es, indem Sie exakte Redirect-URIs serverseitig streng per Allow-List freigeben und alles andere ablehnen. Es ist weder kosmetisch noch ein Performance-Problem, und HTTPS hilft nicht, weil das Ziel des Angreifers ebenfalls eine gültige HTTPS-Site sein kann.

Wenn der Browser das Sitzungs-Cookie automatisch anhängt, kann eine bösartige Seite die Überweisung im Namen des Opfers auslösen — das ist Cross-Site Request Forgery (CSRF). Schützen Sie zustandsändernde Anfragen mit Anti-CSRF-Token und SameSite-Cookies und prüfen Sie den Origin/Referer-Header. Das Cookie beweist die Identität, aber nicht die Absicht, ein Login-CAPTCHA schützt keine bereits authentifizierte Aktion, und HTTPS schützt die Transportvertraulichkeit, nicht die Anfragenfälschung.

Wenn ein Angreifer eine serverseitig ausführbare Datei (oder HTML/SVG) in ein ausgeliefertes Verzeichnis hochladen kann, kann er Remote Code Execution oder Stored-XSS erreichen. Validieren Sie den echten Inhaltstyp, speichern Sie Uploads außerhalb des Web-Roots oder in einem nicht ausführenden Speicher, randomisieren Sie Dateinamen und liefern Sie sie so aus, dass sie weder ausgeführt noch als Markup interpretiert werden. Langsamere Seitenladezeiten und Speicherplatz sind Betriebsfragen, nicht das hier ausgenutzte Sicherheitsrisiko.

Das serverseitige Abrufen von durch Angreifer kontrollierten URLs ist Server-Side Request Forgery (SSRF): Es ermöglicht den Zugriff auf interne Dienste oder den Cloud-Metadaten-Endpunkt, um Zugangsdaten zu stehlen. Mildern Sie es durch eine Allow-List erlaubter Hosts und Schemata, das Sperren privater und Link-Local-Bereiche (mit erneuter Prüfung nach jeder Weiterleitung) und das Härten des Metadatenzugriffs mit IMDSv2. Zu sagen, es gebe kein Risiko, ignoriert den Zugriff, den die Anfrage gewährt, und ein Lade-Spinner oder Caching ändert nichts daran, wohin der Server sich verbinden darf.

Das ist fehlerhafte Zugriffskontrolle (IDOR): Der Server prüft nicht, ob der authentifizierte Benutzer auf das angeforderte Objekt zugreifen darf. Die Behebung ist eine objektbezogene Autorisierung, die serverseitig bei jeder Anfrage erzwungen wird. Das Bereinigen der Zahl belegt keine Eigentümerschaft. Das Verschlüsseln oder Verschleiern der ID ist Obskurität und bleibt erratbar, leakbar oder wiederholbar. Die HTTP-Methode ist für die Autorisierung irrelevant. Prüfe stets das Recht des Aufrufers auf das konkrete Objekt, bevor du es zurückgibst.

`alg: none` erlaubt jedem, ein gültig aussehendes, unsigniertes Token zu fälschen und sich als beliebiger Benutzer auszugeben — eine vollständige Authentifizierungsumgehung, kein Nebenfund. Behebe es, indem du serverseitig eine Allow-Liste der erwarteten Algorithmen führst und die Signatur stets mit dem richtigen Schlüssel prüfst; vertraue niemals dem alg-Header des Tokens für die Wahl der Prüfmethode. Längere Gültigkeit oder ein anderer Speicherort ändert nichts an gefälschten, unsignierten Tokens. Es ist kritisch und ausnutzbar, also ist Dokumentieren keine Behebung.

Prompt Injection lässt sich nicht vollständig mit mehr Prompt-Text lösen; nimm an, dass das Modell unterwandert werden kann, und begrenze, was es TUN darf. Gib Tools least privilege, sichere wirkungsstarke Aktionen mit menschlicher Bestätigung ab und validiere oder sandboxe Tool-Aufrufe vor dem Handeln (OWASP LLM „Excessive Agency“ und „Improper Output Handling“). Im System-Prompt zu flehen ist umgehbar. Höhere Temperature fügt nur Zufall hinzu, und reines Logging hält den Schaden fest, ohne die injizierte Aktion zu verhindern.

Das ist eine Mass-Assignment-Schwachstelle (Over-Posting): Der Server mappt das Client-JSON blind auf sensible Modellfelder. Behebe es, indem du nur eine explizite Allow-Liste erlaubter Felder bindest (DTOs / Strong Params), sodass privilegierte Attribute wie isAdmin nicht vom Client gesetzt werden können. Das Feld im Frontend zu verstecken und clientseitige Validierung werden beide mit einer rohen Anfrage umgangen. isAdmin umzubenennen ist Obskurität, leicht zu entdecken. Steuere serverseitig, welche Felder gebunden werden.

Parametrisierte Abfragen sind die eigentliche Behebung: Sie trennen Code von Daten, sodass Benutzereingaben stets als Wert behandelt werden, niemals als SQL, das die Abfragestruktur ändern kann. Manuelles Escaping ist fehleranfällig und je nach Kodierung und Dialekt umgehbar. Ein WAF ist eine kompensierende Maßnahme, keine Behebung, und Kodierungstricks hebeln es aus. Eine Längenprüfung stoppt Injection überhaupt nicht. Behebe es auf der Abfrageebene.

Stored XSS wird behoben, indem Daten für den genauen Kontext kodiert werden, in dem sie gerendert werden (HTML-Body, Attribut, JavaScript, URL), sodass der Browser sie als Text behandelt, mit einer Content-Security-Policy als zweiter Schicht. Das Wort „script“ auf eine Blacklist zu setzen, wird trivial über Event-Handler, gemischte Groß-/Kleinschreibung und Kodierungen umgangen. Du kannst deine Benutzer nicht zwingen, JavaScript zu deaktivieren. Benutzer zu bitten, kein HTML einzugeben, ist keine durchsetzbare Maßnahme. Kodiere bei der Ausgabe, bei jedem Rendern.

Transitiver Code läuft in deiner Anwendung, also ist eine kritische CVE dein Risiko. Bewerte, ob der verwundbare Codepfad tatsächlich erreichbar ist, dann behebe durch Anheben oder Überschreiben der Version (oder Mitigation) und verifiziere in Produktion. Sie zu ignorieren, weil sie transitiv ist, lässt eine bekannte Lücke offen, die ein Angreifer ausnutzen kann. Die Warnung zu unterdrücken verbirgt nur das Signal. node_modules neu zu installieren zieht dieselbe verwundbare Version. Verfolge sie über SCA, bringe sie nicht zum Schweigen.

Bedrohungsmodellierung ist in der Designphase am günstigsten und wirksamsten, bevor Code Entscheidungen festzurrt: gehe die Datenflüsse durch, zähle Bedrohungen mit einem Rahmenwerk wie STRIDE auf, baue Gegenmaßnahmen ein und überarbeite sie, während sich das Design entwickelt. Sie erst nach einem Vorfall oder beim jährlichen Pentest zu machen, findet Probleme, wenn sie teuer zu beheben und bereits exponiert sind. Und sich auf „sorgfältige Entwickler" zu verlassen ist Hoffnung, keine wiederholbare, prüfbare Kontrolle.

Beweisen Sie die Schwachstelle, ohne dem Kunden zu schaden oder seine Daten anzuhäufen: Zeigen Sie, dass Sie beliebige Daten über die DB-Version, das Schema oder eine einzelne anonymisierte Stichprobe lesen können, und hören Sie dann auf. Den gesamten PII-Datenbestand zu exfiltrieren erzeugt für beide Seiten eine Haftung zur Meldung von Datenpannen und zum Datenumgang. Eine Tabelle zu löschen ist destruktiv und geht weit über einen Proof of Concept hinaus. Die Datenbank zu verschlüsseln und ein Lösegeld zu fordern ist Erpressung, kein Test — eine Straftat, kein Finding.

Ein nützlicher Bericht treibt die Behebung an: nach Geschäftsrisiko (Wahrscheinlichkeit × Auswirkung) priorisieren, die Exploit-Ketten hervorheben, die zu kritischer Kompromittierung führen, und für jedes Finding umsetzbare Fixes geben. Alphabetische Sortierung begräbt das Wichtige unter dem, was zufällig mit „A" beginnt. Längster Text zuerst belohnt Wortfülle statt Schwere. Die niedrigen wegzulassen verbirgt echtes Risiko und die Muster, die der Kunde für Defense-in-Depth braucht, und hinterlässt ein falsch beruhigendes Bild.

Sensible Daten sollten niemals in Logs gelangen: redigiere oder maskiere zuerst an der Quelle, um die Blutung zu stoppen, behebe dann die historischen Logs und verschärfe die Zugriffe. PCI DSS verbietet, vollständige PANs und CVVs so zu speichern, und Passwörter sollten überhaupt nie protokolliert werden. „Interne" Logs sind weiterhin ein erstrangiges Angriffsziel. Den Speicher zu verschlüsseln oder mit ACLs zu versehen lässt trotzdem Klartext-Geheimnisse in den Logs liegen, lesbar für jeden mit Lesezugriff — Backups, SIEM-Pipelines und Administratoren sehen sie alle.

Direkte Prompt Injection liegt vor, wenn ein Nutzer gegnerische Anweisungen direkt in den Prompt tippt, um den System-Prompt oder Sicherheitsregeln zu überschreiben. Indirekte Prompt Injection verbirgt bösartige Anweisungen in externen Inhalten, die das Modell später einliest — eine Webseite, eine E-Mail, ein PDF oder ein RAG-Dokument —, sodass der Angriff auslöst, ohne dass das Opfer ihn je tippt. Indirekte Injection ist das größere Risiko, weil Angreifer und Opfer verschiedene Personen sind und die Payload in Daten mitreist, denen die App implizit vertraut.

Unsichere Ausgabeverarbeitung bedeutet, dem zu vertrauen, was das Modell zurückgibt, und es ohne Validierung oder Codierung an ein nachgelagertes System weiterzureichen. Weil die Modellausgabe von Angreifern beeinflussbar ist, führt das Rendern als rohes HTML zu XSS, das Einspeisen in einen URL-Fetcher zu SSRF und das Übergeben an eine Shell oder SQL-Abfrage zu Command- oder SQL-Injection. Die Lösung ist, die Modellausgabe genauso wie nicht vertrauenswürdige Benutzereingaben zu behandeln: kontextbewusste Ausgabecodierung, Allowlisting, Sanitization und Parametrisierung, bevor sie einen Sink erreicht.

Die OWASP Top 10 für LLM-Anwendungen sind die Konsensliste der kritischsten Risiken beim Entwickeln mit großen Sprachmodellen. Die Ausgabe 2025 umfasst Prompt Injection, Offenlegung sensibler Informationen, Supply Chain, Daten- und Modellvergiftung, unsichere Ausgabeverarbeitung, übermäßige Handlungsvollmacht, Leakage von System-Prompts, Schwachstellen in Vektoren und Embeddings, Fehlinformation sowie unbegrenzten Ressourcenverbrauch. Sie existiert, weil klassische AppSec-Listen die LLM-spezifischen Fehlerbilder nicht erfassen, und gibt Teams ein gemeinsames Vokabular sowie eine Checkliste, um Maßnahmen zu priorisieren.

RAG-Sicherheit bedeutet, jedes abgerufene Dokument als nicht vertrauenswürdige Eingabe zu behandeln. Zentrale Risiken: indirekte Prompt Injection, die in abgerufenen Inhalten versteckt ist, Vergiftung der Wissensbasis oder der Embeddings sowie fehlende benutzerbezogene Autorisierung, sodass das Modell Daten zurückgibt, auf die der Benutzer keinen Zugriff hat. Zu den Verteidigungsmaßnahmen zählen Zugriffskontrolle beim Retrieval, Inhaltsprovenienz und Prüfung der Ingestion, Behandeln von abgerufenem Text als Daten statt als Anweisungen, Ausgabevalidierung und Isolierung der Vektordatenbank pro Mandant.

Ein LLM-Agent verwandelt Text über Tools und Function Calls in Aktionen, sodass eine Prompt Injection zu einer realen Aktion wird — das Risiko übermäßiger Handlungsvollmacht. Sichere ihn ab, indem du jedem Tool das geringste benötigte Privileg und den engsten Geltungsbereich gibst, Tool-Argumente validierst und einschränkst, menschliche Bestätigung für sensible oder irreversible Aktionen verlangst, die Ausführung sandboxt, Aufrufe rate-limitierst und budgetierst und jeden Tool-Aufruf protokollierst. Lass niemals zu, dass die von nicht vertrauenswürdigen Daten beeinflusste Ausgabe des Modells direkt eine folgenschwere Aktion autorisiert.

SPF veröffentlicht, welche IPs für eine Domain Mail senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, damit der Empfänger prüfen kann, dass die Nachricht nicht verändert wurde und von der Domain stammt. DMARC bindet die SPF/DKIM-Ergebnisse über das Alignment an den sichtbaren From:-Header, sagt Empfängern, was bei Fehlschlag zu tun ist (none/quarantine/reject), und sendet Berichte. SPF und DKIM allein schützen das vom Nutzer gesehene From nicht – DMARC erzwingt das.

Betten Sie Sicherheit in jede SDLC-Phase ein, statt am Ende zu testen: Anforderungen umfassen Sicherheits- und Datenschutzanforderungen, das Design umfasst Bedrohungsmodellierung, die Entwicklung folgt sicheren Codierstandards mit SAST, das Testen ergänzt DAST und Reviews, und das Release erfordert eine Freigabe — alles gesteuert durch Richtlinie, Funktionstrennung und Änderungskontrolle. Fehler früh zu beheben ist drastisch günstiger als nach dem Release.

Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.

Die App leitet den Benutzer zum Autorisierungsserver weiter, um sich anzumelden und einzuwilligen. Der Server leitet mit einem kurzlebigen Autorisierungscode zurück. Das Backend der App tauscht diesen Code (plus sein Client-Geheimnis) dann am Token-Endpunkt über einen Server-zu-Server-Back-Channel gegen ein Access-Token. Das hält Tokens aus Browser/URL fern. Öffentliche Clients ergänzen PKCE, um den Code an den ursprünglichen Anforderer zu binden.

Lockfiles pinnen exakte Abhängigkeitsversionen und Hashes, sodass jeder Build dieselben verifizierten Bytes auflöst — das macht Builds reproduzierbar und blockiert stille bösartige Updates. Pinning per Digest, das Prüfen von Integritäts-Hashes und das Scoping interner Pakete auf eine private Registry schützen zudem vor Dependency Confusion, bei der ein Angreifer ein öffentliches Paket mit höherer Version veröffentlicht, das einem internen Namen entspricht, um die Auflösung zu kapern. Das Prinzip: Den Build niemals still ungeprüften Code ziehen lassen.

SAST liest den Quellcode, ohne ihn auszuführen, und findet Fehler wie Injection-Sinks früh, aber mit vielen Fehlalarmen. DAST greift die laufende Anwendung von außen ohne Code-Einblick an und findet echte ausnutzbare Probleme, aber spät und mit oberflächlicher Abdeckung. IAST instrumentiert die laufende Anwendung, um Laufzeitverhalten mit dem Code zu korrelieren, und liefert präzise Ergebnisse mit Code-Kontext, benötigt aber eine ausgeübte Anwendung und Agent-Unterstützung.

Setzen Sie auf Defense in Depth: Pre-Commit-Hooks (z. B. gitleaks) fangen Secrets ab, bevor sie landen, serverseitiges CI-Scanning fängt, was durchrutscht, und regelmäßige Scans des gesamten Verlaufs finden alte Lecks. Entscheidend: Ein Secret, das ein Remote-Repository erreicht hat, muss als kompromittiert behandelt und rotiert werden — den Commit zu löschen hilft nicht, da es im Verlauf, in Forks und Logs lebt. Kombinieren Sie das mit einem echten Secrets-Manager, damit Secrets gar nicht erst im Code stehen.

Brich den Build nur bei hochgradig zuverlässigen, schwerwiegenden, neu eingeführten Befunden; warne (blockiere nicht) bei allem anderen, damit Entwickler dem Gate weiter vertrauen. Manage False Positives mit getunten Regeln, Baselining bereits bestehender Probleme und dokumentierten, befristeten, geprüften Unterdrückungen statt Scanner zu deaktivieren. Ein Gate, das ständig fälschlich Alarm schlägt, wird ignoriert oder umgangen — Signalqualität ist also das Ganze.

Shift-Left bedeutet, Sicherheit nach vorn zu verlagern — ins Design, in die IDE und in den Pull Request —, wo Probleme billiger zu beheben sind als in der Produktion. Du vermeidest es, Entwickler zu blockieren, indem du den sicheren Pfad zum einfachen Pfad machst: schnelles kontextbezogenes Feedback, Gates mit wenigen False Positives, die nur bei schwerwiegenden neuen Problemen hart fehlschlagen, sichere Defaults und Paved-Road-Templates und das Behandeln von Sicherheit als Ermöglicher statt als spätes Veto.

SCA inventarisiert die Open-Source- und Drittanbieter-Komponenten, die eine Anwendung einbindet — einschließlich transitiver Abhängigkeiten — und markiert jene mit bekannten CVEs oder problematischen Lizenzen. Sie ist wichtig, weil der meiste moderne Code aus Abhängigkeiten besteht, die du nicht geschrieben hast, und ein einziges anfälliges transitives Paket (wie Log4j) die gesamte App gefährden kann. Gute SCA priorisiert nach Erreichbarkeit und Ausnutzbarkeit, nicht nur nach reinen CVE-Zahlen.

Ein SBOM ist ein maschinenlesbares Inventar jeder Komponente, Bibliothek und Abhängigkeit in einer Software, mit Versionen und idealerweise Hashes. Es ist wichtig, weil man bei einer neuen Schwachstelle seine SBOMs abfragen kann, um sofort zu beantworten «Sind wir betroffen und wo?», statt in Hektik zu verfallen. Die beiden dominierenden Standards sind SPDX und CycloneDX, und SBOMs werden zunehmend durch Regulierung und Beschaffung gefordert.

Kodierung (wie Base64) ist eine reversible Formatänderung ohne Geheimnis — keine Sicherheit. Verschlüsselung ist mit einem Schlüssel reversibel und schützt die Vertraulichkeit. Hashing ist eine Einwegfunktion, die einen Digest fester Länge erzeugt, für Integritätsprüfungen und Passwortspeicherung verwendet wird und nicht zur Eingabe zurückgerechnet werden kann.

Es bestätigt XSS. Wenn alert() überhaupt ausgelöst hat, hat der Browser Ihr eingeschleustes JavaScript im Seitenkontext geparst und ausgeführt — das ist die Schwachstelle. Ein leeres Popup bedeutet nur, dass das übergebene String-Argument nicht wie erwartet angezeigt wurde (Anführungszeichen-Behandlung, Kodierung oder Kontext-Verstümmelung haben die Nachricht zerstört), nicht dass die Payload blockiert wird. Der Ausführungspunkt ist aktiv; von hier aus verfeinern Sie die Payload.

Nein. CORS ist keine Abwehr gegen CSRF — es lockert tatsächlich die Same-Origin-Policy, damit eine Seite Cross-Origin-Antworten lesen kann, die sie sonst nicht lesen dürfte. CSRF muss die Antwort nicht lesen; es genügt, dass der Browser des Opfers eine authentifizierte zustandsändernde Anfrage sendet. Die echten Abwehrmechanismen sind Anti-CSRF-Tokens, das SameSite-Cookie-Attribut und das Prüfen von Origin/Referer.

Nein. Das Schloss bedeutet, dass der Transport verschlüsselt und das Zertifikat für diese Domain gültig ist — es sagt nichts darüber aus, ob der Betreiber ehrlich oder der Inhalt bösartig ist. Kostenlose, automatisierte Zertifikate führen dazu, dass Phishing- und Malware-Seiten fast immer ebenfalls ein einwandfrei gültiges Schloss haben. HTTPS schützt den Kanal, nicht das Ziel.

Halte Access-Tokens kurzlebig (Minuten), damit ein gestohlenes schnell abläuft, und nutze langlebigere Refresh-Tokens, um neue Access-Tokens zu erhalten, ohne den Benutzer erneut aufzufordern. Rotiere Refresh-Tokens bei jeder Verwendung und erkenne die Wiederverwendung eines verbrauchten Tokens als Diebstahlsignal, das die Kette widerruft. Das Ziel ist, das Begrenzen des Fensters eines kompromittierten Tokens gegen das Vermeiden ständiger erneuter Anmeldungen abzuwägen.

Coordinated Vulnerability Disclosure ist ein Prozess, bei dem ein Forscher eine Schwachstelle privat an den Hersteller meldet, beide Seiten sich auf Behebung und Zeitplan einigen und Details erst veröffentlicht werden, sobald ein Fix verfügbar ist (oder eine vereinbarte Frist abläuft). Sie wägt die Zeit zum Patchen für Verteidiger gegen das Recht der Öffentlichkeit auf Information ab. Eine security.txt-Datei und eine klare Richtlinie machen das Melden reibungslos; Bug-Bounty-Programme fügen darauf strukturierte Belohnungen hinzu.

Der WSTG ist eine checklistengestützte Methodik, die eine App durch Testkategorien führt: Informationsbeschaffung, Konfiguration und Deployment, Identität und Authentifizierung, Autorisierung, Session-Management, Eingabevalidierung (Injection/XSS), Fehlerbehandlung, Kryptografie, Geschäftslogik und Client-seitig. Er bietet systematische Abdeckung mit stabilen Test-IDs, sodass Befunde reproduzierbar sind und nichts Offensichtliches übersprungen wird.

PTES definiert sieben Phasen: Pre-Engagement (Scope, Rules of Engagement, Autorisierung), Intelligence Gathering (OSINT, Aufklärung), Threat Modeling, Schwachstellenanalyse, Exploitation, Post-Exploitation (Pivoting, wertvolle Daten, Persistenz) und Reporting. Die Struktur macht Einsätze wiederholbar, vertretbar und an das Geschäftsrisiko gebunden statt an Ad-hoc-Hacking. Pre-Engagement und Reporting sind die Phasen, die Juniors unterschätzen.

Beginnen Sie damit, das Bedrohungsmodell der App zu verstehen und wo sie nicht vertrauenswürdige Eingaben, Geheimnisse, Authentifizierung und Autorisierung verarbeitet. Nutzen Sie SAST zum breiten Scannen und DAST gegen die laufende App, behandeln Sie die Tool-Ausgabe aber als Hinweise, nicht als Befunde — sortieren Sie False Positives aus. Verwenden Sie dann die menschliche Zeit auf die wertvollen, kontextabhängigen Bereiche, die Tools verpassen: Autorisierungslogik, Geschäftslogik, Krypto-Nutzung und Vertrauensgrenzen. Verfolgen Sie den Datenfluss von der Source bis zum Sink.

Ein sicherer SDLC bettet Sicherheit in jede Phase ein, statt am Ende zu testen: Anforderungen (Sicherheits- und Missbrauchsfälle), Design (Threat Modeling), Implementierung (sichere Coding-Standards, SAST/SCA in der IDE und CI), Test (DAST, Pentest), Release (Gates und Freigabe) und Betrieb (Monitoring, Patching, Feedback). Shift-Left verlagert Defekte nach vorne, wo sie billig zu beheben sind; Reifegradmodelle wie OWASP SAMM und BSIMM messen, wie gut man es tatsächlich tut.

Threat Modeling beantwortet vier Fragen: Was bauen wir, was kann schiefgehen, was tun wir dagegen und haben wir gute Arbeit geleistet. Sie diagrammieren das System (oft ein Datenflussdiagramm mit Vertrauensgrenzen), zählen Bedrohungen mit einem Framework wie STRIDE auf, priorisieren nach Risiko und weisen Gegenmaßnahmen zu. PASTA fügt eine risiko- und angreiferzentrierte Note hinzu; Angriffsbäume zerlegen ein einzelnes Ziel. Es zur Designzeit zu tun ist weit billiger, als Produktion zu patchen.

Ein Forward-Proxy steht vor den Clients und stellt ausgehende Anfragen in deren Namen — für Egress-Kontrolle, Filterung, Caching und Anonymität. Ein Reverse-Proxy steht vor den Servern und empfängt eingehende Anfragen in deren Namen — für Lastausgleich, TLS-Terminierung, Caching und als Sicherheitsfassade für eine WAF. Die Richtung, in die er zeigt, clientseitig oder serverseitig, ist die entscheidende Unterscheidung.

Bestimme den Stack aus Headern und Quellcode, dann brute-force Verzeichnisse und Dateien mit gobuster oder feroxbuster unter Nutzung einer guten Wortliste und relevanter Endungen. Suche nach Admin-Panels, Backups, Konfigurationsdateien und Upload-Punkten und prüfe virtuelle Hosts, wenn die Seite auf einen Hostnamen reagiert.

Einzeln legt SQLi Daten offen oder verändert sie und kann RCE erreichen; Stored XSS kapert Sitzungen im Browser der Opfer. Verkettet können Sie SQLi nutzen, um eine Stored-XSS-Payload zu platzieren, die in der Sitzung eines Admins ausgelöst wird, dessen Sitzung zu stehlen und zur vollständigen Anwendungskontrolle zu eskalieren.

Ein Pentest durchläuft Pre-Engagement (Scope und Einsatzregeln), Aufklärung, Scanning und Enumeration, Ausnutzung, Post-Exploitation und Reporting. Jede Phase speist die nächste, und im Reporting wird der Wert tatsächlich an den Kunden geliefert.

Ein Schwachstellenscan ist eine automatisierte, in die Breite gehende Bestandsaufnahme potenzieller Schwächen, oft mit Fehlalarmen. Ein Penetrationstest ist menschengeführt: Er validiert Funde, verkettet sie und demonstriert durch tatsächliche Ausnutzung echte geschäftliche Auswirkungen.

Ein guter Bericht bedient zwei Zielgruppen: eine Executive Summary, die das Geschäftsrisiko für die Führung einordnet, und detaillierte, reproduzierbare Funde mit Beweisen, präzisen Risikobewertungen und priorisierter Behebung für das technische Team. Der Bericht — nicht der Exploit — ist das Liefergut.

Ein sicherer SDLC verankert Sicherheit in jeder Phase, statt sie am Ende anzuflanschen. Anforderungen umfassen Sicherheits- und Missbrauchsfälle, Design ergänzt Threat Modeling, Entwicklung nutzt sicheres Coding und SAST plus Dependency Scanning, Tests ergänzen DAST und Penetrationstests, und Betrieb ergänzt Monitoring, Patching und Incident Response – Sicherheit nach links verlagert.

Überall TLS erzwingen, jede Anfrage authentifizieren (z. B. OAuth2/OIDC-Tokens) und pro Objekt autorisieren, sodass Benutzer nur ihre eigenen Daten erreichen. Eingabevalidierung, Rate Limiting und Kontingente, Schemavalidierung sowie gründliches Logging ergänzen. Der häufigste API-Fehler ist gebrochene objektbezogene Autorisierung, also prüfe bei jedem Ressourcenzugriff die Eigentümerschaft.

Prüfen Sie die E-Mail sicher ohne zu klicken: Header und Absender-Authentifizierung (SPF/DKIM/DMARC) checken, URLs und Anhänge in einer Sandbox oder mit Reputations-Tools inspizieren, dann den Umfang bestimmen — wer sie sonst erhielt, ob jemand klickte oder Zugangsdaten eingab. Je nach Befund remediieren: E-Mail purgen, Indikatoren blockieren und kompromittierte Zugangsdaten zurücksetzen.

Content-Security-Policy ist ein HTTP-Antwort-Header, der dem Browser mitteilt, welche Quellen von Skripten, Stilen, Bildern und anderen Inhalten auf einer Seite geladen und ausgeführt werden dürfen. Indem sie Inline-Skripte und nicht vertrauenswürdige Quellen untersagt — idealerweise über Nonces oder Hashes — dient sie als Defense-in-Depth-Absicherung, die eingeschleuste XSS-Payloads neutralisiert, selbst wenn eine durchrutscht.

CSRF bringt den Browser eines angemeldeten Nutzers dazu, eine zustandsändernde Anfrage an eine Website zu senden, bei der er authentifiziert ist, und nutzt dabei aus, dass Cookies automatisch mitgesendet werden. Verhindert wird es mit Anti-CSRF-Tokens (ein geheimer Wert pro Sitzung, den der Angreifer weder lesen noch erraten kann) und dem SameSite-Cookie-Attribut, das verhindert, dass Cookies bei Cross-Site-Anfragen mitgeschickt werden.

Die OWASP Top 10 sind ein von der Community getragenes Bewusstseinsdokument, das die kritischsten Sicherheitsrisiken von Webanwendungen einstuft und alle paar Jahre auf Basis realer Daten aktualisiert wird. Es ist weder eine Checkliste noch ein Standard, sondern ein Ausgangspunkt — aktuelle Einträge sind unter anderem fehlerhafte Zugriffskontrolle (Nr. 1), kryptografische Fehler, Injection und unsicheres Design.

Speichere Passwörter niemals im Klartext oder umkehrbar verschlüsselt und niemals mit schnellen Allzweck-Hashes wie MD5 oder SHA-256. Verwende eine langsame, speicherintensive Passwort-Hashfunktion — Argon2id (bevorzugt) oder bcrypt — mit einem eindeutigen Zufalls-Salt pro Passwort und einem abgestimmten Arbeitsfaktor, sodass ein Angreifer, der die Datenbank stiehlt, die Hashes nicht realistisch knacken kann.

Prepared Statements senden zuerst die Abfragevorlage mit Platzhaltern an die Datenbank, sodass die Struktur feststeht, bevor irgendwelche Nutzerdaten eintreffen. Parameter werden danach als reine Daten gebunden und können niemals als SQL geparst werden — eine Eingabe wie ' OR 1=1 wird also als Zeichenkettenliteral behandelt, nicht als Code. Diese Trennung ist die kanonische, zuverlässige Lösung gegen Injection.

Die primäre Verteidigung ist kontextbezogene Ausgabecodierung — nicht vertrauenswürdige Daten genau für die Stelle codieren, an der sie landen (HTML-Körper, Attribut, JavaScript, URL). Kombiniere das mit sicheren DOM-APIs (textContent statt innerHTML), dem automatischen Escaping von Frameworks, Eingabevalidierung und einer Content-Security-Policy als Defense-in-Depth-Absicherung, die begrenzt, welche Skripte laufen dürfen.

Die Same-Origin Policy ist die Browser-Regel, dass ein Skript aus einem Origin (Schema + Host + Port) die Antworten eines anderen Origins nicht lesen kann, was authentifizierte Sitzungen schützt. CORS ist eine kontrollierte Lockerung: Ein Server gibt Access-Control-Allow-Origin-Header zurück, um bestimmten Origins ausdrücklich das Lesen seiner Antworten zu erlauben, und lockert so die SOP, statt sie zu umgehen.

HttpOnly verbirgt das Cookie vor JavaScript, sodass XSS es nicht über document.cookie stehlen kann. Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird, und blockiert das Abfangen im Netzwerk. SameSite steuert, ob das Cookie bei Cross-Site-Anfragen gesendet wird, und mildert CSRF ab. Zusammen härten sie Sitzungs-Cookies gegen die häufigsten Diebstahl- und Missbrauchswege.

Zu den wichtigsten Sicherheits-Headern zählen Strict-Transport-Security (erzwingt HTTPS, blockiert SSL-Stripping), Content-Security-Policy (begrenzt Skriptquellen, mildert XSS), X-Frame-Options oder CSP frame-ancestors (blockiert Clickjacking), X-Content-Type-Options: nosniff (stoppt MIME-Sniffing) und Referrer-Policy (steuert das Durchsickern des Referrers). Jeder adressiert eine bestimmte Angriffsklasse.

SQL-Injection erlaubt einer Angreifereingabe, eine Abfrage zu verändern. In-Band-Techniken geben Daten direkt zurück: Die UNION-basierte hängt ein UNION SELECT an, um zusätzliche Spalten zu ziehen, und die fehlerbasierte lässt Daten über Datenbank-Fehlermeldungen durchsickern. Wenn keine Ausgabe sichtbar ist, nutzen Angreifer blinde SQLi — die boolesche schließt Daten aus Unterschieden in Wahr/Falsch-Antworten, die zeitbasierte nutzt Verzögerungen wie SLEEP(), um Daten Bit für Bit zu lesen.

SSRF bringt einen Server dazu, HTTP- (oder andere) Anfragen an ein vom Angreifer gewähltes Ziel zu stellen, und missbraucht die Netzwerkposition des Servers, um interne Dienste hinter der Firewall zu erreichen. In der Cloud ist es besonders gravierend, weil der Instanz-Metadaten-Dienst (z. B. 169.254.169.254) IAM-Anmeldedaten zurückgeben kann und so ein SSRF zur Kompromittierung des Cloud-Kontos macht.

HTTP ist zustandslos — jede Anfrage ist unabhängig und hat keine Erinnerung an vorherige. Sitzungen fügen darauf Zustand hinzu: Nach der Anmeldung gibt der Server eine Kennung aus, die der Browser in einem Cookie speichert und bei jeder Anfrage erneut sendet. Serverseitige Sitzungen halten den Zustand auf dem Server, indiziert über eine undurchsichtige Sitzungs-ID; zustandslose Tokens wie JWTs legen signierten Zustand in das Token selbst, sodass der Server ohne Speicher prüfen kann.

Jedes XSS schleust vom Angreifer kontrolliertes Skript in den Browser eines Opfers ein. Stored XSS speichert die Payload dauerhaft auf dem Server (z. B. einen Kommentar) und trifft jeden, der sie ansieht; Reflected XSS spiegelt die Payload in einer einzelnen Antwort vom Server zurück, meist über einen präparierten Link; DOM-basiertes XSS erreicht nie die Serverlogik — verwundbares clientseitiges JavaScript schreibt nicht vertrauenswürdige Eingaben in die Seite.

XXE missbraucht einen XML-Parser, der externe Entitäten auflöst, die in der DTD eines Dokuments definiert sind. Ein Angreifer deklariert eine Entität, die auf eine lokale Datei oder interne URL zeigt, und der Parser ruft sie ab — was Dateioffenlegung, SSRF und Dienstverweigerung ermöglicht. Die Lösung ist, DTD-Verarbeitung und externe Entitätsauflösung in der Parser-Konfiguration zu deaktivieren.