API-Sicherheit in Vertrag und Design

API-Sicherheit in Vertrag und Design

0:00 Wenn man Entwickler nach API-Sicherheit fragt, kommt fast immer die Antwort: Tokens, Verschlüsselung, Anmeldung. Das ist nicht falsch, trifft aber nicht den Kern. Die OWASP-Liste der häufigsten API-Risiken führt seit Jahren etwas ganz anderes an — fehlende Berechtigungsprüfungen auf Objektebene. Also der Fall, in dem jemand mit einer fremden Kennung eine fremde Bestellung abruft, weil niemand geprüft hat, ob sie ihm gehört.

0:25 In diesem Modul geht es darum, wo Sicherheit im Entwurf und im Vertrag verankert wird — nicht erst im Penetrationstest.

API-Sicherheit in Vertrag und Design

0:33 Drei Blöcke liegen vor uns. Zuerst die saubere Trennung von Authentifizierung und Autorisierung und wie beide im Vertrag stehen. Dann der Umgang mit allem, was von außen hereinkommt — Eingaben, Rümpfe, Ressourcenverbrauch. Und zum Schluss die OWASP API Security Top 10 als Prüfraster, das Sie in Entwurf und Review anlegen können. Am Ende decken wir in der Hofkiste eine echte Schwachstelle auf.

Authentifizierung und Autorisierung

0:57 Beginnen wir mit zwei Begriffen, die im Alltag oft in einem Atemzug genannt werden und völlig Verschiedenes bedeuten — und deren Verwechslung genau die Lücken erzeugt, um die es später geht. Denn fast alle Lücken, um die es gleich geht, entstehen an genau dieser Nahtstelle: Die Identität wird sorgfältig geprüft, die Berechtigung für das konkrete Objekt aber gar nicht.

1:18 Ein Bild dazu: Der Ausweis am Empfang klärt, wer Sie sind. Ob Sie damit in den Serverraum dürfen, ist eine völlig andere Frage — und sie hängt nicht nur an Ihrer Rolle, sondern am konkreten Raum. Genau diese zweite Frage wird in APIs zu oft übersprungen. Der Token ist gültig, also ist der Zugriff erlaubt. Beides gehört in den Vertrag: OpenAPI beschreibt Anmeldeverfahren als securitySchemes und die Anforderung entweder für das ganze Dokument oder je Operation.

1:46 Damit ist im Vertrag sichtbar, was geschützt ist. Worauf es hier ankommt: Das Verfahren steht einmal in components und wird über security angefordert. Sie können das global setzen und an einzelnen Operationen überschreiben — etwa für einen öffentlichen Endpunkt. Der Gewinn ist doppelt: Werkzeuge können die Anmeldung anbieten, und Sie sehen im Vertrag auf einen Blick, wo etwas ungeschützt ist.

2:10 Neu in Version 3.2 sind übrigens der Device-Authorization-Flow für Geräte ohne Tastatur und ein Feld für die Metadaten-Adresse von OAuth2 — beides schließt Lücken, die vorher Sonderlösungen erzwangen. Auf der Folie stehen drei Ebenen, und die mittlere ist die, die am häufigsten fehlt. Die Funktionsebene fragt: Darf diese Rolle diese Operation aufrufen? Das wird meist geprüft.

2:33 Die Objektebene fragt: Gehört dieses konkrete Objekt zu diesem Aufrufer? Das wird oft vergessen. Und die Eigenschaftsebene fragt nach einzelnen Feldern — darf dieser Aufrufer den Rabattsatz sehen oder gar setzen? Der letzte Punkt gilt für alle drei und ist nicht verhandelbar: Diese Prüfungen finden auf dem Server statt. Was im Client entschieden wird, ist keine Berechtigung, sondern eine Anzeige.

2:58 Der erste Punkt ist der gefährlichste Trugschluss überhaupt: Die Kennung sieht zufällig aus, also findet sie niemand. Das ist keine Sicherheitsmaßnahme, sondern eine Hoffnung — und Kennungen wandern durch Logs, Browserverläufe und Fehlermeldungen. Der zweite Punkt ist die technische Ausprägung davon: Rollen im Token werden geprüft, die Zugehörigkeit des Objekts nie.

3:19 Und der vierte ist ein Inventarproblem, auf das wir gleich zurückkommen — ein undokumentierter Administrationsendpunkt wird auch nicht geprüft. Er ist trotzdem erreichbar.

Eingaben prüfen und Ressourcen schützen

3:30 Weiter mit allem, was von außen hereinkommt. Der Grundsatz ist simpel und wird trotzdem ständig verletzt: Alles, was ein Aufrufer schickt, ist ein Vorschlag — und keine Anweisung. Das gilt für Felder im Rumpf ebenso wie für Seitengrößen und für die Antworten fremder Dienste. Wir schauen uns an, was passiert, wenn man diesem Grundsatz nicht folgt.

3:51 Mass Assignment ist eine dieser Schwachstellen, die aus reiner Bequemlichkeit entstehen. Ein Framework bietet an, den kompletten Rumpf auf ein Objekt abzubilden — eine Zeile Code statt zwanzig. Der Haken: Damit entscheidet der Aufrufer, welche Felder er setzt, und nicht Sie. Solange er nur die vorgesehenen kennt, fällt nichts auf.

4:11 Die Abhilfe ist unspektakulär und wirksam: Das Schema nennt die erlaubten Felder abschließend, und alles andere wird verworfen oder abgelehnt. Der Vertrag ist hier also gleichzeitig Sicherheitsmaßnahme. Sie sehen hier eine ganz normale Bestellung — mit einem Feld, das dort nichts zu suchen hat. Der Rabattsatz gehört der Hofkiste, nicht dem Kunden.

4:32 Wenn Ihre Anwendung den Rumpf ungeprüft übernimmt, hat der Kunde sich soeben neunzig Prozent Rabatt gegeben. Was mich an diesem Beispiel überzeugt, ist seine Unauffälligkeit: Es sieht aus wie ein Tippfehler, es erzeugt keinen Fehler, und in den Logs steht eine erfolgreiche Bestellung. Genau deshalb muss das Schema abschließend sein und nicht großzügig.

4:52 Der erste Punkt hat sich mit der Cloud verändert: Früher bedeutete Überlast eine langsame Anwendung, heute bedeutet sie eine Rechnung. Ein Aufrufer, der Ihre API in einer Schleife befragt, skaliert Ihre Umgebung nach oben und Ihr Budget nach unten. Deshalb gehören Grenzen für Seitengröße, Rumpfgröße und Nebenläufigkeit in den Entwurf.

5:12 Der vierte Punkt ist der subtilste und steht in der OWASP-Liste als eigener Eintrag: fachliche Abläufe, die einzeln harmlos sind — etwa das Anlegen von Konten oder Reservierungen —, in Masse aber das Geschäft schädigen. Der zweite und der dritte Punkt beschreiben zusammen ein Risiko, das viele unterschätzen. Antworten fremder Dienste werden weniger streng geprüft als Nutzereingaben, weil die Quelle vertrauenswürdig wirkt — die OWASP-Liste führt genau das als eigenen Punkt.

5:39 Und wenn Ihr Server eine Adresse abruft, die der Aufrufer geliefert hat, dann ruft er möglicherweise Ihre internen Dienste ab, an denen keine Anmeldung hängt. Der vierte Punkt ist ein Konfigurationsfehler mit Ansage: Rate Limits je Server statt je Aufrufer skalieren mit Ihrer eigenen Infrastruktur weg.

OWASP API Security Top 10 anwenden

5:56 Kommen wir zum Prüfraster. Die OWASP-Liste ist keine Zertifizierung und kein Regelwerk — sie ist eine gut begründete Aufzählung dessen, was in der Praxis tatsächlich schiefgeht. Sie beruht auf ausgewerteten Vorfällen, und ihre Reihenfolge ist deshalb aufschlussreicher als jede selbst gebaute Prüfliste. Wir gehen sie durch und ordnen sie ein.

6:17 Bemerkenswert an der Liste ist ihre Reihenfolge. Auf den vorderen Plätzen stehen nicht kryptografische Schwächen oder ausgefeilte Angriffe, sondern fehlende Berechtigungsprüfungen. Das ist ein bemerkenswerter Befund: Die häufigsten Sicherheitsprobleme von APIs sind Entwurfs- und Sorgfaltsfehler, keine technischen Raffinessen.

6:36 Was das für Sie bedeutet, ist ermutigend — Sie brauchen kein Spezialwissen, um die wichtigsten Risiken zu adressieren. Sie brauchen Systematik im Entwurf und im Review. Statt die Liste vorzulesen, drei Beobachtungen. Erstens: Drei der zehn Einträge betreffen Autorisierung — auf Objektebene, auf Eigenschaftsebene, auf Funktionsebene.

6:57 Das ist ein Drittel der Liste für ein einziges Thema. Zweitens: Zwei Einträge betreffen Ressourcenverbrauch und sensible Geschäftsabläufe, also das, was wir gerade besprochen haben. Und drittens, aus der Fußnote: Die letzten beiden Plätze handeln von Inventar und vom Vertrauen in fremde APIs. Beides sind Organisationsthemen, keine Codethemen.

7:20 Improper Inventory Management klingt nach Verwaltung und ist ein handfestes Sicherheitsrisiko. Der Mechanismus ist immer derselbe: Was nicht dokumentiert ist, wird nicht geprüft — kein Review, kein Scan, kein Test. Alte Versionen laufen weiter, weil niemand merkt, dass sie noch angesprochen werden. Testumgebungen mit echten Daten sind erreichbar, weil sie in keiner Liste stehen.

7:43 Und hier kommt der Bogen zurück zu unserem Thema: Der Vertrag ist genau dieses Inventar — vorausgesetzt, er ist vollständig. Ein gepflegtes OpenAPI-Dokument ist deshalb auch eine Sicherheitsmaßnahme. Der erste Punkt beschreibt den verbreitetsten Umgang mit der Liste: abhaken vor dem Release. Das findet, was offensichtlich ist, und verhindert nichts — denn Berechtigungsmodelle nachträglich zu ändern, ist teuer.

8:08 Der dritte Punkt ist die Annahme, die in den letzten Jahren am gründlichsten widerlegt wurde: Ein Endpunkt sei sicher, weil er nur intern erreichbar ist. Interne Netze sind groß, und der erste kompromittierte Dienst darin ist der Ausgangspunkt für alles Weitere.

Übung

8:23 In der Übung schauen wir uns die häufigste API-Schwachstelle im eigenen Beispiel an. Und Sie werden sehen: Sie ist nicht spektakulär, sondern banal — und genau deshalb so verbreitet. Es geht um die häufigste Schwachstelle überhaupt — und Sie werden sehen, dass sie nicht raffiniert ist, sondern schlicht übersehen wurde. Genau das macht sie so verbreitet.

8:44 Ein Logistikpartner der Hofkiste kann Bestellungen fremder Kunden lesen, weil er nur die Kennung ändern muss. Ihre Aufgabe ist, die fehlende Prüfung zu benennen, sie zu ergänzen und die Antwort festzulegen. Dazu ergänzen Sie die securitySchemes im Vertrag. Der spannendste Teil ist die Erweiterung: Ist 403 oder 404 die bessere Antwort? Ein 403 verrät, dass das Objekt existiert; ein 404 verrät es nicht.

9:10 Diese Wahl ist selbst eine Sicherheitsentscheidung — und sie hat Nebenwirkungen für die Fehlersuche. Der erste Schritt ist wichtiger, als er klingt: Stellen Sie den Zugriff wirklich nach, mit einem fremden Bezeichner. Eine Schwachstelle, die man gesehen hat, prägt sich anders ein als eine, über die man gelesen hat. Der letzte Schritt schlägt den Bogen zu API9: Vergleichen Sie Ihre tatsächliche Endpunktliste mit dem, was im Vertrag steht.

9:37 Erfahrungsgemäß findet sich mindestens einer, den niemand mehr auf dem Schirm hatte — meist ein Hilfs- oder Testendpunkt aus der Anfangszeit. Der erste Punkt ist die Versuchung, die immer besteht: Die Prüfung wandert in den Client, weil dort die Daten schon vorliegen. Damit ist sie wirkungslos, denn ein Angreifer benutzt Ihren Client nicht.

9:57 Der zweite Punkt ist der halbe Weg beim 404 — die Existenz wird über die Antwortzeit trotzdem verraten, weil die Datenbank bei existierenden Objekten länger braucht. Und der dritte ist der klassische unvollständige Fix: Der Lesezugriff wird abgesichert, das Ändern bleibt offen.