Top-10-Webanwendungsbedrohungen der OWASP

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

In diesem Dokument werden verschiedene Ansätze beschrieben, mit denen Sie in Apigee Sicherheitslücken beheben können, die von OWASP identifiziert wurden. Weitere für Apigee dokumentierte Ansätze finden Sie unter OWASP Top 10 2021 – Optionen zur Risikominimierung in Google Cloud.

Übersicht

API-Umgebungen werden sowohl von externen als auch von internen Clients angegriffen. Das Angebot und die Nutzung von APIs bietet Dienstanbietern enorme Chancen, birgt aber auch einige Sicherheitsrisiken. Entwickler müssen sich dieser Herausforderungen bewusst sein und sie angehen, wenn sie APIs erstellen und verwenden.

OWASP ist eine offene Community, die Organisationen dabei unterstützt, vertrauenswürdige Anwendungen und APIs zu entwickeln, zu kaufen und zu verwalten. Im Rahmen des OWASP API Security Project veröffentlicht OWASP die wichtigsten Sicherheitsrisiken für Webanwendungen und REST APIs und gibt Empfehlungen zur Behebung dieser Risiken.

Mit Apigee kann die API-Proxy-Ebene fehlerhafte API-Anfragen vom Client erkennen, blockieren und melden, bevor die Anfragen in den Back-End-Systemen verarbeitet werden. So werden Risiken minimiert und Ihre Dienste geschützt. Falsch formatierte Anfragen können jede Komponente des HTTP-Protokolls auf Anwendungsebene enthalten:

  • URL
  • Header
  • Pfad
  • Nutzlast

Falsch formatierte API-Anfragen können von bekannten oder unbekannten Clients stammen, die von externen oder internen Entwicklern oder schädlichen Bots entwickelt wurden.  Diese Arten von Anfragen machen den Großteil der OWASP-Bedrohungen aus. Es gibt jedoch zusätzliche Komponenten der zugrunde liegenden API-Proxy-Ebene, mit denen Risiken gemindert werden können, z. B. Datenmaskierung, Logging und Verwaltung.

Mit der intelligenten API-Verwaltungsplattform von Apigee können Sie die wichtigsten OWASP-API-Sicherheitslücken nahtlos beheben, indem Sie Ihre APIs verbraucherorientiert entwerfen und mit Ihren Backend-Systemen verbinden. Im Folgenden finden Sie eine Liste der Richtlinien/Konfigurationen, die Apigee für die wichtigsten REST-OWASP-Bedrohungen empfiehlt.

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

Beim Erstellen und Schützen von Webanwendungen gibt es viele Sicherheitsaspekte. OWASP hat die Liste der Top 10 OWASP-Sicherheitsbedrohungen 2017 für Webanwendungen veröffentlicht.  Eine Webanwendung besteht aus vielen Teilen, die meisten modernen Webanwendungen sind jedoch stark auf REST APIs angewiesen.  Apigee ist nicht dafür gedacht, alle Sicherheitsanforderungen einer Webanwendung zu erfüllen, kann aber eine wichtige Rolle bei der Sicherung der REST APIs spielen. Im Folgenden finden Sie die wichtigsten OWASP-Sicherheitsbedrohungen mit Beschreibungen dazu, wie Sie Apigee zur Bewältigung dieser Bedrohungen einsetzen können.

A1:2017 – Injection

Zum Schutz vor nicht vertrauenswürdigen Dateninjektionen wie SQL, NoSQL, LDAP und JavaScript, die zur Ausführung unbeabsichtigter Befehle oder zum unbefugten Datenzugriff führen können, bietet Apigee mehrere Eingabevalidierungsrichtlinien, um zu prüfen, ob die von einem Client bereitgestellten Werte den Erwartungen entsprechen, bevor die weitere Verarbeitung zugelassen wird. Apigee Edge, das als Server für eingehende API-Anfragen fungiert, prüft, ob die Nutzlaststruktur in einen akzeptablen Bereich fällt. Diese Prüfung wird auch als Grenzwertprüfung bezeichnet. Sie können einen API-Proxy so konfigurieren, dass die Eingabevalidierungsroutine die Eingabe transformiert, um riskante Zeichensequenzen zu entfernen und sie dann 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. Dies ist eher ein Implementierungsproblem als ein Produktproblem.  Apigee stellt VerifyApiKey-, OAuth- und JWT-Richtlinien (JSON Web Token) bereit, die vor dieser Sicherheitslücke schützen.

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 Clientanwendung präsentiert dabei einfach einen API-Schlüssel mit der zugehörigen Anfrage. Apigee Edge prüft dann über eine Richtlinie, die mit einem API-Proxy verknüpft ist, ob der API-Schlüssel einen Genehmigungsstatus für die angefragte Ressource aufweist.

Apigee unterstützt die Generierung und Validierung 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 manchmal verschiedene Bedeutungen haben. Wenn in Apigee die Beziehung zwischen App und Produkt hergestellt wird, generiert Apigee eine Client-ID und ein Client-Secret.  Manche bezeichnen sowohl die ID als auch das Secret als API-Schlüssel. Einige bezeichnen nur die Client-ID als API-Schlüssel. In der Edge-Benutzeroberfläche sehen Sie „Consumer-Key“ und „Consumer-Secret“.

In der VerifyAPIKey-Richtlinie wird nur die Client-ID oder der „Consumer-Key“ überprüft. Entwickler erhalten einen Verbraucherschlüssel, wenn sie ihre App bei Apigee registrieren und die App mit einem API-Produkt verknüpfen. Entwickler fügen den Consumer-Schlüssel in Aufrufe der App an API-Proxys ein, die im API-Produkt gebündelt sind.

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

Für OAuth-Berechtigungstypen werden sowohl die Client-ID als auch das Secret verwendet.

oauth 2.0

Mit dem OAuth 2.0-Autorisierungsframework kann eine Drittanbieteranwendung eingeschränkten Zugriff auf einen HTTP-Dienst erhalten, entweder im Namen eines Ressourceneigentümers durch eine Genehmigungsinteraktion zwischen dem Ressourceneigentümer und dem HTTP-Dienst oder indem der Drittanbieteranwendung Zugriff in eigenem Namen gewährt wird.

Mit den OAuth 2.0-Richtlinien von Apigee können Sie die vier OAuth 2.0-Berechtigungstypen implementieren und anpassen. Die Erzwingung von OAuth-Zugriffstokens kann mithilfe der OAuthv2-Richtlinie erfolgen. Der Verbraucher muss registriert sein und eine genehmigte App haben, die ihm Zugriff auf die API gewährt. Im Gegenzug erhalten sie eine API-Client-ID und einen Clientschlüssel. Der Verbraucher muss eine der OAuth-Berechtigungen durchlaufen, um authentifiziert zu werden. Dadurch erhält er ein undurchsichtiges Zugriffstoken. Mit diesem Token kann der Zugriff auf die API gesteuert werden.

JWT

JSON Web Tokens (JWT) werden häufig zum Freigeben von Anforderungen oder Assertions für verbundene Anwendungen verwendet. Apigee bietet JWT-Unterstützung mit drei Richtlinien.

  • GenerateJWT-Token (unterstützt HS256- und RS256-Signatur)
  • ValidateJWT-Tokens
  • DecodeJWT-Tokens ohne Validierung

A3:2017 – Offenlegung sensibler Daten

Angreifer zielen auf sensible Daten wie Kreditkartendetails, Sozialversicherungsnummern, Anmeldedaten, personenidentifizierbare Informationen und Steuernummern ab, um Identitätsdiebstahl, Gelddiebstahl, Betrug und andere Straftaten zu begehen. Webanwendungen müssen sowohl ruhende als auch übertragene Daten verschlüsseln und andere Strategien implementieren, um sensible Daten zu schützen.

TLS (Transport Layer Security, dessen Vorgänger SSL ist) ist die Standardsicherheitstechnologie zum Aufbau einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer App. Apigee unterstützt sowohl Ein- als auch Zwei-Wege-TLS.

Northbound-TLS (Clientverbindung zur API, die als Server dient) wird durch die Verwendung einer virtuellen Hostkonfiguration unterstützt. Ein virtueller Host kann für uni- oder bidirektionale TLS konfiguriert werden.

Südgerichtetes TLS (Apigee als Client, der eine Verbindung zum Backend-Dienst herstellt) wird durch die Verwendung einer Zielserverkonfiguration unterstützt.  Ein TargetServer kann für One-Way- oder Bidirektionales-TLS konfiguriert werden.

Apigee unterstützt viele Konfigurierungsoptionen für TLS.

Durch die Erzwingung von Zwei-Wege-TLS wird sichergestellt, dass der Client ein Zertifikat verwendet, das bereits in Apigee registriert wurde. OWASP bietet auch Best Practices für TLS.

In Apigee Hybrid ist TLS am Eingang über einen Hostalias verfügbar, der einem virtuellen Host ähnelt.

Im Folgenden finden Sie Richtlinien zum Schutz sensibler Daten:

  • Verwenden Sie eine Plattform, die uni- und bidirektionale TLS-Verschlüsselung unterstützt, um die Daten auf Protokollebene zu schützen.
  • 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 erwägen Sie das Hinzufügen von HMAC-, Hash-, Status-, Nonce-, PKCE- oder anderer Techniken, um die Authentifizierungsstufe für jede Anfrage zu verbessern.
  • Verwenden Sie die Einstellungen für die Datenmaskierung, um vertrauliche Daten im Edge Trace-Tool zu maskieren.
  • Speichern Sie keine sensiblen Daten im Cache oder verschlüsseln Sie sie. In Edge können Sie sensible inaktive Daten in Schlüssel/Wert-Zuordnungen verschlüsseln.

A4:2017 – Externe XML-Entitäten

Systeme oder Anwendungen, die XML verarbeiten, müssen „externe Entitätsreferenzen“ 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 veraltet oder schlecht implementiert sind, können Angreifer die Daten hacken und damit Informationen stehlen oder verschiedene Arten von Angriffen auf das System starten, z. B. einen Denial-of-Service-Angriff.

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

Apigee hat einen integrierten XML-Parser, der Daten mithilfe von XPath extrahiert. Außerdem gibt es 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 ordnungsgemäße Autorisierungssteuerungen vorhanden sein, damit Nutzer nur das sehen und tun können, was ihnen erlaubt ist. Ohne strenge Zugriffssteuerungen können Angreifer unbefugt auf häufig vertrauliche Daten zugreifen oder Daten und das Systemverhalten böswillig manipulieren.

Apigee unterstützt einen mehrstufigen Ansatz zur Implementierung von Zugriffssteuerungen, um zu verhindern, dass böswillige Nutzer Änderungen vornehmen oder auf das System zugreifen.

Zugriffssteuerung für die Edge-Benutzeroberfläche

Zugriffssteuerung 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 Funktionen und Konfigurationen zu ermöglichen, die sie in Drupal-basierten Entwicklerportalen benötigen.
  • Konfigurieren Sie Entwicklerportale, um bestimmte API-Produkte entsprechend der Nutzerrolle anzuzeigen.
  • Konfigurieren Sie das Portal so, dass Inhalte je nach Nutzerrolle ein- oder ausgeblendet werden.

Zugriffssteuerung für den Apigee-Laufzeit-API-Zugriff

  • Der Zugriff auf APIs kann über API-Schlüssel, OAuth-Tokens, OAuth-Bereiche, Zertifikate und andere Methoden erzwungen werden.
  • Der API-Anbieter konfiguriert, welche Ressourcen verfügbar sind, indem er ein API-Produkt definiert. Der Zugriff wird entweder manuell über die Benutzeroberfläche, über die Management API oder über das Entwicklerportal gewährt. Wenn die App eines Entwicklers Zugriff auf ein API-Produkt erhält, erhält er eine Client-ID und ein Secret, die für den Authentifizierungsprozess verwendet werden.
  • Apigee kann mit jedem Identitätsanbieter für OAuth integriert werden.
  • Apigee kann JWT-Tokens oder andere Methoden 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-Sicherheitsfehlkonfiguration

Sicherheitsfehler sind leicht zu übersehen, oft weil Administratoren und Entwickler fälschlicherweise davon ausgehen, dass die von ihnen verwendeten Systeme von Natur aus sicher sind. Sicherheitskonfigurationsfehler können auf viele verschiedene Arten auftreten, z. B. durch das Vertrauen in Standardkonfigurationen, das Erstellen von Teilkonfigurationen, die möglicherweise nicht sicher sind, das Zulassen von vertraulichen Informationen in Fehlermeldungen, das Speichern von Daten in der Cloud ohne ordnungsgemäße Sicherheitskontrollen oder durch eine Fehlkonfiguration von HTTP-Headern. Die Apigee-Plattform bietet eine Reihe von Mechanismen, mit denen Sie Sicherheitskonfigurationen steuern, verwalten und überwachen können, einschließlich wiederverwendbarer gemeinsam genutzter Abläufe.

In einem freigegebenen Ablauf können API-Entwickler Richtlinien und Ressourcen in einer wiederverwendbaren Gruppe kombinieren. Durch die Erfassung wiederverwendbarer Funktionen an einem zentralen Ort kann ein freigegebener Ablauf für Konsistenz sorgen, die Entwicklungszeit verkürzen und Code einfacher verwalten. Sie können einen freigegebenen Ablauf in einzelne API-Proxys einfügen. Sie können auch einen Schritt weiter gehen und freigegebene Abläufe in Ablauf-Hooks platzieren, um die Logik des freigegebenen Ablaufs automatisch für jeden API-Proxy auszuführen, der in derselben Umgebung wie ein freigegebener Ablauf bereitgestellt wird.

Apigee-Produktveröffentlichungen bieten Schutz vor Bibliotheken mit Sicherheitslücken. Apigee kann zusätzliche Patches oder Updates veröffentlichen, wenn neue Sicherheitslücken gefunden werden. Edge Public Cloud wird automatisch gepatcht. Kunden von Edge for Private Cloud (on premises) müssen Produkt-Patches selbst anwenden.

A7:2017-Cross-Site Scripting (XSS)

Mit Cross-Site-Scripting (XSS) können Angreifer Skripts in Nutzer-Webbrowsern ausführen, um Nutzersitzungen zu steuern, Websites zu bearbeiten oder Nutzer auf andere Weise zu schädigen. XSS-Probleme hängen nicht unbedingt mit APIs zusammen. Apigee bietet jedoch Richtlinien zum Schutz vor Bedrohungen, die in der API vor XSS schützen können.  Mit regulären Ausdrücken, entweder mit der RegularExpressionProtection-Richtlinie oder der JavaScript-Richtlinie, können die Nutzlast- und Parameterwerte für JavaScript- und andere Injection-Angriffe geprüft werden.

CORS ist eine der häufig implementierten Lösungen für die Same-Origin-Richtlinie, die von allen Browsern durchgesetzt wird. Sie kann mithilfe der AssignMessage-Richtlinie implementiert werden.

A8:2017 – Unsichere Deserialisierung

Angreifer können Fehler bei der Deserialisierung für verschiedene Angriffsarten verwenden, wie z. B. Wiederholung, Rechteausweitung und Injection. Die unsichere Deserialisierung kann auch zu einer Remote-Codeausführung führen.

Apigee empfiehlt keine Deserialisierung. Die JSONThreatProtection-Richtlinie und die RegularExpressionProtection-Richtlinie können jedoch dazu beitragen, vor schädlichen JSON-Nutzlasten zu schützen. Mit der JavaScript-Richtlinie können auch Nutzlasten auf schädliche Inhalte geprüft werden. Der Cache und andere Richtlinien können zum Schutz vor Replay-Angriffen verwendet werden. Auf Infrastrukturebene sind in der Apigee-Plattform auch Schutzmaßnahmen zum Schutz laufender Prozesse integriert.

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 Komponentenlücken nutzen, um Systeme anzugreifen.

Die regelmäßigen Produktveröffentlichungen von Apigee bieten Schutz vor Komponentenlücken, insbesondere wenn bestimmte Sicherheitslücken entdeckt werden. Die Apigee Public Cloud wird automatisch gepatcht. Apigee benachrichtigt Edge for Private Cloud-Kunden, wenn lokale Patches zur Installation verfügbar sind.

A10:2017 – Unzureichendes Logging und Monitoring

Wenn Sie die Protokollierung, Überwachung und das Vorfallmanagement in Ihren Systemen nicht angemessen durchführen, können Angreifer umfassendere und länger andauernde 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 andere Syslog-Endpunkte 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 Logdateien zu schreiben. Außerdem sind Logdateien für alle ausgeführten Komponenten verfügbar.
  • Mit der JavaScript-Richtlinie können Lognachrichten synchron oder asynchron an einen REST-Logging-Endpunkt gesendet werden.

Monitoring

  • Verwenden Sie die API-Monitoring-UI oder API, um APIs und Back-Ends regelmäßig zu überwachen und Benachrichtigungen auszulösen.
  • Verwenden Sie das Systemmonitoring für das regelmäßige Monitoring der Zielserver-Back-Ends.
  • Apigee bietet Empfehlungen zum Monitoring von Edge for Private Cloud.
  • Apigee bietet auch Best Practices, mit denen Ihr Team Ihr API-Programm überwachen kann.

Fehlerbehandlung

Apigee bietet einen leistungsstarken, vielseitigen Mechanismus zur Fehlerbehandlung für API-Proxys. Ähnlich wie ein Java-Programm Ausnahmen abfangen kann, können API-Proxys Fehler abfangen und festlegen, wie entsprechende 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 speichert ein Audit-Log, das Änderungen an API-Proxys, Produkten und dem Organisationsverlauf erfasst.  Dieses Log ist über die Benutzeroberfläche oder über die Audits API verfügbar.

Apigee-Lösungen für OWASP-Sicherheitslücken 2013

Bei der Aktualisierung der Liste für 2017 wurden einige Sicherheitslücken aus der Liste von 2013 entfernt. Sie stellen jedoch weiterhin eine Bedrohung dar. In den folgenden Abschnitten wird beschrieben, wie Sie mit diesen Bedrohungen mit Apigee umgehen.

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

Mit Anfragen zur Website-Fälschung können Angreifer die Authentifizierungsdetails, das Sitzungscookie und andere Daten eines Nutzers über HTTP an eine anfällige Webanwendung weiterleiten, sodass die Webanwendung glaubt, dass es sich um legitime Anfragen des Nutzers handelt.

Richtlinien:

  • Dies ist eher ein Browserproblem als ein Problem mit einem API-Produkt. Sie können diese Sicherheitslücke mit OpenID Connect, OAuth und anderen Techniken schließen.
  • Verwenden Sie HMAC-, Status-, Hash-, Nonce- oder PKCE-Techniken, um Fälschungs- und Replay-Angriffe zu verhindern.

A10:2013 – Nicht validierte Weiterleitungen und Weiterleitungen

Wenn eine Webanwendung Weiterleitungen durchführt, aber nicht überprüft, ob Nutzer zu vertrauenswürdigen, beabsichtigten Websites weitergeleitet werden, können Angreifer Nutzer zu schädlichen Zielen weiterleiten, um Phishing, Malware-Ausführung und andere Angriffe durchzuführen.

Richtlinien:

  • Verwenden Sie OAuth und erzwingen Sie bei jeder Anfrage eine Validierung.
  • Unerwartete 302-Weiterleitungen können Sie verhindern, indem Sie in der API-Proxy-Logik nach Antwortcodes suchen und Weiterleitungen ordnungsgemäß verarbeiten.