Ich werde oft nach Schatten-APIs und Schatten-API-Parametern gefragt - sogar von Leuten mit viel Erfahrung im Bereich der API-Entwicklung. Das ist nicht sonderlich überraschend, denn Schatten-APIs sind in der Regel kein Risiko, an das man bei der normalen Entwicklung einer API denken würde. Einige Leute sind sogar davon überzeugt, dass Schatten-APIs in Wirklichkeit nur eine Panikmache von Sicherheitsanbietern sind, um ihre Tools zu verkaufen.
In Wirklichkeit sind Schatten-APIs jedoch relativ einfach zu erstellen und zu verwenden. Wie können wir sie am besten besser verstehen? Indem wir uns Beispiele aus der Praxis ansehen! Das ist es, was wir in diesem Beitrag behandeln werden.
Was sind Schatten-APIs?
Beginnen wir mit dieser Beispiel-API-Anfrage, auf die ich gestoßen bin:
Dies ist eine Anfrage an eine GraphQL-API zur Generierung des Einmalpassworts (OTP), das bei der Authentifizierung für einen Webdienst verwendet wird. Wenn Sie nicht genau hinschauen, erkennen Sie das Problem vielleicht nicht, deshalb habe ich es mit einem großen roten Pfeil markiert. Das otpDigit Parameter ist tatsächlich ein großes Problem.
Ich habe entdeckt, dass dieser Parameter tatsächlich über die API geändert werden kann. Wenn Sie ihn ändern, können Sie die Länge des für die Authentifizierung erforderlichen Einmalpassworts anpassen. Was sind die Auswirkungen? Ich konnte den Wert ändern auf 1. Damit sank die Zahl der Möglichkeiten für das Passwort von einer Million auf nur 10!
Verständlicherweise war das Entwicklungsteam alarmiert, als ich ihnen von diesem Parameter erzählte, und sie haben ihn sofort behoben. Nichtsdestotrotz ist dies ein perfektes Beispiel für Schatten-APIs und ihre Parameter. Höchstwahrscheinlich war dieser Parameter eine anfängliche Annehmlichkeit für die Entwickler, die für die Prototypenerstellung oder Tests verwendet wurde. Als die API in die Produktion überging, wurde die Unterstützung für den Parameter nie entfernt, und er wurde zu einem Schatten-API-Parameter.
Ohne jemanden, der diesen speziellen Endpunkt daraufhin untersucht, was mit einem undokumentierten Parameter getan werden kann, wäre diese schwerwiegende Sicherheitslücke nicht entdeckt worden. Noch wichtiger ist, dass ein Entwicklungsteam nicht gezielt danach suchen wird, bis es mit der Schwachstelle konfrontiert wird.
Dieses Beispiel bildet die Grundlage für eine Arbeitsrichtlinie zu Schatten-API-Endpunkten und -Parametern: Alle Ihre API-Endpunkte oder -Parameter, die nicht direkt im Fokus der Entwickler stehen, existieren im Schatten, und sie stellen ein Risiko dar, weil das Sicherheitsteam sie wahrscheinlich ebenfalls übersehen wird.
Was kann ich gegen Schatten-APIs tun?
Da Sie nun wissen, was Schatten-API-Endpunkte und -Parameter sind, stellt sich die Frage, was Sie dagegen tun können. Natürlich können Sie Ihrem Sicherheitsteam nicht einfach sagen, dass es wachsamer sein soll, vor allem in Bezug auf die Dinge, auf die die Entwickler bei ihrer aktiven Arbeit nicht einmal hinweisen.
Höchstwahrscheinlich benötigen Sie ein Tool oder einen Prozess, der Sie bei der Bewertung der Sicherheit Ihrer APIs unterstützt. Welche Art von Tool Sie benötigen, hängt von der Größe Ihres Unternehmens und der Anzahl der von Ihnen eingesetzten APIs ab. API-Gateways oder sogar API-Sicherheits-Tools können Sie auf dem Weg zu dem von Ihnen benötigten Maß an Sicherheit ein gutes Stück voranbringen, aber sie können auch mehr sein, als Sie brauchen. Wenn Sie nur einige Endpunkte für API-Kunden zur Verfügung haben, ist die Bereitstellung eines robusten Satzes von Tools, die den Datenverkehr in Ihrem Stack verfolgen und Sie bei verdächtigen Aktivitäten warnen, definitiv zu viel verlangt.
Ein einfacherer Ansatz ist es, dafür zu sorgen, dass Ihre APIs gut dokumentiert sind. Dies ist auch ein guter Ausgangspunkt. Beginnen Sie mit der Übernahme des OpenAPI-Standards für die Dokumentation Ihrer APIs. Denken Sie daran, dass Schatten-APIs entstehen, wenn Sie Ihren Endpunkten und Parametern keine Aufmerksamkeit schenken. Der ganze Sinn des OpenAPI-Standards besteht darin, ein Modell bereitzustellen, mit dem Sie jeden Endpunkt und jeden Parameter Ihrer API spezifizieren und somit kennen können.
Von dort aus können Sie auch von Ihren Entwicklern verlangen, dass sie diese API-Dokumentation dem Sicherheitsteam bei der Bereitstellung zur Verfügung stellen. Das Sicherheitsteam testet dann die API anhand der Dokumentation, um etwaige Ungenauigkeiten oder Lücken zu finden. So werden blinde Flecken vermieden.
Fazit
Wenn Sie Licht in diese Bereiche bringen, werden die Dinge nicht mehr im Schatten lauern. Wenn Sie die Details der von Ihnen bereitgestellten APIs kennen, kann es keine Schatten-APIs geben. Auch wenn es vielleicht nicht die aufregendste Aufgabe der Welt ist, trägt die Dokumentation Ihrer APIs dazu bei, dass Sie Ihre APIs nicht für böswillige Angreifer öffnen.
Ich hoffe, dieser Beitrag hat Sie über die Definition und die Gefahren von Schatten-APIs aufgeklärt. Go bringt Licht in die dunklen Ecken Ihrer API-Infrastruktur, um Sicherheitsverletzungen zu verhindern!
Kommentare