Direkt zum Inhalt

API-Sicherheit prüfen

REST und GraphQL mit gültigen Zugängen für mehrere Rollen, entlang der OWASP API Security Top 10. Der häufigste Befund liegt zwischen Anmeldung und Berechtigung.

Test von Schnittstellen Dieselbe Anfrage mit einer fremden Kundennummer wird ebenfalls beantwortet. Authentisiert ist der Aufruf, autorisiert nicht. GET /customers/4711/ invoicesAuthorization: Bearer … OWN CUSTOMER NUMBER GET /customers/4712/ invoicesAuthorization: Bearer … ONE DIGIT CHANGED 200 OK 200 OK DATA OF ANOTHER USER APIS · REST AND GRAPHQL
Vertraut von
Worum es geht

Schnittstellen tragen die Daten, nicht die Oberfläche

Ein API-Penetrationstest prüft die Schnittstellen einer Anwendung so, wie ein Angreifer sie aufrufen würde: mit gültigen Zugängen, mit fremden Kennungen, mit Feldern, die niemand vorgesehen hat. Geprüft wird nicht die Oberfläche, sondern was die Schnittstelle dahinter tatsächlich herausgibt. Andere Namen für dasselbe: API-Pentest, API Security Testing, Schnittstellentest.

Hinter jeder App und jedem Portal liegt eine API und dort liegen auch die Daten. Die Oberfläche zeigt einem Benutzer, was er sehen darf. Die Schnittstelle entscheidet, was er tatsächlich abrufen kann.

Wir prüfen REST- und GraphQL-Schnittstellen mit gültigen Zugängen für mehrere Rollen, entlang der OWASP API Security Top 10. Wo eine OpenAPI-Beschreibung vorliegt, arbeiten wir damit; wo nicht, nehmen wir die Aufrufe aus der App auf.

Der häufigste Befund

Authentisiert ja, autorisiert nein

Test von Schnittstellen Dieselbe Anfrage mit einer fremden Kundennummer wird ebenfalls beantwortet. Authentisiert ist der Aufruf, autorisiert nicht. GET /customers/4711/ invoicesAuthorization: Bearer … OWN CUSTOMER NUMBER GET /customers/4712/ invoicesAuthorization: Bearer … ONE DIGIT CHANGED 200 OK 200 OK DATA OF ANOTHER USER APIS · REST AND GRAPHQL

Der Aufruf trägt ein gültiges Token, die Anwendung erkennt den Benutzer und dann liefert sie die Rechnung eines anderen Kunden aus. Zwischen Anmeldung und Berechtigung liegt eine Prüfung, die im Backend fehlt, weil die Oberfläche die fremde Kundennummer gar nicht erst anbietet.

In der OWASP-Liste steht das an erster Stelle, als Broken Object Level Authorization. Es findet sich mit einer geänderten Ziffer und ist der Grund, warum wir mit mehreren Konten gleichzeitig testen: Ein einzelnes Konto kann diese Lücke nicht zeigen.

Was geprüft wird

Was ein API-Test abdeckt

Die OWASP API Security Top 10 nennt zehn Kategorien. Hier stehen sie in fünf Gruppen, damit die Liste lesbar bleibt; im Bericht ist jeder Befund seiner Kategorie zugeordnet. Was in Ihrem Fall schwerer wiegt, hängt von der Schnittstelle ab.

Objekt- und Funktionsrechte

Fremde Kennungen, fremde Mandanten, administrative Endpunkte mit einem gewöhnlichen Token. Dazu Felder, die der Client mitschicken darf, obwohl das Backend sie nur lesen sollte: ein Rollenwechsel per JSON-Feld kommt häufiger vor als erwartet. Der Klassiker und der mit den größten Folgen.

Anmeldung und Token

Wie ein Token ausgestellt, geprüft und zurückgezogen wird. Signaturverfahren, Laufzeit, Erneuerung und ob ein abgemeldeter Zugang wirklich ungültig ist. Ein Token, das nach der Abmeldung weiter funktioniert, hebelt jede Berechtigung darüber aus.

Verbrauch und Geschäftsabläufe

Ohne Ratenbegrenzung wird aus einem funktionierenden Login die Möglichkeit, Konten durchzuprobieren oder Daten seitenweise abzuziehen. Dazu Abläufe, die einzeln erlaubt sind und in Menge schaden: Bestellungen, Einladungen, Gutscheine.

Konfiguration und Serveranfragen

Fehlermeldungen mit zu viel Inhalt, offene Verwaltungsschnittstellen, fehlende Sicherheits-Header und Aufrufe, mit denen sich der Server dazu bringen lässt, selbst Anfragen ins interne Netz zu stellen.

Bestand und fremde Schnittstellen

Welche Versionen einer Schnittstelle noch erreichbar sind und welche davon niemand mehr pflegt. Eine vergessene v1 neben der gepflegten v3 ist einer der häufigsten Funde. Dazu die Schnittstellen, die Ihre Anwendung selbst aufruft und wie sie deren Antworten behandelt.

Ablauf

Wie ein API-Test abläuft

Der Aufwand richtet sich nach der Zahl der Endpunkte und der Rollen. Geprüft wird entlang der OWASP API Security Top 10 und des BSI-Praxis-Leitfadens für IS-Penetrationstests; jeder Bericht durchläuft eine Zwei-Augen-Qualitätssicherung.

1

Umfang und Zugänge festlegen

Welche Schnittstellen, welche Umgebung, welches Zeitfenster. Wir brauchen je Rolle einen Zugang, weil sich die wichtigsten Befunde erst im Vergleich zwischen zwei Konten zeigen.

2

Endpunkte aufnehmen

Aus einer OpenAPI-Beschreibung, wenn es eine gibt, sonst aus dem mitgeschnittenen Verkehr der App oder des Frontends. Dazu die Suche nach Versionen, die noch antworten, aber in keiner Dokumentation stehen.

3

Prüfen

Jeder Endpunkt gegen die Kategorien der OWASP-Liste, manuell bestätigt. Automatisierte Läufe liefern die Fläche, die Befunde entstehen danach von Hand.

4

Verketten

Was sich verbinden lässt: von der fremden Kennung zum fremden Mandanten, vom mitgeschickten Feld zur höheren Rolle. Die Bewertung richtet sich nach dem, was am Ende erreichbar war.

5

Bericht und Nachtest

Befunde mit Reproduktionsschritten als Aufruf, den Ihr Team nachstellen kann, dazu die Risikobewertung. Auf Wunsch die Gegenprobe nach der Behebung.

Was Sie erhalten

Ein Bericht, mit dem Ihr Team weiterarbeiten kann.

Jeder Befund kommt eingeordnet: mit Risiko, Aufwand und dem Weg zur Behebung.

Management Summary

Die Lage auf einer Seite, verständlich für Geschäftsführung und Aufsicht.

Technische Findings

Jeder Befund mit eindeutiger Befund-ID, Nachweis und Reproduktionsschritten.

Risikobewertung nach BSI

Eine nachvollziehbare Einstufung jedes Funds nach anerkanntem Schema.

Priorisierte Empfehlungen

Konkrete Handlungsempfehlungen in der Reihenfolge, in der sie wirken.

Abschlussgespräch

Auf Wunsch eine gemeinsame Durchsprache der Ergebnisse mit Ihren Fachteams.

Retest

Auf Wunsch die erneute Prüfung der behobenen Schwachstellen, mit Bestätigung des Stands.

Rahmen

Was wir brauchen und was nicht dazugehört

Von Ihnen brauchen wir die Adressen der Schnittstelle, je Rolle einen gültigen Zugang, einen Ansprechpartner für die Dauer des Tests und eine schriftliche Freigabe. Eine OpenAPI-Beschreibung verkürzt die Aufnahme, ist aber keine Bedingung. Gibt es eine Testumgebung, prüfen wir dort; sonst im Produktivsystem mit abgestimmten Einschränkungen und was wir verändern, protokollieren wir und machen es rückgängig.

Nicht enthalten sind Angriffe auf Menschen und auf die Verfügbarkeit. Phishing-Simulationen und Social Engineering sind eigene Leistungen, Last- und Denial-of-Service-Tests führen wir nicht durch. Gehört die Oberfläche dazu, prüfen wir sie im selben Auftrag als Webanwendung; liegt die Schnittstelle in einer Cloud-Umgebung, gehören deren Berechtigungen in den Cloud-Test. Eine Quelltextprüfung ist kein Pentest, sondern eine eigene Leistung, die sich gut damit verbindet.

Häufige Fragen

Häufige Fragen zu API-Tests

Ja und am besten für mehrere Rollen. Ein API-Test ohne gültige Token prüft nur, was ohne Anmeldung erreichbar ist. Die Befunde mit Substanz liegen darin, was ein angemeldeter Benutzer erreicht, den es nichts angeht.

Das ist der Normalfall. Wir nehmen den Verkehr der App oder des Frontends auf und leiten die Endpunkte daraus ab. Eine vorhandene OpenAPI-Datei verkürzt die Aufnahme, ist aber keine Bedingung.

Bei einer modernen Anwendung ist die API der größere Teil. Wir prüfen beides im selben Test, wenn Frontend und Backend zusammengehören.

Nachweise

Zertifizierungen und Mitgliedschaften.

Zertifizierungen im Team
Mitgliedschaften
eco – Verband der Internetwirtschaft
networker NRW
Nächster Schritt

Sprechen Sie mit uns.

Ein erstes Gespräch dauert in der Regel 30 Minuten. Wir schauen uns Ihre Ausgangslage an und sagen offen, ob wir der passende Partner sind.

Telefon
0231 39814905
Mo–Fr · 9–17 Uhr
E-Mail
info@yekta-it.de
PGP verfügbar
Standort
Dortmund
Ruhrallee 9 · 44139