Checkliste für REST-API-Sicherheitstests

REST-API-Sicherheitstests sind die Praxis, nachzuweisen, dass ein angemeldeter Benutzer nicht erreichen kann, was ihm nicht gehört. Sie sind wichtig, weil die meisten Angriffe genau aus dieser Position kommen und nicht durch einen Einbruch. Ihre Anmeldemaske kann makellos sein, während der Endpunkt dahinter einem zahlenden Kunden die Rechnung eines anderen aushändigt.

Solche Lücken zu finden braucht nichts Spezielles, nur zwei gewöhnliche Konten und ein Werkzeug, das Anfragen senden kann. Der schwierige Teil ist, diese Arbeit vor jedem Release zu wiederholen, ausnahmslos. Viele Teams schaffen das ein paar Monate lang und hören dann stillschweigend auf, weshalb sich ein fester QA-Partner lohnt. Unsere Dienstleistungen für Penetrationstests gehen noch weiter, wenn es die Sache erfordert, einen externen Experten hinzuzuziehen.

So testen Sie Authentifizierung und Autorisierung an jedem Endpunkt

Authentifizierung fragt, wer Sie sind. Autorisierung fragt, was Sie tun dürfen, sobald das System das weiß. Jeder Benutzer begegnet der Anmeldemaske, deshalb wird Ersteres sorgfältig gebaut und funktioniert meistens. Letzteres wird an den Endpunkten geprüft, an die jemand gedacht hat, und an denen übersprungen, an die niemand gedacht hat.

Salt Labs verfolgte ein Jahr echter Angriffe und stellte fest, dass 95% aus authentifizierten Quellen kamen, die Aufrufer, über die man sich Sorgen machen sollte, sind also bereits durch die Tür.

Die Checkliste für REST-API-Sicherheitstests beginnt hier, wo jede Prüfung dieselbe Form hat: Senden Sie eine Anfrage, die abgelehnt werden sollte, von einem Aufrufer, der kein Recht hat, sie zu stellen.

• Rufen Sie jeden Endpunkt ganz ohne Zugangsdaten auf. Alles, was mit Daten statt mit einer Ablehnung antwortet, ist ein Befund.
• Wiederholen Sie das mit abgelaufenen Zugangsdaten und dann mit solchen, die zu einem anderen Konto gehören.
• Melden Sie sich als gewöhnlicher Benutzer an und fordern Sie einen reinen Administrator-Endpunkt direkt über seine Adresse an, ohne die Oberfläche zu berühren.
• Bestätigen Sie, dass Zugangsdaten in dem Moment ungültig werden, in dem sich jemand abmeldet oder ein Administrator das Konto deaktiviert.
• Prüfen Sie den Weg zum Zurücksetzen des Passworts von beiden Enden. Ein Link, der nach der Nutzung gültig bleibt oder für eine fremde Adresse angefordert werden kann, hebt alles andere auf dieser Liste auf.

Das Muster, das man sich merken sollte: Eine korrekte API lehnt ab. Sie gibt keine leere Liste zurück, keinen Teildatensatz und keine freundliche Nachricht darüber, was man fast bekommen hätte. Solche Beinahetreffer verraten einem Angreifer, dass die Adresse echt war und einen weiteren Versuch wert ist.

BOLA-Schwachstelle: wenn eine ID die Daten einer anderen Person zurückgibt

Hier ist die häufigste REST-API-Schwachstelle, und sie trägt einen hässlichen Namen: gebrochene Autorisierung auf Objektebene, meist als BOLA abgekürzt.

Die Idee ist einfacher als der Begriff. Webadressen in einer REST-API benennen meist den angefragten Datensatz, eine Rechnung liegt also womöglich unter /invoices/8812. Eine BOLA-Schwachstelle liegt vor, wenn ein angemeldeter Kunde diese Nummer auf 8813 ändert und stattdessen den Kontoauszug eines anderen Unternehmens liest. Die Anmeldung funktionierte genau wie vorgesehen. Was nie geschah, war eine zweite Prüfung, nämlich die Frage, ob dieser Kunde jenen Datensatz besitzt.

BOLA ist die API-Variante eines größeren Problems, das wir in unserem Artikel über gebrochene Zugangskontrolle behandeln. Salt Labs zählt es zusammen mit Injection-Fehlern, bei denen ein Angreifer einen Befehl in einem gewöhnlichen Formularfeld versteckt. Beide zusammen machten 37% aller gemeldeten Probleme aus, der größte Einzelanteil.

BOLA zu testen ist unspektakulär und schnell:

• Legen Sie zwei gewöhnliche Konten an. Melden Sie sich mit dem ersten an und notieren Sie die IDs, die Ihnen rechtmäßig gehören.
• Fordern Sie die IDs des zweiten Kontos an, während Sie noch im ersten angemeldet sind. Tun Sie das für Lesen, Aktualisieren und Löschen, denn viele APIs schützen eine dieser Aktionen und vergessen die anderen.
• Probieren Sie IDs aus, die niemandem gehören, und weitere aus einem benachbarten Bereich. Eine Antwort, die zwischen “gehört Ihnen nicht” und “existiert nicht” unterscheidet, verrät, welche Datensätze echt sind.
• Wiederholen Sie das an jedem Endpunkt, der eine ID annimmt, einschließlich Berichten, Exporten und Anhängen. Diese werden übersehen, weil sie sich wie Funktionen anfühlen und nicht wie Daten.
• Prüfen Sie auch verschachtelte Adressen. /orders/88 zu schützen bringt wenig, wenn /orders/88/items jedem antwortet.

Diese Prüfungen zu automatisieren zahlt sich aus, denn dieselben zwei Konten können bei jedem Release Hunderte gepaarter Anfragen antreiben. Solche Tests zu schreiben und zu pflegen ist die Arbeit unseres Teams für Automatisierungstests.

So testen Sie das Rate Limiting einer REST-API

Ein Rate Limit ist eine Obergrenze dafür, wie oft ein einzelner Aufrufer fragen darf. Ohne sie kann ein einziges Skript die ganze Nacht Passwörter raten, einen kostenpflichtigen Dienst leersaugen, den Sie weiterverkaufen, oder schlicht den Server für alle anderen erschöpfen.

Wenn ein Aufrufer die Grenze überschreitet, lautet die richtige Antwort Statuscode 429, also “zu viele Anfragen”. Die falschen Antworten sind eine langsame Seite, ein Timeout oder ein 500er-Fehler, der einen Absturz meldet statt einer bewussten Ablehnung.

Die folgenden Prüfungen treiben die API über ihr Limit hinaus, führen Sie sie deshalb gegen eine Testumgebung aus und nicht gegen die Produktion.

• Senden Sie einen Schwall von Anfragen weit jenseits dessen, was ein echter Client erzeugen würde, und bestätigen Sie dann, dass Sie 429-Antworten erhalten statt Schweigen.
• Prüfen Sie, ob die Grenze pro Konto und pro Adresse gilt und nicht nur global. Eine rein globale Obergrenze lässt einen missbräuchlichen Aufrufer den Dienst für alle verschlechtern.
• Nehmen Sie gezielt die Wege für Anmeldung und Passwort-Zurücksetzung unter Beschuss. Sie verdienen strengere Grenzen als der Rest, denn dort lohnt sich das Raten.
• Betrachten Sie teure Endpunkte gesondert. Eine Suche oder ein Bericht, der eine Sekunde Serverzeit kostet, braucht eine niedrigere Decke als einer, der einen Namen zurückgibt.
• Bestätigen Sie, dass sich die Grenze sinnvoll zurücksetzt und dem Aufrufer sagt, wann er es erneut versuchen soll, damit legitime Clients zurückstecken statt in eine Schleife zu geraten.

Rate Limits schützen Sie auch vor Ihren eigenen Kunden. Deren Software kann dieselbe fehlgeschlagene Anfrage ohne Pause immer weiter senden. Von der Seite Ihres Servers aus sieht das genau wie ein Angriff aus.

Eingabevalidierung: was Ihre API mit einer fehlerhaften Anfrage macht

Jedes Feld, das Ihre API annimmt, ist eine Stelle, an der jemand einen Wert eintragen kann, mit dem Sie nicht gerechnet haben. Funktionstests decken die Werte ab, die Ihre eigene Anwendung senden würde, und das ist das meiste, was ein echter Kunde je erzeugt. Allerdings tippt niemand einen Namen mit Tausenden von Zeichen, bestellt minus fünf Stück von etwas oder wählt ein Lieferdatum im Jahr 3000, Ihre API sieht so etwas im Normalbetrieb also nie.

Früher oder später sendet es trotzdem jemand, entweder ein Angreifer beim Abtasten oder eine Software, die aus dem Ruder läuft. Der Schaden ist selten dramatisch. Häufiger speichert die API den Unsinn und irgendetwas anderes im System bricht Wochen später, oder sie liefert einen Fehler zurück, der so detailliert ist, dass er Ihre Datenbank und deren Version benennt.

Um das zu testen, füttern Sie den Endpunkt mit Werten, die er nie annehmen sollte, und beobachten dann, wie er reagiert.

• Senden Sie in jedem Feld den falschen Typ: Text, wo eine Zahl hingehört, eine Zahl, wo ein Datum hingehört, gar nichts, wo etwas verlangt wird.
• Senden Sie Werte weit außerhalb des sinnvollen Bereichs, einschließlich negativer Zahlen, null und Längen, die in die Megabyte gehen.
• Senden Sie Felder, die der Endpunkt nie dokumentiert hat. Eine Aktualisierung, die stillschweigend is_admin oder credit_limit annimmt, lässt einen Kunden sich selbst befördern, und sie verdient an jedem Endpunkt, der Daten speichert, einen Blick.
• Senden Sie Zeichen, die für eine Datenbank oder eine Kommandozeile eine Bedeutung haben. Injection funktioniert genau so, bestätigen Sie also, dass sie als reiner Text zurückkommen und nicht als Anweisungen.
• Lesen Sie die Fehlermeldungen. Eine Ablehnung sollte sagen, dass die Anfrage falsch war, und nicht die Bibliothek benennen, die sie zurückgewiesen hat, oder die Tabelle, an der sie scheiterte.

Der Fehler, den Sie jagen, ist eine API, die ihrem eigenen Frontend vertraut. Wenn Ihre eigene Anwendung nie einen fehlerhaften Wert sendet, wurde der Endpunkt dahinter vielleicht nie gebeten, Nein zu sagen.

CORS, JWT und zu viel Auskunft: drei Wege, auf denen REST-APIs Daten preisgeben

Drei Dinge machen den Großteil der versehentlichen Preisgabe aus, und bei keinem davon bricht ein Angreifer irgendetwas auf.

CORS steht für Cross-Origin Resource Sharing. Ein Browser hindert normalerweise eine Website daran, Daten zu lesen, die einer anderen gehören, und CORS ist der Weg, auf dem Ihre API eine Ausnahme gewährt. Auf “alle zulassen” gestellt, lädt es jede Seite im Internet ein, Anfragen mit der Sitzung eines Besuchers zu stellen. Bestätigen Sie, dass die Erlaubnisliste nur Ihre echten Domains nennt, dass Zugangsdaten allein für diese zulässig sind und dass niemand nach dem Debuggen eine offene Regel hinterlassen hat.

JWT steht für JSON Web Token. Er funktioniert wie ein Ausweis: Ihre API gibt nach der Anmeldung einen aus, und die Anwendung schickt ihn bei jeder weiteren Anfrage mit. Eine Signatur beweist, dass der Token echt und unverändert ist, Ihr Server muss also nie erneut nach dem Passwort fragen. Diese Abkürzung setzt vier Dinge auf Ihre Checkliste:

• Bestätigen Sie, dass Token ablaufen und dass ein alter tatsächlich abgelehnt wird, statt mit einer Warnung akzeptiert zu werden.
• Prüfen Sie, ob die Signatur kontrolliert wird. Eine API, die einen Token akzeptiert, der von sich behauptet, gar keine zu haben, ist ein bekannter und schwerwiegender Fehler.
• Prüfen Sie, was der Token enthält. Wer ihn besitzt, kann den Inhalt lesen, eine E-Mail-Adresse ist also in Ordnung, ein Passwort oder eine interne Notiz nicht.
• Stellen Sie sicher, dass eine Abmeldung oder ein Entzug des Zugangs durch einen Administrator die Sitzung beendet, bevor der Token von selbst ablaufen würde.

Zu viel Auskunft bedeutet eine Antwort, die mehr Daten mitführt, als der Bildschirm je anzeigt. Ein Kunde sieht seinen Namen und die Bestellsumme, während die Antwort dahinter auch eine Bonitätsbewertung, den Einkaufspreis eines Lieferanten oder die E-Mail-Adresse eines anderen Kunden enthält. Nichts davon erscheint auf dem Bildschirm, und alles davon hat den Browser trotzdem erreicht. Salt Labs beziffert die Preisgabe sensibler Daten auf 34% der gemeldeten Probleme, knapp hinter den 37% für Autorisierungs- und Injection-Fehler. Lesen Sie die Rohantwort jedes Endpunkts, der einen Datensatz zurückgibt, und vergleichen Sie sie mit dem, was dieser Benutzer sehen darf.

REST-API-Sicherheitstests an einem laufenden Produkt

Ein Kundenprojekt zeigt die ganze Checkliste bei der Arbeit. Union54 gibt Zahlungskarten für Fintech-Unternehmen in ganz Afrika aus. Als wir dazustießen, hatte das Produkt überhaupt kein Frontend, jede Prüfung lief also direkt gegen die Endpunkte. In dieser Lage landen Sie immer dann, wenn die Oberfläche dem Backend hinterherhinkt oder nie gebaut wird. Unsere Praxis für API-Tests legt die Sicherheitsprüfungen in denselben Durchgang wie die funktionalen, statt sie für später aufzuheben.

Die manuelle Arbeit lief über Postman, was zu einer API passt, an der es nichts zu klicken gibt. Die Automatisierung begann in Mocha und wechselte zu Cypress, als die Suite wuchs und Stabilität zum Problem wurde. Diesen Wechsel macht man besser früh als spät. Am Ende erreichte die automatisierte Abdeckung 90% der Endpunkte über mehr als 1.500 Szenarien. Die Zusammenarbeit brachte über 190 Defekte zutage, alle innerhalb eines Zweimonatsfensters, das die Investorendemo des Kunden vorgab.

Einer dieser Defekte zeigt, warum das Lesen von Antworten wichtig ist. Eine Karte meldete zurück, sie habe ein Guthaben von null und den Status ausgegeben, während die Datenbank dahinter ein positives Guthaben und den Status gesperrt enthielt. Beide Antworten waren wohlgeformt und keine sah kaputt aus. Erst der Vergleich der Antwort mit dem darunterliegenden Datensatz zeigte, dass dem Aufrufer etwas Unwahres über sein eigenes Geld erzählt wurde.

Dieser Vergleich ist die Gewohnheit, die diese Checkliste lehrt. Funktionale Arbeit fragt, ob eine Antwort ankommt. Sicherheitsarbeit fragt, ob sie hätte ankommen dürfen.

Wo die REST-API-Sicherheitscheckliste endet

Arbeiten Sie diese Liste bei jedem Release durch, und Sie finden die teuren Probleme, solange ihre Behebung noch günstig ist. Eine funktionale Suite meldet keines davon, denn soweit sie das beurteilen kann, kam jede Antwort genau wie vorgesehen.

Drei Tätigkeiten werden unter “API-Tests” in einen Topf geworfen, und es macht einen Unterschied, zu wissen, welche Sie gerade einkaufen:

Die mittlere Zeile ist das, was Sie gerade durchgearbeitet haben. Unsere Checkliste für REST-API-Tests deckt die erste ab. Beide passen gut zusammen, denn viele Sicherheitsprüfungen sind ein funktionierender Funktionstest mit umgedrehtem Erwartungswert.

REST ist nicht die einzige Art, eine API zu bauen. Für dieselben Probleme in GraphQL, gRPC und SOAP arbeitet sich unser Leitfaden zu API-Sicherheitstests durch die OWASP API Top 10, die Standardrangliste der API-Risiken in der Branche.

Die dritte Zeile einzukaufen ist eine eigene Entscheidung. Eine solche Zusammenarbeit passt zu einem großen Release, einem Schritt in einen regulierten Markt oder einem Unternehmenskunden, der vor der Unterschrift Belege will. Sie bringt mehr, sobald Ihre eigenen Leute die einfachen Befunde beseitigt haben, denn einen Experten dafür zu bezahlen, sie neu zu entdecken, ist verschwendetes Geld.

Neugierig, was Ihre Endpunkte einem angemeldeten Aufrufer preisgeben, der sich umsieht? Buchen Sie eine Prüfung mit unserem QA-Team.

FAQ

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