Exponierte APIs: Die versteckten Tueren Ihrer Website

Ihre Website hat eine Vordertuer, die Besucher sehen: die Seiten, die Formulare, die Navigation. Aber hinter dieser Vordertuer gibt es Dutzende anderer Tueren, die die meisten Menschen nie bemerken. Das sind Ihre APIs, Application Programming Interfaces, und sie sind die Art und Weise, wie die Komponenten Ihrer Website miteinander und mit externen Diensten kommunizieren.

Das Problem ist, dass viele dieser Tueren nicht verschlossen sind. Einige stehen weit offen. Und Angreifer wissen genau, wie sie diese finden.

Dieser Artikel erklaert, was APIs im Kontext einer Geschaeftswebsite sind, warum sie ein Sicherheitsproblem darstellen, wie Angreifer sie entdecken und ausnutzen, und was Sie tun koennen, um sich zu schuetzen.

Was sind APIs und warum hat jede moderne Website welche?

Eine API ist eine Moeglichkeit fuer Softwarekomponenten zu kommunizieren. Wenn Sie ein Kontaktformular auf einer Website ausfuellen, werden die Formulardaten an einen API-Endpunkt auf dem Server gesendet. Wenn eine Seite Produktlisten laedt, holt sie diese Daten moeglicherweise von einer API. Wenn Ihre Website sich mit einem Zahlungsabwickler, E-Mail-Dienst oder CRM integriert, geschehen diese Integrationen ueber APIs.

Selbst eine einfache Geschaeftswebsite hat typischerweise APIs fuer:

• Kontaktformular-Einreichungen - Daten, die vom Browser zum Server gesendet werden.
• Suchfunktionalitaet - Anfragen an einen Suchendpunkt, der Ergebnisse zurueckgibt.
• Benutzerauthentifizierung - Login, Logout, Passwort-Zuruecksetzung.
• Content-Management - Das CMS verwendet APIs zum Erstellen, Lesen, Aktualisieren und Loeschen von Inhalten.
• Drittanbieter-Integrationen - Analytics, Zahlungsabwickler, E-Mail-Marketing, Chat-Widgets.

WordPress REST API: Benutzerdaten standardmaessig exponiert

WordPress wird seit Version 4.7 standardmaessig mit einer vollstaendigen REST API ausgeliefert. Diese API wurde entwickelt, um WordPress zu einer besseren Plattform fuer den Aufbau von Anwendungen zu machen, aber sie legt auch Daten offen, von denen die meisten Website-Betreiber nicht wissen, dass sie oeffentlich sind.

Was die WordPress REST API offenlegt

Versuchen Sie dies auf jeder WordPress-Website: Navigieren Sie zu /wp-json/wp/v2/users. Auf vielen Websites sehen Sie eine JSON-Antwort, die alle Benutzerkonten auflistet, einschliesslich Benutzernamen, Anzeigenamen, Benutzer-IDs und Profil-URLs. Diese Informationen sind fuer jeden ohne Authentifizierung verfuegbar.

Warum das wichtig ist

Die Aufzaehlung von Benutzernamen ist der Ausgangspunkt fuer Brute-Force-Angriffe. Wenn ein Angreifer die Benutzernamen auf Ihrer WordPress-Website kennt (und die REST API hat sie gerade uebergeben), kann er anfangen, Passwoerter zu raten. Kombiniert mit dem /wp-login.php-Endpunkt und fehlendem Rate Limiting ist dies ein direkter Angriffsweg.

Wir haben verwandte Risiken in unserem Artikel ueber exponierte Admin-Seiten besprochen.

GraphQL-Introspection aktiviert gelassen

GraphQL ist eine Alternative zu REST APIs, die immer haeufiger wird. Es erlaubt Clients, genau die Daten anzufordern, die sie benoetigen, in einer einzigen Abfrage.

Das Introspection-Problem

GraphQL hat eine eingebaute Funktion namens Introspection, die es jedem erlaubt, das vollstaendige Schema der API abzufragen. Das bedeutet, ein Angreifer kann jeden Typ, jedes Feld, jede Beziehung und jede Mutation entdecken, einfach durch das Senden einer einzigen Abfrage:

{ __schema { types { name fields { name type { name } } } } }

Das ist wie einem Angreifer einen vollstaendigen Bauplan Ihrer Datenbankstruktur und jeder Operation zu uebergeben, die Ihre API unterstuetzt.

Die Loesung

Deaktivieren Sie Introspection in der Produktion. Jede wichtige GraphQL-Bibliothek bietet eine Konfigurationsoption dafuer. In Apollo Server: introspection: false. Dies sollte Teil Ihrer Deployment-Checkliste sein.

Nicht authentifizierte API-Endpunkte

Ueber WordPress und GraphQL hinaus haben viele massgeschneiderte Websites und Anwendungen API-Endpunkte ohne ordnungsgemaesse Authentifizierung. Dies geschieht aus mehreren haeufigen Gruenden:

• Entwicklungs-Abkuerzungen: Authentifizierung "sollte spaeter hinzugefuegt werden" und wurde es nie.
• Angenommene Obskuritaet: Der Entwickler nahm an, niemand wuerde den Endpunkt finden, weil er von keiner Seite verlinkt ist. Das ist Security through Obscurity, und es funktioniert nicht.
• Falsch konfigurierte Middleware: Die Authentifizierungs-Middleware wurde auf die meisten Routen angewendet, hat aber einige verpasst.
• Legacy-Endpunkte: Alte API-Endpunkte aus einer frueheren Version der Anwendung, die nie ordnungsgemaess ausser Betrieb genommen wurden.

IDOR-Schwachstellen: Wenn Authentifizierung nicht ausreicht

IDOR steht fuer Insecure Direct Object Reference. Es tritt auf, wenn eine API einen vorhersagbaren Bezeichner (wie eine fortlaufende Nummer) verwendet, um auf Objekte zu verweisen, und nicht ueberprueft, ob der anfragende Benutzer die Berechtigung hat, auf dieses spezifische Objekt zuzugreifen.

Wie IDOR funktioniert

Stellen Sie sich einen API-Endpunkt wie /api/rechnungen/1234 vor, der Rechnungsdetails zurueckgibt. Sie sind angemeldet und fordern Ihre eigene Rechnung an. Aendern Sie nun die Nummer auf 1235. Wenn die API die Rechnung einer anderen Person zurueckgibt, ist das eine IDOR-Schwachstelle.

Die API hat ueberprueft, dass Sie authentifiziert sind (Sie sind angemeldet), aber sie hat nicht die Autorisierung ueberprueft (ob Sie die Berechtigung haben, auf Rechnung 1235 zuzugreifen). Dies ist einer der haeufigsten Schwachstellentypen in Webanwendungen und erscheint regelmaessig in den OWASP Top 10.

Rate Limiting: Der fehlende Schutz

Rate Limiting beschraenkt, wie viele Anfragen ein Client innerhalb eines bestimmten Zeitraums an eine API stellen kann. Ohne dies koennen Angreifer:

• Login-Endpunkte per Brute-Force angreifen: Tausende Passwortkombinationen pro Minute ausprobieren.
• Daten aufzaehlen: Ihre gesamte Datenbank durch Tausende sequenzieller API-Anfragen herunterladen.
• Denial of Service: Ihren Server mit Anfragen ueberwaeltigen und ihn fuer legitime Benutzer unverfuegbar machen.

Endpunkt-Typ	Empfohlenes Limit	Begruendung
Login / Authentifizierung	5-10 Versuche pro Minute pro IP	Verhindert Brute-Force-Angriffe
Passwort-Zuruecksetzung	3 Anfragen pro Stunde pro E-Mail	Verhindert E-Mail-Bombing
Kontaktformular	5 Einreichungen pro Stunde pro IP	Verhindert Spam
Suche	30 Anfragen pro Minute pro IP	Verhindert Daten-Scraping
Allgemeine API	100 Anfragen pro Minute pro Benutzer	Verhindert Missbrauch bei normalem Gebrauch

API-Schluessel im Frontend-JavaScript

Dies ist einer der haeufigsten Fehler, die wir bei Website-Audits finden. Entwickler betten API-Schluessel, geheime Tokens und Zugangsdaten direkt in clientseitigen JavaScript-Code ein. Da jedes JavaScript, das an den Browser geliefert wird, fuer jeden sichtbar ist, der die Entwicklerwerkzeuge oeffnet, sind diese Geheimnisse effektiv oeffentlich.

Was wir im JavaScript-Quellcode finden

• Google Maps API-Schluessel (oft mit aktivierter Abrechnung und ohne Einschraenkungen).
• Firebase-Konfiguration einschliesslich Datenbank-URLs und API-Schluessel.
• API-Schluessel von Zahlungsabwicklern (manchmal einschliesslich geheimer Schluessel).
• CMS-API-Tokens mit Schreibberechtigungen.
• API-Schluessel von E-Mail-Diensten (SendGrid, Mailgun, etc.).

Wie man es behebt

1. Setzen Sie niemals geheime Schluessel in Frontend-Code. Nur oeffentliche Schluessel sollten im clientseitigen JavaScript sein.
2. Verwenden Sie Umgebungsvariablen auf dem Server. Bewahren Sie Geheimnisse in serverseitigen Umgebungsvariablen auf.
3. Beschraenken Sie API-Schluessel nach Domain. Google Cloud, AWS und die meisten Dienste erlauben es, API-Schluessel auf bestimmte Domains oder IP-Adressen zu beschraenken.
4. Leiten Sie sensible API-Aufrufe ueber Ihr Backend. Anstatt eine Drittanbieter-API direkt vom Browser aufzurufen, leiten Sie die Anfrage ueber Ihren Server, wo der geheime Schluessel sicher gespeichert ist.
5. Rotieren Sie exponierte Schluessel sofort. Wenn Sie entdecken, dass ein Schluessel exponiert wurde, generieren Sie einen neuen und widerrufen Sie den alten.

Wie Angreifer APIs aufzaehlen und ausnutzen

Entdeckungsphase

• Browser-Entwicklerwerkzeuge: Oeffnen Sie den Network-Tab und browsen Sie die Website. Jeder API-Aufruf ist sichtbar, einschliesslich der vollstaendigen URL, der Request-Header, des Request-Bodys und der Response.
• JavaScript-Quellcode-Analyse: Lesen Sie die JavaScript-Dateien der Website. API-Endpunkte, Schluessel und manchmal Authentifizierungstoken sind im Code eingebettet.
• Scanning gaengiger Pfade: Tools wie DirBuster oder ffuf testen gaengige API-Pfade: /api/, /v1/, /graphql, /wp-json/.
• JavaScript Source Maps: Wenn Source Maps in der Produktion bereitgestellt werden, offenbaren sie die urspruengliche Quellcode-Struktur.

Von Angreifern verwendete Tools

• Postman: Urspruenglich ein legitimes API-Entwicklungstool, haeufig verwendet, um API-Anfragen mit geaenderten Parametern zu erstellen und wiederzugeben.
• Burp Suite: Ein professionelles Web-Sicherheitstest-Tool. Die Proxy-Funktion faengt jede Anfrage zwischen Browser und Server ab und ermoeglicht es, API-Aufrufe in Echtzeit zu manipulieren.
• cURL: Der Kommandozeilen-HTTP-Client. Einfach, leistungsstark und auf jedem System verfuegbar.
• OWASP ZAP: Eine Open-Source-Alternative zu Burp Suite mit aehnlichen Faehigkeiten.

Wie Sie Ihre APIs sichern

Authentifizierung

Jeder API-Endpunkt, der nicht explizit oeffentlich ist, sollte eine Authentifizierung erfordern. Verwenden Sie Standardmechanismen: JWT, OAuth 2.0, API-Schluessel fuer Service-zu-Service-Kommunikation, Session-Cookies fuer Browser-Anwendungen.

Autorisierung

Authentifizierung bestaetigt die Identitaet. Autorisierung bestaetigt die Berechtigung. Beides ist erforderlich. Implementieren Sie rollenbasierte oder attributbasierte Zugriffskontrolle. Pruefen Sie die Autorisierung bei jeder Anfrage, fuer jede Ressource.

Eingabevalidierung

Validieren Sie jede Eingabe auf der Serverseite. Vertrauen Sie niemals Daten, die vom Client kommen. Pruefen Sie Datentypen, Laengenbegrenzungen, Formatvalidierung, erlaubte Werte und Encoding.

Fehlerbehandlung

API-Fehlerantworten sollten informativ genug fuer legitime Benutzer sein, aber keine internen Details an Angreifer preisgeben. Verwenden Sie generische Fehlermeldungen fuer Authentifizierungsfehler. Keine Stack-Traces, Dateipfade oder SQL-Abfragen in Fehlerantworten.

Praktische Audit-Checkliste

1. Oeffnen Sie Ihre Website in einem Browser mit geoeffneten Entwicklerwerkzeugen. Gehen Sie zum Network-Tab. Durchsuchen Sie jede Seite und klicken Sie auf jeden Button. Wie viele API-Aufrufe sehen Sie?
2. Versuchen Sie bei jedem Endpunkt, ohne Authentifizierung darauf zuzugreifen. Welche Daten gibt er zurueck?
3. Pruefen Sie die WordPress REST API: Besuchen Sie /wp-json/wp/v2/users. Koennen Sie Benutzernamen sehen?
4. Pruefen Sie GraphQL: Versuchen Sie /graphql mit einer Introspection-Abfrage. Antwortet es?
5. Schauen Sie sich die JavaScript-Quelldateien an. Sind API-Schluessel, Tokens oder Zugangsdaten eingebettet?
6. Versuchen Sie, numerische IDs in API-Anfragen zu aendern. Koennen Sie auf Daten anderer Benutzer zugreifen?
7. Senden Sie 100 Anfragen an einen sensiblen Endpunkt in schneller Folge. Werden Sie rate-limitiert?

Naechste Schritte

API-Sicherheit ist ein spezialisiertes Gebiet, das sowohl technisches Wissen als auch ein Verstaendnis Ihrer spezifischen Anwendung erfordert. Bei Envestis fuehren wir gruendliche API-Sicherheitsbewertungen fuer Unternehmen in Lugano und in der ganzen Schweiz durch, identifizieren exponierte Endpunkte, testen Autorisierungskontrollen und geben konkrete Empfehlungen zur Behebung.

Wenn Sie sich ueber die Sicherheit der APIs Ihrer Website unsicher sind, kontaktieren Sie uns fuer eine Sicherheitsbewertung. Wir kartieren Ihre API-Oberflaeche, testen die in diesem Artikel beschriebenen Schwachstellen und geben Ihnen einen klaren Bericht darueber, was behoben werden muss und wie.