Heute kündigen wir Cloudflare Sequence Analytics für APIs an. Damit können Kunden, die API Gateway abonniert haben, die wichtigsten Sequenzen von API-Anfragen an ihre Endpunkte einsehen. Diese neue Funktion hilft ihnen, den Schutz zuerst auf die wichtigsten Endpunkte anzuwenden.
Was versteht man unter einer Sequenz? Es handelt sich einfach um eine zeitlich geordnete Auflistung von HTTP-API-Aufrufe, die von einem bestimmten Besucher beim Surfen auf einer Website, bei der Nutzung einer Anwendung auf einem Mobilgerät oder bei der Interaktion mit einem B2B-Partner über eine API gestellt werden. Beispielsweise könnte ein Ausschnitt aus einer Sequenz, die während einer Banküberweisung entsteht, folgendermaßen aussehen:
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-1wig{font-weight:bold;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}
| Order | Method | Path | Description |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id is the active user |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id is one of the user’s accounts |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id is a different account belonging to the user |
| 4 | POST | /api/v1/transferFunds | Containing a request body detailing an account to transfer funds from, an account to transfer funds to, and an amount of money to transfer |
Reihenfolge
Methode
Pfad
Beschreibung
1
GET
| Order | Method | Path | Description |
|---|---|---|---|
| 1 | GET | /api/v1/users/{user_id}/accounts | user_id is the active user |
| 2 | GET | /api/v1/accounts/{account_id}/balance | account_id is one of the user’s accounts |
| 3 | GET | /api/v1/accounts/{account_id}/balance | account_id is a different account belonging to the user |
| 4 | POST | /api/v1/transferFunds | Containing a request body detailing an account to transfer funds from, an account to transfer funds to, and an amount of money to transfer |
| … attacker copies the request to a debugging tool like Postman … | |||
| 5 | POST | /api/v1/transferFunds | Attacker has modified the POST body to try and trick the API |
| 6 | POST | /api/v1/transferFunds | A further modified POST body to try and trick the API |
| 7 | POST | /api/v1/transferFunds | Another, further modified POST body to try and trick the API |
/api/v1/users/{user_id}/accounts
„user_id“ ist der aktive Nutzer
2
GET
/api/v1/accounts/{account_id}/balance
„account_id“ ist eines der Konten des Nutzers, dessen Stand hier abgefragt wird
3
GET
/api/v1/accounts/{account_id}/balance
„account_id“ ist ein anderes Konto des Nutzers, dessen Stand hier abgefragt wird
4
POST
/api/v1/transferFunds
Enthält den Nachrichtenrumpf (Body) der Anfrage, in dem ein Absender- und ein Empfängerkonto für eine Überweisung sowie die zu überweisende Summe angegeben sind
Warum ist es für die API-Sicherheit wichtig, auf die Sequenzen zu achten? Würde die API in unserem Beispiel Anfragen für POST /api/v1/transferFunds ohne eine der vorherigen Aufrufe erhalten, wäre das verdächtig. Woher sollte der API-Client wissen, welche Kontonummern relevant sind, wenn er sie nicht für den Nutzer auflistet? Und woher sollte er wissen, wie viel Geld für eine Überweisung zur Verfügung steht? Bei diesem Beispiel mag die Sachlage klar erscheinen, aber die schiere Menge der Anfragen an eine bestimmte API, die im laufenden Betrieb genutzt wird, kann es menschlichen Analysten schwer machen, eine verdächtige Nutzung auszumachen.
Ein Ansatz zur Prüfung unzähliger potenzieller Bedrohungen, die von einem menschlichen Team nicht geleistet werden kann, besteht im Aufbau eines positiven Sicherheitsmodells. Anstatt nach Möglichkeit alles zu blockieren, was theoretisch eine Gefahr darstellen könnte, lässt man den bekanntermaßen gutartigen Traffic zu und blockiert alles andere standardmäßig.
Kunden konnten bereits positive Sicherheitsmodelle mit API Gateway in zwei Hauptbereichen erstellen: beim Schutz vor Missbrauch durch volumetrische Angriffe und bei der Schema-Validierung. Sequenzen werden künftig als dritte Säule eines positiven Sicherheitsmodells für den API-Traffic fungieren. API Gateway wird in der Lage sein, die Vorrangigkeit von Endpunkten in einer bestimmten API-Sequenz durchzusetzen. Dank der Priorisierung innerhalb einer API-Sequenz kann API Gateway den Datenverkehr, der nicht den Erwartungen entspricht, protokollieren oder blockieren. Auf diese Weise wird die Menge des schädlichen Traffics reduziert.
Missbrauchserkennung anhand von Sequenzen
Wenn Angreifer versuchen, Daten auszuschleusen, folgen sie selten den Mustern des erwarteten API-Datenverkehrs. Sie verwenden oft spezielle Software zur Täuschung der API. In der Hoffnung, unerwartete Antworten von der API zu erhalten, die Hinweise auf Möglichkeiten zum Ausschleusen von Daten geben, werden mehrere Anfragen mit unterschiedlichen Parametern gesendet. Es können auch manuell Aufrufe geschickt werden, um die API nach Möglichkeit zu unbefugten Aktionen zu verleiten, z. B. einem Angreifer erhöhte Privilegien zu gewähren. Möglich ist auch ein Datenzugriff durch Angriffe, die fehlerhafte Autorisierung auf Objektebene ausnutzen. Beim Schutz von APIs hat sich Durchsatzbegrenzung bewährt. In den beiden oben genannten Beispielen können Angreifer jedoch absichtlich Anfragesequenzen langsam ausführen, um die Erkennung eines Missbrauchs mittels volumetrischer Angriffe zu vereiteln.
Rufen Sie sich die obige Anfragesequenz noch einmal vor Augen, aber stellen Sie sich diesmal vor, dass ein Angreifer die legitime Überweisungsanfrage kopiert und die Nutzdaten der Anfrage ändert, um das System auszutricksen:
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-1wig{font-weight:bold;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top} .tg .tg-5frq{font-style:italic;text-align:center;vertical-align:top} .tg .tg-8zwo{font-style:italic;text-align:left;vertical-align:top}
Reihenfolge
Methode
Pfad
Beschreibung
1
GET
/api/v1/users/{user_id}/accounts
„user_id“ ist der aktive Nutzer
2
GET
/api/v1/accounts/{account_id}/balance
„account_id“ ist eines der Konten des Nutzers, dessen Stand hier abgefragt wird
3
GET
/api/v1/accounts/{account_id}/balance
„account_id“ ist ein anderes Konto des Nutzers, dessen Stand hier abgefragt wird
4
POST
/api/v1/transferFunds
Enthält den Nachrichtenrumpf (Body) der Anfrage, in dem ein Absender- und ein Empfängerkonto für eine Überweisung sowie die zu überweisende Summe angegeben sind
… Angreifer kopiert die Anfrage in ein Debugging-Tool wie Postman …
5
POST
/api/v1/transferFunds
Angreifer hat den POST-Body modifiziert, um die API damit auszutricksen
6
POST
/api/v1/transferFunds
Ein darüber hinaus modifizierter POST-Body soll die API austricksen
7
POST
/api/v1/transferFunds
Ein weiterer, darüber hinaus modifizierter POST-Body soll die API austricksen
Wüsste der Kunde im Voraus, dass es auf den Schutz des Endpunkts der Überweisung ankommt und dieser innerhalb einer Sequenz nur einmal auftaucht, könnte er durch eine Regel sicherstellen, dass der Endpunkt nie zweimal hintereinander aufgerufen wird und „GET /balance“ immer „POST /transferFunds“ vorausgeht. Aber woher soll der Kunde wissen, welche Regeln zu definieren sind, wenn er nicht vorher weiß, welche Endpunktsequenzen unbedingt geschützt werden müssen? Die Begrenzung des Datendurchsatzes auf niedrigem Niveau ist zu riskant, weil ein legitimer API-Nutzer in der Lage sein muss, mehrere Überweisungsaufträge in kurzer Zeit auszuführen. Aktuell gibt es faktisch nur wenige Instrumente, mit denen diese Art von Missbrauch verhindert werden kann. Die meisten Kunden müssen sich damit begnügen, im Nachhinein auf Vorfälle zu reagieren und den Schaden mit ihren für Anwendungen und Betrugsfälle zuständigen Abteilungen zu beheben, nachdem er entstanden ist.
Unserer Ansicht nach ist letztendlich ein dreigleisiger Ansatz erforderlich, damit unsere Kunden positive Sicherheitsmodelle für API-Anforderungssequenzen definieren können:
Sequenzanalyse: Ermitteln, welche Sequenzen von API-Anfragen wann aufgetreten sind, und die Daten in leicht verständlicher Form zusammenfassen.
Erkennung von Sequenzmissbrauch: Erkennen, welche Sequenzen von API-Anfragen wahrscheinlich gut- oder bösartigen Ursprungs sind.
Sequenzüberprüfung: Identifizierung relevanter Regeln für Sequenzen von API-Aufrufen, um zu entscheiden, welcher Datenverkehr zugelassen und welcher blockiert werden soll.
Herausforderungen bei der Sequenzanalyse
Die Sequenzanalyse (Sequence Analytics) birgt einige technische Herausforderungen, da Sitzungen sehr langlebig sein und aus vielen Anfragen bestehen können. Folglich reicht es nicht aus, Sequenzen allein durch die Sitzungskennung zu definieren. Stattdessen mussten wir eine Lösung entwickeln, mit der mehrere Sequenzen innerhalb einer bestimmten Sitzung automatisch identifiziert werden können. Da wichtige Sequenzen nicht notwendigerweise nur durch ihr Volumen charakterisiert sind und eine Vielzahl an verschiedenen Sequenzen möglich ist, musste die Lösung zudem in der Lage sein, nicht einfach nur häufig auftauchende, sondern wichtige Sequenzen anzuzeigen.
Um diese Herausforderungen am Beispiel von api.cloudflare.com zu verdeutlichen, können wir API-Aufrufe nach Sitzungen gruppieren und die Zahl der unterschiedlichen Sequenzen mit der Sequenzlänge ins Verhältnis setzen:
Das Diagramm beruht auf einer einstündigen Momentaufnahme mit etwa 88.000 Sitzungen und 260 Millionen API-Aufrufen mit 301 verschiedenen API-Endpunkten. Wir verarbeiten die Daten, indem wir ein gleitendes Fenster fester Länge auf jede Sitzung anwenden und dann die Gesamtzahl der verschiedenen Sequenzen feststehender Länge (N-Gramms) zählen, die wir als Ergebnis der Anwendung des Schiebefensters beobachten. Die Grafik zeigt die Ergebnisse für eine Fenstergröße (N-Gramm-Länge), die zwischen einer und zehn Anfragen variiert. Die Zahl der unterschiedlichen Sequenzen reicht von 301 (für eine Fenstergröße von einer Anfrage) bis zu ungefähr 780.000 (für eine Fenstergröße von zehn Anfragen). Anhand des Diagramms lässt sich eine große Zahl möglicher Sequenzen ausmachen, die mit der Sequenzlänge wächst: Wird das gleitende Fenster vergrößert, sehen wir eine immer größere Zahl verschiedener Sequenzen in der Stichprobe. Der eindeutige Trend lässt sich durch die Tatsache erklären, dass wir ein gleitendes Fenster in Kombination mit vielen langen Sitzungen im Verhältnis zur Sequenzlänge verwenden (wobei die Sitzungen selbst viele Sequenzen enthalten können).
Angesichts der großen Zahl möglicher Sequenzen gleicht der Versuch, schädliche Sequenzen zu finden, der Suche nach der Nadel im Heuhaufen.
Einführung in Sequence Analytics
Der folgende Screenshot zeigt Sequence Analytics im API Gateway-Dashboard:
Schauen wir uns die neuen Funktionen auf dem Screenshot genauer an.
API Gateway ermittelt mithilfe der in diesem Beitrag beschriebenen Methoden auf smarte Weise die Abfolge der von Ihren API-Kunden gestellten Anfragen. Die Sequenzen werden anhand der Metrik „Correlation Score“ (Korrelationswert) bewertet. Sequence Analytics zeigt die 20 wichtigsten Sequenzen nach dem höchsten Korrelationswert an. Diese werden von uns als Ihre wichtigsten Sequenzen bezeichnet. Sequenzen mit großer Wichtigkeit enthalten API-Aufrufe, die wahrscheinlich zusammen in einer bestimmten Reihenfolge auftreten.
Sie sollten jede Ihrer Sequenzen prüfen, um ihre Korrelationswerte zu verstehen. Sequenzen mit hohen Korrelationswerten können sowohl aus selten genutzten Endpunkten (potenziell anormales Nutzerverhalten) als auch aus häufig genutzten Endpunkten (wahrscheinlich harmloses Nutzerverhalten) bestehen. Da die in diesen Sequenzen gefundenen Endpunkte häufig zusammen auftreten, stellen sie echte Nutzungsmuster Ihrer API dar. Sie sollten alle verfügbaren API Gateway-Schutzmaßnahmen auf diese Endpunkte anwenden (Vorschläge zur Durchsatzbegrenzung, Schema-Validierung, JWT-Validierung und mTLS) und ihre spezifische Endpunktreihenfolge mit Ihrem Entwicklungsteam überprüfen.
Uns ist bekannt, dass Kunden explizit ein zulässiges Verhalten für ihre APIs festlegen möchten, was über die aktuell bei API Gateway verfügbaren aktiven Schutzmaßnahmen hinausgeht. Wir werden in Kürze Regeln für die Reihenfolge der Anfragen veröffentlichen und die Möglichkeit bieten, Aufrufe auf Grundlage dieser Regeln zu blockieren. Die neuen Priorisierungsregeln für Sequenzen erlauben es den Kunden, die genaue Reihenfolge der zulässigen API-Anfragen festzulegen. Das stellt eine weitere Möglichkeit dar, ein positives Sicherheitsmodell zum Schutz Ihrer API vor unbekannten Bedrohungen zu schaffen.
Erste Schritte
Sequence Analytics steht jetzt allen API Gateway-Kunden zur Verfügung. Rufen Sie im Cloudflare-Dashboard eine Zone auf und klicken Sie dann auf die Registerkarte „Security“ (Sicherheit) > API Gateway > „Sequences“ (Sequenzen). Dort werden Ihnen die wichtigsten von Ihren API-Kunden angeforderten Sequenzen angezeigt.
Enterprise-Kunden, die API Gateway noch nicht erworben haben, können zunächst die Gateway-Testversion im Cloudflare-Dashboard aktivieren oder sich an ihre(n) Kundenbetreuer(in) wenden.
Was kommt als Nächstes?
Die sequenzbasierte Erkennung ist ein wirkungsvoller und einzigartiger Weg, der viele neue Möglichkeiten zur Identifizierung und zur Abwehr von Angriffen eröffnet. Im Zuge der Feinabstimmung der Methoden zur Identifizierung dieser Sequenzen und ihrer Übermittlung an unser internationales Netzwerk werden wir zu gegebener Zeit benutzerdefinierte Funktionen für den Sequenzabgleich und die Abwehr in Echtzeit veröffentlichen. Wir stellen außerdem sicher, dass Sie Ihrem Team verwertbare Informationen dazu bereitstellen können, welche API-Nutzer versucht haben, Sequenzen anzufordern, die nicht Ihrer Richtlinie entsprechen.