Top-10-Webanwendungsbedrohungen der OWASP

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen

In diesem Dokument werden verschiedene Ansätze beschrieben, die Sie in Apigee verwenden können, um die von OWASP identifizierten Sicherheitslücken zu schließen. Weitere für Apigee dokumentierte Ansätze finden Sie unter OWASP Top 10 2021 Minderungsoptionen in Google Cloud.

Überblick

API-Umgebungen sind mit verschiedenen Angriffen sowohl von externen als auch von internen Kunden konfrontiert. Das Anbieten und Verwenden von APIs eröffnet Dienstanbietern enorme Möglichkeiten, birgt aber auch einige Sicherheitsrisiken. Entwickler müssen sich dieser Herausforderungen bewusst sein und sie beim Erstellen und Verwenden von APIs angehen.

OWASP ist eine offene Community, die Organisationen dabei unterstützt, vertrauenswürdige Anwendungen und APIs zu entwickeln, zu erwerben und zu warten. OWASP veröffentlicht im Rahmen des OWASP API Security-Projekts die kritischsten Sicherheitsrisiken für Webanwendungen und REST APIs und gibt Empfehlungen zum Umgang mit diesen Risiken.

Mit Apigee kann die API-Proxy-Ebene fehlerhafte API-Anfragen des Clients erkennen, blockieren und melden, bevor die Anfragen auf den Back-End-Systemen verarbeitet werden. So werden Risiken minimiert und Ihre Dienste geschützt. Fehlerhafte Anfragen können jede Komponente umfassen, aus der das HTTP-Protokoll auf Anwendungsebene besteht:

  • URL
  • Header
  • Pfad
  • Nutzlast

Fehlerhafte API-Anfragen können von bekannten oder unbekannten Clients stammen, die von externen Entwicklern, internen Entwicklern oder schädlichen Bots entwickelt wurden. Diese Arten von Anfragen stellen die meisten OWASP-Bedrohungen dar. Es gibt jedoch zusätzliche Komponenten der zugrunde liegenden API-Proxy-Ebene, die Risiken wie Datenmaskierung, Logging, Verwaltung usw. mindern können.

Mit der intelligenten API-Verwaltungsplattform von Apigee können Sie die häufigsten OWASP-API-Sicherheitslücken nahtlos schließen, während Sie Ihre APIs nach einem verbrauchsorientierten Ansatz gestalten und mit Ihren Back-End-Systemen verbinden. Nachfolgend finden Sie eine Liste der Richtlinien/Konfigurationen, die Apigee für die häufigsten REST OWASP-Bedrohungen empfiehlt.

Apigee-Lösungen für die OWASP Top 10 2017

Beim Erstellen und Sichern von Webanwendungen gibt es viele Sicherheitsbedenken. OWASP hat die Liste der 10 wichtigsten OWASP-Sicherheitsbedrohungen 2017 für Webanwendungen veröffentlicht. Eine Webanwendung besteht aus vielen Teilen, aber die meisten modernen Webanwendungen basieren stark auf REST APIs. Apigee ist nicht für alle Sicherheitsanforderungen einer Webanwendung gedacht, kann aber eine entscheidende Rolle beim Schutz der REST APIs spielen. Im Folgenden finden Sie die wichtigsten OWASP-Sicherheitsbedrohungen und Beschreibungen, wie Sie Apigee zur Abwehr dieser Bedrohungen einsetzen können.

A1:2017 – Einschleusung

Zum Schutz vor nicht vertrauenswürdigen Dateninschleusungen wie SQL, NoSQL, LDAP und JavaScript, die zur Ausführung unbeabsichtigter Befehle oder unbefugter Datenzugriffe führen kann, bietet Apigee verschiedene Richtlinien zur Eingabevalidierung, um vor der weiteren Verarbeitung zu überprüfen, ob die von einem Client bereitgestellten Werte den Erwartungen entsprechen. Apigee Edge fungiert als Server für die eingehenden API-Anfragen und prüft, ob die Nutzlaststruktur in einen akzeptablen Bereich fällt. Dies wird auch als Limitprüfung bezeichnet. Sie können einen API-Proxy so konfigurieren, dass die Eingabevalidierungsroutine die Eingabe umwandelt, um riskante Zeichensequenzen zu entfernen und durch sichere Werte zu ersetzen.

Es gibt mehrere Ansätze zur Validierung von Eingaben mit der Apigee-Plattform:

Inhaltstypen validieren:

A2:2017 – Fehlerhafte Authentifizierung und Sitzungsverwaltung

Angreifer können auf Passwörter, Sitzungstokens und Schlüssel zugreifen, um sich als andere Nutzer auszugeben, indem sie Implementierungsfehler in Anwendungen ausnutzen. Dabei handelt es sich eher um ein Implementierungsproblem, nicht um ein Produktproblem. Apigee bietet Richtlinien für „VerifyApiKey“, „OAuth“ und „JSON Web Token“ (JWT) zum Schutz vor dieser Sicherheitslücke.

API-Schlüsselüberprüfung

Die API-Schlüsselvalidierung ist die einfachste Form der anwendungsbasierten Sicherheit, die für eine API konfiguriert werden kann. Eine Client-App stellt in ihrer Anfrage einfach einen API-Schlüssel bereit. Anschließend prüft Apigee Edge über eine mit einem API-Proxy verknüpfte Richtlinie, ob der API-Schlüssel für die angeforderte Ressource genehmigt wurde.

Apigee unterstützt das Generieren und Validieren von API-Schlüsseln. Apigee generiert einen API-Schlüssel und ein Secret, wenn eine Entwickler-App erstellt und genehmigt wird, die mit einem oder mehreren API-Produkten verknüpft ist.

Der Begriff „API-Schlüssel“ kann unterschiedliche Bedeutungen haben. Wenn in Apigee die Beziehung zwischen Anwendung und Produkt aufgebaut wird, generiert Apigee eine Client-ID und einen Clientschlüssel. Einige beziehen sich sowohl auf die ID als auch auf das Secret als API-Schlüssel. In einigen Fällen wird nur die Client-ID als API-Schlüssel bezeichnet. In der Edge-Benutzeroberfläche werden „Consumer key“ und „Consumer Secret“ angezeigt.

In der VerifyAPIKey-Richtlinie wird nur die Client-ID bzw. der Nutzerschlüssel verifiziert. Entwickler erhalten einen Consumer-Key, wenn sie ihre App bei Apigee registrieren und die App mit einem API-Produkt verknüpfen. Entwickler fügen den Consumer-Key in Aufrufe von API-Proxys, die im API-Produkt gebündelt sind, ein.

Apigee unterstützt auch die Möglichkeit, vorhandene API-Schlüssel aus externen Quellen zu importieren.

Für OAuth-Zustimmungstypen werden sowohl die Client-ID als auch der Clientschlüssel verwendet.

oauth 2.0

Mit dem OAuth 2.0-Autorisierungs-Framework kann eine Drittanbieteranwendung eingeschränkten Zugriff auf einen HTTP-Dienst erhalten – entweder im Namen eines Ressourceninhabers, indem eine Genehmigungsinteraktion zwischen dem Ressourceninhaber und dem HTTP-Dienst orchestriert wird, oder indem die Drittanbieteranwendung in ihrem eigenen Namen Zugriff erhält.

Mit den OAuth 2.0-Richtlinien von Apigee können Sie die vier OAuth 2.0-Genehmigungstypen implementieren und anpassen. Die Erzwingung von OAuth-Zugriffstokens kann mit der OAuthv2-Richtlinie erfolgen. Der Nutzer muss registriert sein und eine genehmigte App haben, die ihm Zugriff auf die API gewährt hat. Im Gegenzug erhalten sie eine API-Client-ID und einen Clientschlüssel. Der Nutzer muss eine der OAuth-Zustimmungen zur Authentifizierung durchlaufen. Dabei erhält er ein intransparentes Zugriffstoken. Mit diesem Token kann der Zugriff auf die API gesteuert werden.

JWT

JSON Web Tokens oder JWTs werden häufig verwendet, um Anforderungen oder Assertions zwischen verbundenen Anwendungen zu teilen. Apigee bietet JWT-Unterstützung mithilfe von drei Richtlinien.

  • JWT-Tokens generieren (unterstützt HS256- und RS256-Signatur)
  • JWT-Tokens validieren
  • JWT-Tokens ohne Validierung decodieren

A3:2017 – Sensible Daten preisgegeben

Angreifer nutzen sensible Daten wie Kreditkartendetails, Sozialversicherungsnummern, Anmeldedaten, personenidentifizierbare Informationen und Steuernummern, um Identitätsdiebstahl, Gelddiebstahl, Betrug und andere Straftaten zu begehen. Webanwendungen müssen eine Verschlüsselung sowohl im Ruhezustand als auch bei der Übertragung sowie andere Strategien zum Schutz sensibler Daten implementieren.

TLS (Transport Layer Security, dessen Vorgänger SSL ist) ist die Standardsicherheitstechnologie zum Herstellen einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient wie einem Browser oder einer Anwendung. Apigee unterstützt sowohl One-Way- als auch Zwei-Wege-TLS.

Northbound TLS (Client, der eine Verbindung zur API herstellt, die als Server dient) wird durch die Verwendung einer Konfiguration für einen virtuellen Host unterstützt. Ein virtueller Host kann für One-Way- oder Zwei-Wege-TLS konfiguriert werden.

Southbound TLS (Apigee als Client, der eine Verbindung zum Back-End-Dienst herstellt) wird durch die Verwendung einer Zielserver-Konfiguration unterstützt. Ein Zielserver kann für One-Way-TLS oder für Zwei-Wege-TLS konfiguriert werden.

Apigee unterstützt viele TLS-Konfigurationsoptionen.

Die Zwei-Wege-TLS-Erzwingung stellt sicher, dass der Client ein Zertifikat verwendet, das bereits in Apigee aufgenommen wurde. OWASP bietet außerdem Best Practices für TLS.

In Apigee Hybrid ist TLS beim eingehenden Traffic über einen Hostalias verfügbar, was einem virtuellen Host ähnelt.

Im Folgenden finden Sie Richtlinien zum Sichern sensibler Daten:

  • Verwenden Sie eine Plattform, die One-Way- und Zwei-Wege-TLS unterstützt und auf Protokollebene schützt.
  • Verwenden Sie Richtlinien wie die AssignMessage-Richtlinie und die JavaScript-Richtlinie, um sensible Daten zu entfernen, bevor sie an den Client zurückgegeben werden.
  • Verwenden Sie Standard-OAuth-Techniken und ziehen Sie in Betracht, HMAC, Hash, Status, Nonce, PKCE oder andere Methoden hinzuzufügen, um das Authentifizierungsniveau für jede Anfrage zu verbessern.
  • Verwenden Sie die Einstellungen für die Datenmaskierung, um sensible Daten im Edge Trace-Tool zu maskieren.
  • Seien Sie vorsichtig, wenn Sie sensible Daten im Cache speichern (oder verschlüsseln Sie sensible Daten, die im Cache gespeichert sind). In Edge können Sie inaktive sensible Daten in Schlüssel/Wert-Zuordnungen verschlüsseln.

A4:2017 – Externe XML-Entitäten

Systeme oder Anwendungen, die XML verarbeiten, müssen „externe Entitätsverweise“ in XML verarbeiten – Verweise auf Dateien oder Daten, die während der XML-Verarbeitung durch die tatsächlichen Daten ersetzt werden. Wenn die Anwendungen oder XML-Prozessoren alt oder schlecht implementiert sind, können Angreifer die Daten hacken und sie verwenden, um Informationen zu stehlen oder verschiedene Arten von Angriffen auf das System zu starten, wie z. B. Denial-of-Service.

Mit der Richtlinie „ExtractVariables“ von Apigee können Sie den Inhalt aus einer Anfrage oder Antwort extrahieren und einer Variablen zuweisen. Sie können jeden Teil der Nachricht extrahieren, einschließlich Header, URI-Pfade, JSON/XML-Nutzlasten, Formularparameter und Abfrageparameter. Die Richtlinie wendet ein Textmuster auf den Nachrichteninhalt an und legt bei Übereinstimmung eine Variable mit dem angegebenen Nachrichteninhalt fest.

Apigee verfügt als Teil der Plattform über einen integrierten XML-Parser, der XPath zum Extrahieren von Daten verwendet. Sie hat auch eine XMLThreatProtection-Richtlinie zum Schutz vor schädlichen XML-Nutzlasten.

A5:2017 – Fehlerhafte Zugriffssteuerung

Nachdem sich Nutzer angemeldet und Zugriff auf ein System erhalten haben, müssen geeignete Autorisierungskontrollen implementiert werden, damit Nutzer nur das sehen und tun können, was sie zu tun haben. Ohne strikte Zugriffskontrollen können Angreifer nicht autorisierte und häufig sensible Daten einsehen oder Daten und das Systemverhalten böswillig manipulieren.

Apigee unterstützt einen mehrschichtigen Ansatz zur Implementierung von Zugriffskontrollen, um zu verhindern, dass böswillige Akteure nicht autorisierte Änderungen vornehmen oder auf das System zugreifen.

Zugriffssteuerungen für die Edge-Benutzeroberfläche

Zugriffssteuerungen für das Apigee-Entwicklerportal

  • Konfigurieren Sie die Einmalanmeldung (SSO) mit dem Identitätsanbieter Ihres Unternehmens.
  • Konfigurieren Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), um Nutzern nur den Zugriff auf die Funktionalität und Konfiguration auf Drupal-basierten Entwicklerportalen zu ermöglichen.
  • Konfigurieren Sie Entwicklerportale so, dass bestimmte API-Produkte entsprechend der Nutzerrolle angezeigt werden.
  • Konfigurieren Sie das Portal so, dass Inhalte je nach Nutzerrolle ein- oder ausgeblendet werden.

Zugriffssteuerungen für den API-Zugriff der Apigee-Laufzeit

  • Der Zugriff auf APIs kann mithilfe von API-Schlüsseln, OAuth-Tokens, OAuth-Bereichen, Zertifikaten und anderen Verfahren erzwungen werden.
  • Der API-Anbieter konfiguriert die verfügbaren Ressourcen durch die Definition eines API-Produkts. Der Zugriff wird entweder manuell in der UI, über die Management API oder über das Entwicklerportal gewährt. Wenn der App eines Entwicklers Zugriff auf ein API-Produkt gewährt wird, empfangen er eine Client-ID und ein Secret, die für den Authentifizierungsprozess verwendet werden.
  • Apigee kann mit jedem Identitätsanbieter verknüpft werden, um OAuth auszuführen.
  • Apigee kann JWT-Tokens oder andere Techniken generieren, um die Nutzeridentität an Zieldienste zu senden. Die Zieldienste können diese Identität verwenden, um den Zugriff auf Dienste und Daten nach Bedarf einzuschränken.

A6:2017 – Fehlkonfiguration der Sicherheitsfunktionen

Sicherheitsfehlkonfigurationen sind leicht zu übersehen, da Administratoren und Entwickler fälschlicherweise darauf vertrauen, dass die von ihnen verwendeten Systeme von Natur aus sicher sind. Sicherheitsfehlkonfigurationen können auf viele verschiedene Arten auftreten, z. B. wenn Standardkonfigurationen vertrauen oder Teilkonfigurationen vorgenommen werden, die möglicherweise unsicher sind, Fehlermeldungen enthalten vertrauliche Details, Daten in der Cloud ohne geeignete Sicherheitskontrollen speichern, HTTP-Header falsch konfigurieren usw. Die Apigee-Plattform bietet eine Reihe von Mechanismen zum Steuern, Verwalten und Überwachen von Sicherheitskonfigurationen, einschließlich wiederverwendbarer freigegebener Abläufe.

Mit einem gemeinsamen Ablauf können API-Entwickler Richtlinien und Ressourcen zu einer wiederverwendbaren Gruppe kombinieren. Da wiederverwendbare Funktionen an einem Ort gespeichert werden, sorgt ein gemeinsamer Ablauf für Konsistenz, verkürzen die Entwicklungszeit und vereinfachen die Codeverwaltung. Sie können einen freigegebenen Ablauf in einzelne API-Proxys einfügen oder einen Schritt weiter gehen und freigegebene Abläufe in Ablauf-Hooks platzieren, um automatisch eine freigegebene Ablauflogik für jeden API-Proxy auszuführen, der in derselben Umgebung als freigegebener Ablauf bereitgestellt wird.

Apigee-Produkt-Releases sorgen für Schutz vor Bibliotheken mit Sicherheitslücken. Apigee kann zusätzliche Patches oder Updates veröffentlichen, wenn neue Sicherheitslücken gefunden werden. Die öffentliche Edge Cloud wird automatisch gepatcht. Edge for Private Cloud-Kunden (lokal) müssen Produkt-Patches selbst anwenden.

A7:2017 – Cross-Site-Scripting (XSS)

Cross-Site-Scripting (XSS) ermöglicht es Angreifern, Scripts in Webbrowsern von Nutzern auszuführen, um Nutzersitzungen zu steuern, Websites zu manipulieren oder Nutzer auf andere Weise böswillig zu beschädigen. XSS-Probleme beziehen sich nicht unbedingt auf APIs, aber Apigee bietet Richtlinien für den Schutz vor XSS in der API. Prüfen Sie mithilfe von regulären Ausdrücken, entweder mit der RegularExpressionProtection-Richtlinie oder der JavaScript-Richtlinie, die Nutzlast- und Parameterwerte auf JavaScript- und andere Injection-Angriffe.

CORS, eine der am häufigsten implementierten Lösungen für die Same-Origin-Policy, die von allen Browsern erzwungen wird, kann mit der AssignMessage-Richtlinie implementiert werden.

A8:2017 – Nicht sichere Deserialisierung

Angreifer können Schwachstellen bei der Deserialisierung für verschiedene Arten von Angriffen ausnutzen, z. B. Wiederholung, Rechteausweitung und Injection. Eine unsichere Deserialisierung kann auch die Remote-Codeausführung ermöglichen.

Apigee empfiehlt keine Deserialisierung. Die JSONThreatProtection-Richtlinie und die RegularExpressionProtection-Richtlinie können jedoch zum Schutz vor schädlichen JSON-Nutzlasten beitragen. Die JavaScript-Richtlinie kann auch verwendet werden, um Nutzlasten auf schädliche Inhalte zu scannen. Der Cache und andere Richtlinien können zum Schutz vor Replay-Angriffen verwendet werden. Auf Infrastrukturebene verfügt die Apigee-Plattform außerdem über integrierte Sicherheitsvorkehrungen zum Schutz laufender Prozesse.

A9:2017 – Komponenten mit bekannten Sicherheitslücken verwenden

Da Frameworks, Bibliotheken und Module mit vollständiger Ausführung und CRUD-Zugriff ausgeführt werden, können Angreifer Sicherheitslücken in Komponenten nutzen, um Systeme anzugreifen.

Die regulären Produktreleases von Apigee bieten Schutz vor Sicherheitslücken von Komponenten, insbesondere wenn bestimmte Sicherheitslücken entdeckt werden. Die öffentliche Apigee Cloud wird automatisch gepatcht und Apigee benachrichtigt Edge für Private Cloud-Kunden, wenn lokale Patches für die Installation verfügbar sind.

A10:2017 – Unzureichendes Logging und Monitoring

Wenn Sie Logging, Monitoring und Vorfallmanagement in Ihren Systemen nicht angemessen ausführen, können Angreifer tiefere und länger dauernde Angriffe auf Daten und Software ausführen.

Apigee bietet mehrere Möglichkeiten für Logging, Monitoring, Fehlerbehandlung und Audit-Logging.

Logging

  • Lognachrichten können mithilfe der MessageLogging-Richtlinie an Splunk oder einen anderen Syslog-Endpunkt gesendet werden.
  • API-Analysedaten können über die Analytics API abgerufen und in andere Systeme importiert oder exportiert werden.
  • In Edge for Private Cloud können Sie die MessageLogging-Richtlinie verwenden, um in lokale Protokolldateien zu schreiben. Außerdem sind Protokolldateien von jeder der laufenden Komponenten verfügbar.
  • Mithilfe der JavaScript-Richtlinie können Lognachrichten synchron oder asynchron an einen REST-Logging-Endpunkt gesendet werden.

Monitoring

  • Verwenden Sie die Benutzeroberfläche oder die API für das API-Monitoring, um APIs und Back-Ends regelmäßig zu überwachen und Alets zu auslösen.
  • Verwenden Sie die Statusüberwachung, um die Zielserver-Back-Ends regelmäßig zu überwachen.
  • Apigee bietet Empfehlungen zum Monitoring von Edge für Private Cloud.
  • Apigee bietet außerdem Best Practices, die Ihr Team für das Monitoring Ihres API-Programms nutzen kann.

Fehlerbehandlung

Apigee bietet einen leistungsstarken, vielseitigen Fehlerbehandlungsmechanismus für API-Proxys. Ähnlich wie bei einem Java-Programm können API-Proxys Fehler abfangen und bestimmen, wie geeignete Antworten an Clients zurückgegeben werden. Mit der benutzerdefinierten Fehlerbehandlung von Apigee können Sie Funktionen wie das Nachrichten-Logging hinzufügen, wenn ein Fehler auftritt.

Audit-Logs

Die Apigee-Plattform führt ein Audit-Log, das Änderungen an API-Proxys, Produkten und dem Organisationsverlauf nachverfolgt. Dieses Log ist über die UI oder über die Audits API verfügbar.

Apigee-Lösungen für OWASP-Schwachstellen 2013

Bei der Aktualisierung der OWASP-Liste für 2017 wurden einige Sicherheitslücken aus dem Jahr 2013 nicht mehr angezeigt. Es handelt sich dabei nach wie vor um gültige Bedrohungen. In den folgenden Abschnitten wird beschrieben, wie Sie mit Apigee umgehen.

A8:2013 – Cross-Site Request Forgery (CSRF)

Bei websiteübergreifenden Fälschungsanfragen können Angreifer die Authentifizierungsdetails, das Sitzungscookie und andere Daten eines Nutzers über HTTP an eine anfällige Webanwendung weiterleiten. Dadurch täuscht die Webanwendung vor, die Anfragen seien legitime Anfragen des Nutzers.

Richtlinien:

  • Dabei handelt es sich eher um ein Browserproblem, nicht um ein Problem mit einem API-Produkt. Sie können diese Sicherheitslücke mit OpenID Connect, OAuth und anderen Verfahren schließen.
  • Erwägen Sie den Einsatz von HMAC-, State-, Hash-, Nonce- oder PKCE-Techniken, um Fälschungen und Replay-Angriffe zu verhindern.

A10:2013 – Nicht validierte Weiterleitungen und Weiterleitungen

Wenn eine Webanwendung Weiterleitungen ausführt, aber nicht prüft, ob Nutzer durch Weiterleitungen zu vertrauenswürdigen, vorgesehenen Websites weitergeleitet werden, können Angreifer Nutzer zu schädlichen Zielen weiterleiten, um Phishing, Malware und andere Angriffe auszuführen.

Richtlinien:

  • OAuth verwenden und eine Validierung bei jeder Anfrage erzwingen.
  • Verhindern Sie unerwartete 302-Weiterleitungen, indem Sie die API-Proxy-Logik auf Antwortcodes prüfen und Weiterleitungen entsprechend verwalten.