Wie Angreifer denken: Sicherheitsdenken und OWASP Top 10

Worum es geht

Fabienne ist im dritten Lehrjahr bei der Bödelisoft AG in Interlaken. Das neue Gästeportal ist fast fertig: Gäste melden sich an, sehen ihre Buchungen und laden Rechnungen als PDF herunter. In drei Wochen ist der Go-live. Ihr Teamleiter sagt: "Bevor wir live gehen, will ich wissen, ob da jemand fremde Rechnungen sehen oder Konten übernehmen kann. Schau dir das an."

Am ersten Tag sucht ein Testgast namens D'Amico nach seiner Buchung und erhält eine Fehlermeldung mit einem Stück SQL darin. Für Fabienne ist das ein Alarmsignal: Wenn ein einfacher Apostroph die Datenbankabfrage durcheinanderbringt, dann landet Text aus dem Eingabefeld direkt im SQL-Befehl. Und was ein harmloser Name versehentlich kaputt macht, kann jemand anderes absichtlich ausnutzen.

Die meisten erfolgreichen Angriffe auf Unternehmen laufen nicht über exotische Netzwerktricks, sondern über gewöhnliche Fehler in Applikationen: ungeprüfte Eingaben, schwache Logins, fehlende Berechtigungsprüfungen. Diese Fehler entstehen beim Programmieren, also lassen sie sich auch dort verhindern.

In dieser Lektion lernst du die Denkweise, mit der du ab jetzt jede Funktion anschaust, die aktuelle Liste der wichtigsten Risiken (OWASP Top 10:2025) und eine Struktur, mit der du jede Schwachstelle sauber beschreibst. Im ersten Code-Labor schreibst du eine serverseitige Eingabeprüfung.

Drei Grundideen, die alles andere tragen

Jede Eingabe kommt aus fremder Hand

Stell dir die Rezeption eines Hotels vor. Ein Gast reicht einen Zettel über die Theke: "Zimmer 214, bitte Rechnung an diese Adresse." Eine gute Rezeptionistin prüft zuerst, ob der Gast wirklich in Zimmer 214 wohnt.

Bei einer Webapplikation ist der Browser dieser Zettel. Alles, was vom Browser kommt, kann die Person davor verändern: Formularfelder, versteckte Felder, Cookies, Header, URL-Parameter, JSON im Body. Mit Entwicklertools oder einem Proxy wie Burp Suite dauert das Sekunden. Eine Prüfung im JavaScript des Frontends ist darum Komfort für ehrliche Benutzer, aber kein Schutz. Geschützt ist nur, was der Server prüft.

Die Linie, an der Daten aus einem weniger vertrauenswürdigen Bereich in einen vertrauenswürdigeren wechseln, heisst Vertrauensgrenze. Die wichtigste liegt zwischen Browser und API. Aber auch Daten aus Partnerschnittstellen oder hochgeladenen Dateien überqueren solche Grenzen.

Schutzziele: Was kann kaputtgehen?

Sicherheit heisst konkret, drei Dinge zu schützen. Die Abkürzung CIA kommt aus dem Englischen (Confidentiality, Integrity, Availability).

Dazu kommt die Nachvollziehbarkeit: Wer hat wann was getan? Ohne Protokoll bleibt ein Vorfall unerkannt.

Mehrere Schichten statt einer Mauer

Kein Schutz ist perfekt. Darum baust du mehrere Schichten (Defense in Depth): Eingaben prüfen, Abfragen parametrisieren, Ausgaben kodieren, minimale Rechte, Protokollierung. Dazu kommen Secure by Default (die sichere Einstellung ist die Voreinstellung) und Fail Closed (bei einem Fehler wird der Zugriff verweigert, nicht erlaubt).

Die OWASP Top 10:2025

Das Open Worldwide Application Security Project (OWASP) ist eine gemeinnützige Organisation, die freie Werkzeuge und Leitfäden zur Applikationssicherheit herausgibt. Bekannt sind vor allem die OWASP Top 10, die zehn wichtigsten Risikokategorien für Webapplikationen, ermittelt aus Prüfdaten vieler Applikationen und einer Umfrage unter Fachleuten. Die aktuelle Fassung ist die OWASP Top 10:2025.

Gegenüber der Fassung von 2021 hat sich einiges verschoben. Server-Side Request Forgery (SSRF), 2021 noch eine eigene Kategorie, gehört jetzt zu A01. Die Kategorie zu veralteten Komponenten wurde zu A03 erweitert und umfasst die ganze Lieferkette der Software. Neu ist A10: falsch behandelte Fehlerfälle, zum Beispiel eine Prüfung, die bei einer Ausnahme "offen" weiterläuft.

Angriff, Ursache, Fix: die Struktur für jede Lücke

Wenn du eine Schwachstelle beschreibst, im Team, im Bericht oder in der Prüfung, überzeugt eine klare Struktur mit vier Teilen:

1. Beobachtung und Nachweis: Was passiert, und wie kann man es reproduzieren?
2. Ursache im Code: Welche Zeile, welches Muster ist schuld?
3. Fix: Was änderst du, und warum wirkt das?
4. Nachweis des Fixes: Mit welchem Test zeigst du, dass die Lücke zu ist und zu bleibt?

Am Beispiel D'Amico sieht das so aus:

// Ursache: Die Eingabe wird in den SQL-Text geklebt
const sql = "SELECT * FROM buchung WHERE nachname = '" + req.query.name + "'";
// Mit D'Amico entsteht: ... WHERE nachname = 'D'Amico'  (Syntaxfehler)

// Fix: Platzhalter, der Wert geht getrennt an die Datenbank
const [zeilen] = await pool.execute(
  "SELECT * FROM buchung WHERE nachname = ?",
  [req.query.name]
);

Ordne die Lücke zusätzlich einer OWASP-Kategorie zu, hier A05 Injection. Das zeigt, dass du ein Muster erkennst. Der Nachweis des Fixes ist ein automatisierter Test mit D'Amico und typischen bösartigen Eingaben.

Schritt für Schritt: eine Profiländerung serverseitig prüfen

Gäste können ihr Profil ändern, das Frontend schickt JSON an PATCH /api/profil. Fabienne baut die Prüfung auf dem Server. Eingabevalidierung ist nicht der Hauptschutz gegen Injection oder XSS (das sind parametrisierte Abfragen und Output-Encoding, Lektionen 3 und 4), aber die erste Schicht: Was nicht in die erwartete Form passt, kommt nicht weiter.

Schritt 1: Erlaubte Felder festlegen (Allowlist). Nur vorname, nachname, telefon und sprache dürfen geändert werden. Ein Feld wie rolle oder rabatt im JSON wird abgelehnt. Sonst könnte jemand mit "rolle": "admin" sein eigenes Konto aufwerten (das nennt man Mass Assignment).

Schritt 2: Typ prüfen. Ein Name muss ein String sein, keine Zahl, kein Array, kein Objekt.

Schritt 3: Form und Länge prüfen. Beschreibe, was erlaubt ist, statt aufzuzählen, was verboten ist. Ein Name besteht aus Buchstaben (auch é, ü, ñ), Leerzeichen, Bindestrich und Apostroph, höchstens 50 Zeichen. Eine Telefonnummer im Format +41 und neun Ziffern.

Schritt 4: Wertebereich prüfen. Die Sprache ist genau einer der Werte de, fr, it, en.

Schritt 5: Fehler sammeln und knapp antworten. Der Server antwortet mit Status 400 und nennt die fehlerhaften Felder, aber keine internen Details.

// profilPruefung.js  Serverseitige Prüfung für PATCH /api/profil
const ERLAUBTE_FELDER = ["vorname", "nachname", "telefon", "sprache"];
const NAME = /^[\p{L}][\p{L} '\-]{0,49}$/u;   // Buchstaben, Leerzeichen, ' und -
const TELEFON = /^\+41\d{9}$/;                  // z.B. +41791234567
const SPRACHEN = ["de", "fr", "it", "en"];

function pruefeProfil(daten) {
  const fehler = [];
  // Schritt 1: unbekannte Felder ablehnen (Schutz gegen Mass Assignment)
  for (const feld of Object.keys(daten)) {
    if (!ERLAUBTE_FELDER.includes(feld)) fehler.push(feld);
  }
  // Schritt 2 und 3: Pflichtfelder mit Typ und Form
  for (const feld of ["vorname", "nachname"]) {
    const wert = daten[feld];
    if (typeof wert !== "string" || !NAME.test(wert.trim())) fehler.push(feld);
  }
  // Telefon ist optional, aber wenn vorhanden, dann korrekt
  if (daten.telefon !== undefined &&
      (typeof daten.telefon !== "string" || !TELEFON.test(daten.telefon))) {
    fehler.push("telefon");
  }
  // Schritt 4: Wertebereich
  if (!SPRACHEN.includes(daten.sprache)) fehler.push("sprache");
  // Schritt 5: Ergebnis
  return { ok: fehler.length === 0, fehler };
}

console.log(pruefeProfil({ vorname: "Luca", nachname: "D'Amico", sprache: "it" }));
// { ok: true, fehler: [] }
console.log(pruefeProfil({ vorname: "Luca", nachname: "D'Amico", sprache: "it", rolle: "admin" }));
// { ok: false, fehler: [ 'rolle' ] }

Schritt 6: Gut- und Schlechtfälle testen. D'Amico und Müller-Lüdenscheidt müssen durch. Ein leerer Name, eine Zahl, 51 Zeichen, <b>Test</b> und ein Feld rolle müssen scheitern.

Typische Fehler

1. Nur im Frontend validieren. required oder eine JavaScript-Prüfung lässt sich mit einem Klick umgehen. Korrektur: Jede Regel gilt zusätzlich auf dem Server.
2. Blocklist statt Allowlist. Ein Filter, der <script> entfernt, übersieht <SCRIPT>, <img onerror=...> und hundert andere Varianten. Korrektur: beschreiben, was erlaubt ist, und alles andere ablehnen.
3. Detaillierte Fehlermeldungen an Benutzer. Stacktraces, SQL-Texte oder Pfade verraten einem Angreifer, wie das System gebaut ist (A02, A10). Korrektur: generische Meldung an den Benutzer, Details ins Protokoll.
4. Objekte ungefiltert übernehmen. Object.assign(benutzer, req.body) übernimmt auch rolle oder istAdmin. Korrektur: nur erlaubte Felder einzeln übernehmen.
5. Sicherheit erst am Schluss. "Vor dem Go-live machen wir noch einen Pentest" findet Fehler, wenn sie am teuersten sind. Korrektur: Sicherheitsfragen ab dem Entwurf stellen, mit Bedrohungsanalyse (Lektion 2).

Zusammenfassung

• Alles, was vom Browser kommt, kann verändert sein. Geschützt ist nur, was der Server prüft.
• Vertraulichkeit, Integrität und Verfügbarkeit sind die Schutzziele, Nachvollziehbarkeit ergänzt sie.
• Defense in Depth, Secure by Default und Fail Closed sind die Grundprinzipien.
• Die OWASP Top 10:2025 reichen von A01 Broken Access Control bis A10 Mishandling of Exceptional Conditions. Ordne jeden Fund einer Kategorie zu.
• Beschreibe jede Lücke mit Beobachtung, Ursache, Fix und Nachweis.
• Eingabevalidierung arbeitet mit Allowlists, prüft Typ, Form, Länge und Wertebereich und lehnt unbekannte Felder ab.
• Teste Angriffe nur in eigenen oder ausdrücklich freigegebenen Umgebungen.