API-Sicherheit: die wesentlichen Schritte, um die Tür nicht offen zu lassen

Wenn wir an Systemsicherheit denken, schauen wir auf den Bildschirm: das starke Passwort, die Browsersperre, die Zwei-Faktor-Anmeldung. Doch der Angreifer schaut nicht auf den Bildschirm. Es befasst sich mit der API, der Datenbereitstellungsschicht hinter der Schnittstelle, in der es einfach keine sichtbaren Schutzmaßnahmen gibt.

Das ist die gefährliche Asymmetrie moderner Anwendungen. Die Benutzeroberfläche wurde für Menschen entwickelt und verbirgt die Komplexität. Die API wurde für Maschinen entwickelt und macht alles direkt verfügbar. Ein Angreifer umgeht die Schaltflächen und kommuniziert direkt mit der API, wo die Verhaltensregeln der Schnittstelle nicht gelten.

Man kann ohne Übertreibung sagen, dass APIs zum Hauptangriffsvektor für digitale Systeme geworden sind. OWASP selbst führt eine spezifische Liste der wichtigsten API-Sicherheitsrisiken, getrennt von der allgemeinen Liste der Webanwendungen, gerade weil die Probleme ihrer eigenen Natur sind. Dieser Artikel ist eine Roadmap der wesentlichen Schritte zur Sicherung einer API für Teams, die bereits APIs in der Produktion haben und sicherstellen müssen, dass es sich nicht um eine Hintertür handelt.

Warum die API der zielgerichteteste Link ist

Die Benutzeroberfläche filtert, was Sie sehen. Wenn die API schlecht gestaltet ist, liefert sie viel mehr als das, was der Bildschirm anzeigt. Es ist üblich, dass eine API ein gesamtes Benutzerobjekt zurückgibt, einschließlich Feldern, die die Schnittstelle nie anzeigt, da es einfacher war, alles zu senden und dem Frontend die Auswahl zu überlassen, was angezeigt werden soll. Der Angreifer, der sich die Rohantwort ansieht, findet dort Daten, die niemand sehen sollte.

Ergänzen Sie diese Automatisierung. Ein Angreifer testet nicht wie ein Mensch jeweils eine Anfrage. Es scannt Tausende von Kombinationen pro Sekunde und prüft dabei Identifikatoren, Parameter und Endpunkte. Ein Fehler, der manuell nur schwer auszunutzen wäre, wird im automatisierten Maßstab trivial.

Die These: Der Schutz der Schnittstelle ohne den Schutz der API verschließt die Vordertür und lässt die Hintertür weit offen. Echte Sicherheit liegt auf der Ebene, die die Daten bereitstellt, und nicht auf der Ebene, die sie präsentiert.

Schritt 1: Starke Authentifizierung bei jeder Anfrage

Bei jedem API-Aufruf muss nachgewiesen werden, wer ihn ausführt. Es reicht nicht aus, die Anmeldung zu sichern und dem Rest zu vertrauen. Jede Anfrage an eine geschützte Ressource muss einen gültigen Berechtigungsnachweis enthalten, normalerweise ein Token, den der Server überprüft.

Die größte Sorgfalt liegt bei der Verwaltung dieser Token. Sie müssen eine begrenzte Gültigkeit haben, damit ein gestohlener Token nicht für immer verwendet werden kann. Sie müssen widerrufbar sein. Und sie sollten niemals auf unsichere Weise transportiert oder gelagert werden. Langlebige, nie widerrufene Token führen zu einer Katastrophe: Alles, was es braucht, ist ein Leck.

Der häufige Fehler besteht darin, Authentifizierung als etwas zu behandeln, das einmal gelöst wird. Tatsächlich handelt es sich um eine fortlaufende Disziplin der Ausstellung, Validierung, des Ablaufs und des Widerrufs von Anmeldeinformationen.

Schritt 2: Berechtigungsprüfung bei jedem Zugriff

Dies ist der wichtigste und am meisten übersehene Schritt. Die Authentifizierung antwortet mit „Wer sind Sie?“. Die Autorisierung antwortet: „Können Sie auf dies zugreifen?“. Es handelt sich um unterschiedliche Fragen, und die schwerwiegendsten API-Lecks entstehen dadurch, dass man die erste beantwortet und die zweite vergisst.

Das Fehlermuster hat einen Namen in der OWASP-Liste: fehlerhafte Autorisierung auf Objektebene. Das System bestätigt, dass Sie angemeldet sind, überprüft jedoch nicht, ob diese spezifischen Daten Ihnen gehören. Das Ergebnis ist der klassische Angriff, die Zahl in der URL zu ändern: Sie fragen /pedidos/123 ab, ändern sie in /pedidos/124 und sehen die Anfrage einer anderen Person.

Die nicht verhandelbare Regel: Bei jedem Zugriff auf eine Ressource muss der Server prüfen, ob dieser bestimmte Benutzer Anspruch auf diese bestimmte Ressource hat. Diese Prüfung kann nicht auf dem Client lokalisiert werden, den der Angreifer kontrolliert. Es muss ausnahmslos bei jeder Anfrage auf dem Server vorhanden sein.

Schritt 3: Validieren und begrenzen Sie alles, was hereinkommt

Die API kann nichts vertrauen, was von außen kommt. Alle Eingaben, Parameter, Anforderungstexte und Header müssen vor der Verwendung auf Format, Typ und Größe überprüft werden. Vertrauen in Eingaben ist die Wurzel von Injektionsangriffen, bei denen bösartige Daten als Befehle interpretiert werden.

Eine strenge Validierung auf dem Server ist die Verteidigung. Die clientseitige Validierung dient dem Komfort des Benutzers und nicht der Sicherheit, da der Angreifer einfach den Client umgeht und direkt mit der API kommuniziert.

Es lohnt sich auch, das Versendevolumen einzuschränken. APIs, die große Nutzlasten oder Abfragen akzeptieren, die große Datenmengen zurückgeben, sind Vektoren sowohl für Überlastung als auch für die Massenextraktion von Informationen.

Schritt 4: Begrenzen Sie die Anfragerate

Ohne Ratenbegrenzung ist eine API Brute-Force-Missbrauch und massiver Datenexfiltration ausgesetzt. Ein Angreifer kann Tausende von Passwörtern pro Minute ausprobieren oder alle möglichen Kennungen durchlaufen, um die gesamte Datenbank herunterzuladen, indem er einfach viele schnelle Anfragen stellt.

Ratenbegrenzung, Ratenbegrenzung, schränkt ein, wie viele Anfragen ein Client in einer bestimmten Zeit stellen kann. Es handelt sich um einen einfachen und leistungsstarken Schutz gegen böswillige Automatisierung, Denial-of-Service-Angriffe und Data Scraping. Sein Fehlen macht jeden anderen Fehler zu etwas, das im industriellen Maßstab ausgenutzt werden kann.

Schritt 5: Das Minimum freilegen und alles aufzeichnen

Zwei Übungen schließen das Wesentliche ab. Der erste besteht darin, die Belichtung zu sparen: Die API sollte nur die für den Vorgang erforderlichen Daten zurückgeben, niemals „der Einfachheit halber“ das vollständige Objekt. Mit jedem weiteren offengelegten Feld können mehr Daten verloren gehen. Fehlermeldungen sollten auch keine internen Details preisgeben, die dem Angreifer helfen, das System zu kartieren.

Die zweite ist die Protokollierung und Überwachung. Ohne Protokolle darüber, was in der API passiert, kann ein Angriff wochenlang andauern, ohne dass es bemerkt wird. Durch die Aufzeichnung von Zugriffen, Authentifizierungsfehlern und abnormalen Mustern können Sie diese erkennen und darauf reagieren. In Systemen unter LGPD ist es nicht nur eine gute Sicherheitspraxis, zu wissen, was wann mit den Daten passiert ist, sondern auch Teil der rechtlichen Verantwortung, Rechenschaft abzulegen.

Kritische Überlegung: API-Sicherheit ist eine fortlaufende Arbeit

Der häufigste Fallstrick besteht darin, die API-Sicherheit als einmalige Prüfung beim Start zu behandeln. APIs entwickeln sich weiter, erhalten neue Endpunkte und lassen sich in neue Systeme integrieren. Jede Änderung ist eine Gelegenheit, einen Fehler einzuführen. Die Angriffsfläche wächst mit jeder Veröffentlichung und die Überwachung muss mit ihr wachsen.

Es gibt auch das Problem vergessener APIs. Alte Versionen, die noch aktiv sind, Testendpunkte, die offengelegt sind, Integrationen, die niemand mehr pflegt. Diese Ghost-APIs gehören zu den am häufigsten ausgenutzten Vektoren, da sie niemandem aufgefallen sind. Die Führung einer Bestandsaufnahme der offengelegten Daten ist ein wesentlicher Bestandteil der Verteidigung.

Die strategische Vision für diejenigen, die führen: Die API ist der Ort, an dem Ihr System wirklich lebt. Wenn Sie in die Schnittstellensicherheit investieren, während die API ungeschützt bleibt, investieren Sie in das Erscheinungsbild der Sicherheit, nicht in die Sicherheit. Moderne Vorfälle entstehen dort, wo die Daten tatsächlich übertragen werden, und das ist die API.

Die Sicherung einer API erfordert kein Genie. Es erfordert die konsequente Anwendung der Grundlagen: Authentifizieren Sie jede Anfrage, autorisieren Sie jeden Zugriff, validieren Sie jede Eingabe, begrenzen Sie die Rate, legen Sie das Minimum offen und protokollieren Sie alles. Wer dies diszipliniert tut, verschließt die Tür, durch die die meisten Angriffe eindringen würden.

Wenn Ihre Organisation über APIs in der Produktion verfügt und diese noch nie einer ernsthaften Sicherheitsüberprüfung unterzogen hat, ist dies ein blinder Fleck, der vorrangig angegangen werden sollte. Es gibt weitere Blogartikel zu Authentifizierung, OWASP und sicherer Architektur, die tiefer auf jeden Schritt eingehen. Wenn die API-Sicherheit in Ihrem Kontext ein echtes Problem darstellt, lohnt es sich, darüber zu sprechen.