Heim  >  Artikel  >  Betrieb und Instandhaltung  >  Was sind die fünf häufigsten Schwachstellen von APIs?

Was sind die fünf häufigsten Schwachstellen von APIs?

PHPz
PHPznach vorne
2023-05-12 20:40:041206Durchsuche

Was sind die fünf häufigsten Schwachstellen von APIs?

API macht es einfach, Geschäfte zu machen, und das denken auch Hacker. Heute, wo die digitale Transformation von Unternehmen in vollem Gange ist, gehen APIs weit über den Rahmen der technologischen Innovation im Internet hinaus und die digitale Transformation traditioneller Unternehmen ist untrennbar mit der API-Wirtschaft oder der API-Strategie verbunden. APIs verbinden nicht nur Systeme und Daten, sondern auch Unternehmensabteilungen, Kunden und Partner und sogar das gesamte Geschäftsökosystem. Gleichzeitig werden APIs angesichts immer schwerwiegenderer Sicherheitsbedrohungen zur nächsten Grenze der Netzwerksicherheit. Wir haben die fünf größten API-Sicherheitsschwächen und Patch-Vorschläge zusammengestellt, die Sicherheitsexperten Unternehmen vorschlagen.

APIs machen alles einfacher, von der Datenfreigabe über die Systemkonnektivität bis hin zur Bereitstellung kritischer Funktionen, aber APIs machen es auch Angreifern, einschließlich böswilliger Bots, einfacher. Die Verbreitung von API-Anwendungen regt Cyberkriminelle dazu an, zunehmend API-Sicherheitslücken auszunutzen, um Betrug zu begehen und Daten zu stehlen.

Im Folgenden besprechen wir fünf API-Schwachstellen, die von Hackern leicht ausgenutzt werden können, und teilen Vorschläge von Sicherheitsexperten zur Schadensbegrenzung und -verstärkung.

1. Zu leicht entdeckt zu werden

Wenn Sie ein Hacker sind und ein Unternehmen angreifen wollen, müssen Sie zunächst so viele APIs wie möglich identifizieren. Ich verwende die Zielanwendung zunächst auf normale Weise, indem ich die Webanwendung in einem Browser öffne oder die mobile Anwendung herunterlade und auf dem Telefon installiere, und verwende dann einen Abhör-Proxy, um die Kommunikation zu überwachen.

Der Interception-Proxy ist in der Lage, alle vom Browser oder der mobilen Anwendung an den Backend-Webserver gestellten Anfragen zu erfassen, sodass der Angreifer alle verfügbaren API-Endpunkte katalogisieren kann. Beispielsweise verfügen die meisten APIs über API/V1/login als Authentifizierungsendpunkt.

Wenn das Ziel ebenfalls eine mobile App ist, entpacken Sie die App und sehen Sie sich die in der App verfügbaren API-Aufrufe an. Unter Berücksichtigung aller möglichen Aktivitäten können Angreifer nach häufigen Konfigurationsfehlern oder APIs suchen, die Benutzerdaten nicht ordnungsgemäß schützen.

Schließlich suchen Angreifer nach API-Dokumentation. Einige Organisationen veröffentlichen API-Dokumentation für Dritte, verwenden jedoch für alle Benutzer dieselben API-Endpunkte.

Mit einer guten Endpunktliste können Angreifer sowohl das Standardbenutzerverhalten als auch das abnormale Verhalten testen und so auf beide Arten interessante Schwachstellen finden.

Problemumgehung: Um die API für Angreifer schwieriger zu entdecken, stellen Sie sicher, dass Sie den Zugriff auf die API-Dokumentation durch eine Berechtigungsverwaltung steuern, die nur gültigen Benutzern Zugriff gewährt. Das Anheften des Zertifikats an die mobile App verbirgt den API-Endpunkt zwar nicht vollständig und ist auch nicht perfekt, fügt dem Angriff jedoch einen zusätzlichen Schritt hinzu. API-Anfragen an den Webserver sollten so weit wie möglich verschleiert und kontrolliert werden.

2. Zu detaillierte Fehlermeldungen

In letzter Zeit häufen sich die Versuche von Angreifern, Konten zu übernehmen. Zu „detaillierte“ Fehlermeldungen erleichtern solche Angriffe tendenziell. Die lange Fehlermeldung weist den Angreifer darauf hin, welche Änderungen er vornehmen muss, um als legitime Anfrage zu erscheinen. Die API ist für Hochgeschwindigkeitstransaktionen bei geringer Auslastung konzipiert und ermöglicht es Angreifern, Hochleistungssysteme zu nutzen, um gültige Konten zu identifizieren und dann zu versuchen, sich anzumelden und Passwörter zu ändern, um sie auszunutzen.

Lösung: Benutzen Sie die Benutzererfahrung nicht als Schutzschild. Einige Praktiken, die für die Benutzererfahrung gut zu sein scheinen, sind möglicherweise nicht gut für die Sicherheit. Die vom System zurückgegebene Fehlermeldung sollte keinen falschen Benutzernamen oder ein falsches Passwort enthalten und auch nicht die Kategorie der Fehlermeldung (falscher Benutzername oder falsches Passwort). Das Gleiche gilt für Fehlermeldungen, die zum Abfragen von Daten verwendet werden. Wenn die Abfrage/Suche fehlerhaft ist oder aus irgendeinem Grund nicht ausgeführt werden kann, sollte die „unnützste“ Fehlermeldung zurückgegeben werden: „Ups, etwas ist schiefgelaufen“.

3. Zu viele Parameter

Wenn ein Angreifer das Angriffssystem über API-Aufrufe durchquert, muss er herausfinden, was er senden kann, um an die Daten zu gelangen. Angreifer „glauben“ daran, dass je komplexer das System ist, desto mehr Dinge können schief gehen. Sobald der Angreifer die API identifiziert, katalogisiert er die Parameter und versucht dann, auf die Daten des Administrators (vertikale Privilegieneskalation) oder eines anderen Benutzers (horizontale Privilegieneskalation) zuzugreifen, um zusätzliche Daten zu sammeln. Oft werden dem Benutzer zu viele unnötige Parameter angezeigt.

In einem aktuellen Forschungsprojekt haben unsere API-Aufrufe an den Zieldienst eine große Datenmenge zurückgegeben, von denen viele unnötige Dateninformationen waren, wie z. B. der Prozessorschlüssel des Zahlungsgateways und verfügbare Rabattinformationen. Diese „Belohnungsinformationen“ ermöglichen es Angreifern, den Kontext und die Syntax dieser API-Aufrufe besser zu verstehen. Der Angreifer braucht nicht viel Vorstellungskraft, um herauszufinden, was als nächstes zu tun ist. Diese zusätzlichen Parameter stellen Angreifern einen umfangreichen Angriffsdatensatz zur Verfügung.

Problemumgehung: Wenn Sie den Inhaltsumfang, den Benutzer sehen, auf erforderliche Inhalte beschränken, die Übertragung kritischer Daten einschränken und die Datenabfragestruktur unbekannt machen, wird es für Angreifer schwierig, die ihnen bekannten Parameter brutal zu erzwingen.

4. Zu viele Daten

Auch hier ist das Sammeln von Daten bei so vielen verfügbaren Parametern der naheliegende nächste Schritt. Viele Unternehmenssysteme unterstützen anonyme Verbindungen und neigen dazu, zusätzliche Daten preiszugeben, die der durchschnittliche Benutzer nicht benötigt. Darüber hinaus bevorzugen viele Unternehmen die Speicherung von Daten, auf die direkt zugegriffen werden kann.

Sicherheitsexperten kämpfen mit der Herausforderung, dass API-Anfragen häufig offenlegen, wo Daten gespeichert sind. Wenn ich mir beispielsweise Videos von einer Überwachungskamera ansehe, kann ich erkennen, dass die Informationen aus einem Amazon S3-Repository stammen. Oftmals sind diese S3-Repositorys nicht gut geschützt und die Daten jedermanns können abgerufen werden.

Eine weitere häufige Datenherausforderung ist die Datenüberflutung. Viele Unternehmen sind wie Streifenhörnchen vor dem Winter und speichern weit mehr Daten, als sie benötigen. Viele abgelaufene Benutzerdaten haben keinen kommerziellen Wert oder Aufbewahrungswert, aber wenn sie durchsickern, bergen sie enorme Marken- und Compliance-Risiken für das Unternehmen.

Lösung: Für Unternehmen, die Benutzerdaten speichern, nicht nur PII oder PHI, ist eine gründliche Datenprüfung erforderlich. Nach Prüfung der gespeicherten Daten sollten Datenzugriffsregeln entwickelt und getestet werden. Stellen Sie sicher, dass es sich bei den Daten, auf die anonym zugegriffen werden kann, nicht um sensible Daten handelt.

5. Zu wenig Sicherheitsdesign

Seit vielen Jahren stehen beim Anwendungsdesign immer Funktionalität und Benutzerfreundlichkeit im Vordergrund, ohne dass die Sicherheit berücksichtigt wird. Viele CISOs sagen, dass insbesondere die API-Sicherheit nicht ernst genommen oder sogar vollständig aus dem Sicherheitsdesignprozess ausgeschlossen wird. Nachdem Entwickler die Entwicklung und Bereitstellung abgeschlossen haben, versuchen sie normalerweise erst, Probleme zu finden, nachdem die API in Produktion gegangen ist und häufig angegriffen wurde. Sicherheit (einschließlich API-Sicherheit) muss Teil des Produktdesigns sein und als eine der ersten Überlegungen umgesetzt werden, nicht als nachträglicher Einfall.

Lösung: Die Überprüfung der Sicherheitsarchitektur Ihrer Anwendung ist ein wichtiger erster Schritt auf dem Weg zu einem sicheren System. Denken Sie daran, dass APIs es Angreifern ermöglichen, Ihr System effizienter anzugreifen oder auszunutzen. Das Ziel des Sicherheitsdesigns besteht darin, die API zu einem effizienten Werkzeug für Benutzer und nicht für Angreifer zu machen.

Das obige ist der detaillierte Inhalt vonWas sind die fünf häufigsten Schwachstellen von APIs?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:yisu.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen