API-Sicherheitstests: Ein Vollständiger Leitfaden

Ihre bestehenden Prüfungen beweisen wahrscheinlich eine Sache gut: dass der Dienst sich für jeden korrekt verhält, der die Regeln befolgt. Ob er auch die abweist, die es nicht tun, ist eine andere Frage, und eine, die die meisten Release-Zyklen nie erreichen. API-Sicherheitstests untersuchen, ob jemand, der bereits weiß, wie man mit Ihren Endpunkten spricht, sie zum Fehlverhalten bringen kann.

Sie untersuchen, wie Sie mit Logins und Tokens umgehen, ob jede Anfrage tun darf, worum sie bittet, wie viel Traffic Sie zulassen, und was Ihre Antworten preisgeben. Diese Arbeit hat ihre eigene Risikoliste, die OWASP API Security Top 10. Sie ist nicht dasselbe wie die allgemeine Web-Anwendungsversion, der die meisten Checklisten folgen.

Drei der zehn API-Risiken sind Autorisierungsfehler, bei denen der Dienst genau weiß, wer fragt, und trotzdem Datensätze herausgibt, die jemand anderem gehören. Eine Web-Anwendungs-Checkliste fasst all das in eine breite Kategorie. Wir suchen während der alltäglichen QA nach diesen Fehlern, und führen Penetrationstest-Dienste durch, wenn ein Release eine tiefere, abgegrenzte Überprüfung erfordert.

Der Rest dieses Leitfadens behandelt, wie man jedes davon prüft.

Wie sich API-Sicherheitstests von Web-App-Sicherheitstests Unterscheiden

Sicherheitstests für Webanwendungen gehen von einer Person in einem Browser aus. Jemand füllt ein Formular aus, sendet es ab, und der Bildschirm entscheidet, was ihm gezeigt wird. Deshalb lebt ein Großteil des Schutzes auf dieser Seite: Felder, die Sie nicht bearbeiten können, Buttons, die Sie nie sehen, Menüs, die alles verbergen, was Sie nicht erreichen sollen.

Eine API hat nichts davon. Sie antwortet jedem, der eine korrekt formulierte Anfrage sendet, und der Aufrufer ist meist ein Skript statt einer Person. Was sind API-Sicherheitstests also in der Praxis? Es ist die Arbeit zu beweisen, dass Ihre API die Anfragen ablehnt, die sie ablehnen sollte, selbst wenn sie von einem erfolgreich angemeldeten Konto kommen.

Das ist die Verschiebung, die Teams überrascht. Klassisches Web-Testing verwendet den Großteil seines Aufwands darauf, Fremde draußen zu halten. Bei einer API hingegen starten Sie von der entgegengesetzten Prämisse: Der Aufrufer hat bereits ein gültiges Token. Die interessante Frage ist nicht mehr, wie er dorthin gelangte, sondern wie weit er jetzt reichen kann, wo er es hat.

Das hat zwei praktische Konsequenzen:

• Ihre Geschäftslogik liegt offen statt in einer Oberfläche verpackt, sodass eine Frontend-Prüfung nichts schützt.
• Ein Skript kann eine einzelne Anfrage tausende Male pro Minute wiederholen, was aus einem kleinen Versehen ein großes macht.

Die beiden OWASP-Listen spiegeln diese Aufteilung wider. Auf der Web-Anwendungsseite ist gebrochene Zugangskontrolle ein einzelner Eintrag, der alles von einer versteckten Admin-Seite bis zu einer manipulierten Datensatz-ID abdeckt. Die API-Version teilt denselben Bereich in drei separate Risiken auf, weil diese Fehler hier anders aussehen und sich anders verhalten. Für das Web-Äquivalent geht unsere Checkliste für Web-Penetrationstests darauf ein, während unsere Praxis für Sicherheitstests beide Oberflächen abdeckt.

Was Ist die OWASP API Security Top 10?

Die OWASP API Security Top 10 ist die Referenz für diese Arbeit, derzeit in ihrer Ausgabe von 2023. Sicherheitstests von API-Endpunkten folgen ihr meist eng, weil jeder Punkt einen Fehler benennt, den man nachprüfen kann, statt eines Prinzips, das man im Hinterkopf behalten sollte.

Ein Namensproblem sollte zuerst geklärt werden. Wenn Sie über „übermäßige Datenoffenlegung” als API-Risiko gelesen haben, war das der dritte Punkt der Ausgabe von 2019. Er wurde bei der Überarbeitung 2023 in API3 zusammengeführt, sodass der alte Begriff weiterhin in Artikeln und Tools auftaucht, während die aktuelle Liste es anders nennt.

Die Drei Arten, wie API-Autorisierung Versagt

Diese Einträge beschreiben denselben zugrunde liegenden Fehler auf unterschiedlichen Ebenen. Zusammen sind sie dort, wo die meisten echten API-Vorfälle beginnen, und sie erklären, warum dieses Risikoprofil nicht einfach eine Web-Anwendungs-Checkliste erben kann.

• API1, Objektebene. Ihre API identifiziert den Aufrufer, versäumt dann aber zu fragen, ob er den bestimmten Datensatz besitzt, den er angefordert hat. Zum Beispiel gelingt eine Abfrage für Rechnung 1041, also probiert jemand 1042 und erhält die Rechnung eines Fremden. Es zu finden ist unglamourös und wirksam: melden Sie sich als ein Kunde an, sammeln Sie die Identifikatoren, die Sie legitim besitzen, fordern Sie dann die an, die Sie nicht haben, und beobachten Sie, was zurückkommt. Eine korrekte API antwortet mit einer Ablehnung. Die verwundbare gibt Daten heraus.
• API3, Eigenschaftsebene. Hier gehört der Datensatz tatsächlich Ihnen, aber der Austausch trägt mehr, als er in die eine oder andere Richtung sollte. Ein Kundenprofil könnte einen internen Risiko-Score oder ein Reset-Token neben Name und Adresse zurückgeben, weil der Endpunkt das ganze Objekt sendet und darauf vertraut, dass die App nur einen Teil anzeigt. Das Umgekehrte passiert auch, wo ein Update ein Feld wie role oder account_balance akzeptiert, das kein Client setzen können sollte. Beide Richtungen brauchen Tests, denn eine Antwort, die die App nie anzeigt, hat Ihren Server trotzdem verlassen.
• API5, Funktionsebene. Diesmal ist die Operation außer Reichweite statt des Datensatzes. Ein Standardkonto ruft eine Administrator-Route auf und es funktioniert, weil nichts dahinter erneut prüft, wer fragt. Auf einer Website bleibt ein Admin-Bildschirm aus der Navigation versteckt und meist vergessen. Eine API hat kein Menü, also braucht jede privilegierte Aktion ihre eigene Absicherung, und jede muss von einem gewöhnlichen Konto aus versucht werden.

Beachten Sie, was die drei gemeinsam haben: nichts wurde eingebrochen. Jede Anfrage war korrekt formuliert, ordnungsgemäß authentifiziert, und beantwortet genau so, wie es der Code beabsichtigte. Deshalb überstehen sie funktionale Tests so bequem, und deshalb braucht das Auffangen einen Fall, der bewusst nach etwas fragt, das er nicht erhalten sollte.

Was für die Verbleibenden Sieben Risiken zu Prüfen Ist

Diese zählen weiterhin, obwohl jede weniger Ausführung braucht.

• API2, Authentifizierung. Schauen Sie sich an, wie Tokens ausgestellt werden, wie lange sie gültig bleiben, ob eines nach dem Abmelden noch funktioniert, und ob ein Passwort-Reset-Ablauf rückwärts durchlaufen werden kann.
• API4, Ressourcenverbrauch. Senden Sie mehr Traffic, als jeder echte Client würde, überdimensionierte Payloads, und Abfragen, von denen Sie wissen, dass sie teuer sind. Sie wollen eine klare Ablehnung statt eines langsamen Zusammenbruchs.
• API6, Geschäftsflüsse. Fragen Sie, was ein Konkurrent oder Wiederverkäufer mit unbegrenztem automatisiertem Zugriff auf eine korrekt funktionierende Funktion tun könnte. Ticketkauf und Gutscheineinlösung sind die üblichen Beispiele.
• API7, Request Forgery. Wo auch immer Ihre API eine Web-Adresse akzeptiert, richten Sie sie auf interne Infrastruktur und sehen Sie, ob sie gehorcht.
• API8, Konfiguration. Geschwätzige Fehler, fehlende Header, und Regeln, die jede Website Ihre API aufrufen lassen, leben alle hier. Unser Erklärer zu Sicherheitsfehlkonfiguration behandelt das Muster tiefer.
• API9, Inventar. Finden Sie heraus, was noch erreichbar ist. Alte Versionen, Staging-Routen, und Endpunkte, die in der Dokumentation fehlen, sind üblich, und was niemand pflegt, wird auch nicht gepatcht.
• API10, unsicherer Konsum. Behandeln Sie Daten, die von externen Diensten kommen, mit dem Misstrauen, das Sie auf Nutzereingaben anwenden, denn eine vertrauenswürdige Integration kann Ihnen trotzdem etwas Fehlerhaftes senden.

Wie REST, GraphQL, gRPC, und SOAP Ändern, Was Sie Testen

Die OWASP-Liste ist absichtlich protokollneutral, was bei der Planung hilft und bei der Ausführung zu kurz greift. API-Sicherheitstests müssen berücksichtigen, wie Ihr Dienst tatsächlich kommuniziert, denn dasselbe Risiko taucht je nach zugrunde liegender Technologie an einer anderen Stelle auf.

REST und GraphQL

REST ist dort, wo Objektebenen-Autorisierung am häufigsten scheitert, aus strukturellen statt kulturellen Gründen. Eine REST-Adresse benennt das, worum Sie bitten, sodass der Identifikator direkt dort zum Bearbeiten liegt. Nichts am Stil macht es weniger sicher, aber es macht einen bestimmten Fehler ungewöhnlich leicht zu begehen und einfach zu finden. Die detaillierte Version dieser Prüfung gehört in eine REST-spezifische Sicherheitscheckliste.

GraphQL verlagert die Exposition woandershin. Weil der Client seine eigene Abfrage zusammenstellt, kann eine einzige Anfrage tief verschachtelte, teure Daten anfordern, die keine REST-Route erlauben würde. Das macht API4 zu einer Designentscheidung statt einer Rate-Limit-Einstellung. Die andere häufige Nachlässigkeit ist Introspektion: die Funktion, die es jedem Client erlaubt, die API zu bitten, ihre eigene Struktur zu beschreiben. Öffentlich eingeschaltet gelassen, gibt sie einem Besucher eine vollständige Karte Ihres Datenmodells.

gRPC und SOAP

gRPC wirkt standardmäßig sicherer, größtenteils weil es kein bequemes Browser-Tooling gibt und die Nachrichten für eine Person unlesbar sind. Das arbeitet während der Tests mehr gegen Sie, als es in Produktion hilft. Service-Reflection, die einem Aufrufer erlaubt, jede verfügbare Methode aufzulisten, gibt einem Außenstehenden eine vollständige Karte Ihres Dienstes, wenn Sie sie eingeschaltet lassen. Berechtigungen müssen dann bei jeder einzeln geprüft werden, statt vom Transport angenommen zu werden.

SOAP kommt mit einer eingebauten Sicherheitsspezifikation namens WS-Security, und das schafft eine eigene Falle. Sie zu konfigurieren ist nicht dasselbe wie sie auf jede Operation anzuwenden. XML-Parser bringen zudem eine ganze Familie von Problemen mit sich, denen auf JSON aufgebaute Dienste nie begegnen.

Warum Gehören API-Sicherheitstests zur QA?

Der häufigste Fehler, den wir sehen, ist API-Sicherheitstests als einmaliges Projekt statt als Routinearbeit zu behandeln. Sie werden einmal jährlich geplant, von externen Spezialisten durchgeführt, und Wochen nach dem Release, das sie beschreiben, verschriftlicht.

Diese Anordnung verpasst die Autorisierungsfehler fast vollständig, aus einem einfachen Grund. Sie zu finden hängt davon ab, zu verstehen, was das Produkt tun soll. Doch ein Prüfer, der für zwei Wochen ankommt, hat keine Möglichkeit zu erkennen, welche Felder ein Kunde sehen sollte, welche Routen nur für Admins sind, oder wem welcher Datensatz gehört. Ihre QA-Ingenieure wissen das alles, weil sie die funktionalen Tests geschrieben haben, die diese Regeln kodieren.

Die Lösung ist eine kleine Gewohnheit bei jedem Release. Wer auch immer einen Endpunkt prüft, fragt auch nach einem Datensatz, den er nicht besitzt, und bestätigt die Ablehnung. Unsere Arbeit an API-Tests ist so aufgebaut, mit den Sicherheitsfällen, die neben den alltäglichen laufen, statt dahinter.

Das sahen wir bei Union54, einer kartenausgebenden API für afrikanische Fintechs, getestet ohne jegliche Oberfläche. Einige der Fehler, die wir meldeten, waren Autorisierungsfehler zwischen verschiedenen Nutzertypen. Nichts davon kam aus einer dedizierten Sicherheitsüberprüfung. Stattdessen gehörten diese Befunde QA-Ingenieuren, die das Produkt gut genug kannten, um zu bemerken, wenn die falsche Person die richtige Antwort bekam.

Das macht spezialisierte Arbeit nicht überflüssig. Ein gezielter Penetrationstest verdient sich seinen Platz weiterhin vor einem großen Launch, oder wenn ein Regulator oder ein großer Kunde einen verlangt. Er zahlt sich jedoch mehr aus, sobald die offensichtlichen Lücken geschlossen sind. Die Spezialisten verbringen ihre Zeit dann mit Problemen, die nur sie finden können.

Wie Man eine API-Sicherheitstest-Checkliste Erstellt

Zu wissen, wie man API-Sicherheit testet, erweist sich als weniger davon abhängig, was die Liste enthält, sondern mehr davon, wer sie verantwortet. Viele Teams haben ein Dokument, aber kaum jemand öffnet es während eines Releases.

Organisieren Sie Ihre um die OWASP-Kategorien statt um Ihre Endpunkte. Ein routenweises Inventar veraltet in der Woche, nachdem Sie es geschrieben haben, während diese Risikogruppierungen über Releases und Technologien hinweg stabil bleiben. Erfassen Sie unter jeder, was geprüft wird, für welche Pfade es gilt, und wer es abzeichnet.

Vier Entscheidungen bewirken mehr für eine Checkliste als ihr Inhalt:

• Geben Sie ihr einen Verantwortlichen mit der Befugnis, einen Launch zu blockieren, niemals ein gemeinsames Postfach.
• Binden Sie sie an den Release-Prozess, dem Ihr Team bereits folgt, statt an einen separaten Sicherheitskalender.
• Schreiben Sie jeden Eintrag als eine Anfrage plus eine erwartete Ablehnung, damit jeder sie ausführen und das Ergebnis lesen kann.
• Überarbeiten Sie sie, wann immer Sie eine Route hinzufügen, ein Berechtigungsmodell ändern, oder eine neue Drittintegration übernehmen.

Zwei angrenzende Stücke lohnt es sich, daneben offen zu halten:

• Unsere REST-API-Testcheckliste deckt die Zuverlässigkeitshälfte ab, und die Überschneidung ist nützlich, da ein Sicherheitsfall oft ein funktionaler mit umgekehrtem erwarteten Ergebnis ist.
• Unsere Arbeit zu API-Performance-Tests gehört auch hierher, weil was auch immer Missbrauch begrenzt, Sie auch durch einen Traffic-Spike trägt.

Eine Warnung zum Thema Tooling. Scanner leisten gute Arbeit bei Fehlkonfiguration und Token-Handhabung, wo Fehler erkennbaren Mustern folgen. Bei den drei Autorisierungsrisiken sind sie fast nutzlos, denn kein Tool kann wissen, wer eine bestimmte Rechnung besitzen sollte. Nur Ihr Team hat dieses Wissen, also gehört die Arbeit in die Qualitätssicherung statt außerhalb davon.

Wir prüfen APIs gegen die OWASP-Liste in welcher Phase auch immer sich Ihr Produkt befindet, ob der Build fertig ist oder die Endpunkte noch geschrieben werden. Um herauszufinden, was Ihre API an einen Aufrufer herausgibt, der um mehr bittet, als er sollte, sprechen Sie mit unserem QA-Team.

Sehen Sie ein Beispiel unserer Sicherheits-Code-Review einer US-amerikanischen E-Commerce-Plattform

Dieser Bericht hebt die von uns gefundenen Exploits hervor, kategorisiert nach Schweregrad, zusammen mit Empfehlungen zur Behebung.

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

PDF Erhalten