Top-10-Webanwendungsbedrohungen der OWASP

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

In diesem Dokument werden verschiedene Ansätze beschrieben, die Sie in Apigee verwenden können, um von OWASP identifizierte Sicherheitslücken zu beheben. Weitere Ansätze, die für Apigee dokumentiert sind, finden Sie unter OWASP Top 10 2021 – Optionen zur Risikominimierung in Google Cloud.

Übersicht

API-Ökosysteme sind verschiedenen Angriffen von externen und internen Clients ausgesetzt. Das Anbieten und Verwenden von APIs bietet enorme Möglichkeiten für Dienstanbieter, birgt aber auch einige Sicherheitsrisiken. Entwickler müssen sich dieser Herausforderungen bewusst sein und sie bei der Erstellung und Verwendung von APIs berücksichtigen, wenn

OWASP ist eine offene Community, die Organisationen bei der Entwicklung, dem Kauf und der Wartung vertrauenswürdiger Anwendungen und APIs unterstützt. Über das OWASP API Security Project, veröffentlicht OWASP die kritischsten Sicherheitsrisiken für Webanwendungen und REST APIs und gibt Empfehlungen zur Behebung dieser Risiken.

Mit Apigee kann die API-Proxyebene fehlerhafte API-Anfragen vom Client 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 enthalten, 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 böswilligen 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-Proxyebene, die Risiken mindern können, z. B. Datenmaskierung, Logging und Verwaltung.

Mit der intelligenten API-Verwaltungsplattform von Apigee können Sie die wichtigsten OWASP-Sicherheitslücken für APIs nahtlos beheben, indem Sie einen verbrauchsorientierten Ansatz für das Design Ihrer APIs verfolgen und sie mit Ihren Back-End-Systemen verbinden. Im Folgenden finden Sie eine Liste der Richtlinien/Konfigurationen , die Apigee für die wichtigsten OWASP-Bedrohungen für REST empfiehlt.

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

Beim Erstellen und Sichern von Webanwendungen gibt es viele Sicherheitsbedenken. OWASP hat die Liste der Top 10 der OWASP-Sicherheits bedrohungen von 2017 für Webanwendungen veröffentlicht. Webanwendungen bestehen aus vielen Teilen, aber die meisten modernen Webanwendungen basieren stark auf REST APIs. Apigee ist nicht dafür gedacht, alle Sicherheits anforderungen einer Webanwendung zu erfüllen, kann aber eine entscheidende Rolle bei der Sicherung der REST APIs spielen. Im Folgenden werden die wichtigsten OWASP-Sicherheitsbedrohungen beschrieben und wie Sie Apigee verwenden können, um diese Bedrohungen zu beheben.

A1:2017 – Injection

Um sich vor nicht vertrauenswürdigen Dateninjections wie SQL, NoSQL, LDAP und JavaScript zu schützen, die zur Ausführung unerwünschter 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 die eingehenden API-Anfragen fungiert, 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 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 Validierung per API-Schlüssel 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 Entwickleranwendung erstellt und genehmigt wird, die mit einem oder mehreren API Produkten verknüpft ist.

Der Begriff „API-Schlüssel“ kann manchmal unterschiedliche Bedeutungen haben. Wenn in Apigee die Beziehung zwischen Anwendung und Produkt hergestellt wird, generiert Apigee eine Client-ID und ein Client-Secret. Einige 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 werden „Consumer-Key“ und „Consumer-Secret“ angezeigt.

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

Apigee unterstützt auch den Import vorhandener API Schlüssel aus externen Quellen.

Bei OAuth-Zustimmungstypen werden sowohl die Client-ID als auch das Secret verwendet.

oauth 2.0

Das OAuth 2.0-Autorisierungsframework ermöglicht es einer Drittanbieteranwendung, eingeschränkten Zugriff auf einen HTTP-Dienst zu erhalten, entweder im Auftrag eines Ressourceninhabers, indem eine Genehmigungsinteraktion zwischen dem Ressourceninhaber und dem HTTP-Dienst orchestriert wird, oder durch Zulassen einer Drittanbieteranwendung, um Zugriff im eigenen Namen zu erhalten.

Mit den OAuth 2.0-Richtlinien von Apigee können Sie die vier OAuth 2.0-Berechtigungstypen implementieren und anpassen. Die Durchsetzung von OAuth-Zugriffstokens kann mit der OAuthv2-Richtlinie erfolgen. Der Consumer muss registriert sein und eine genehmigte Anwendung haben, die ihm Zugriff auf die API gewährt. Im Gegenzug erhält er eine API-Client-ID und ein Client-Secret. Der Consumer muss eine der OAuth-Berechtigungen durchlaufen, um authentifiziert zu werden. Dadurch 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 zum Freigeben von Anforderungen oder Assertions für verbundene Anwendungen verwendet. Apigee bietet JWT-Unterstützung mit drei Richtlinien.

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

A3:2017 – Offenlegung sensibler Daten

Angreifer zielen auf sensible Daten wie Kreditkartendetails, Sozialversicherungsnummern, Anmeldedaten, personenbezogene Daten und Steuernummern ab, um Identitätsdiebstahl, Geldraub, Betrug und andere Straftaten zu begehen. Webanwendungen müssen sowohl im Ruhezustand als auch bei der Übertragung Verschlüsselung und andere Strategien implementieren, um den Schutz sensibler Daten zu gewährleisten.

TLS (Transport Layer Security, dessen Vorgänger SSL ist) ist die Standard-Sicherheitstechnologie zum Einrichten einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer App. Apigee unterstützt sowohl One-Way- als auch Two-Way-TLS.

Northbound TLS (Client, der sich mit der API als Server verbindet) wird durch die Verwendung von einer Konfiguration für virtuelle Hosts unterstützt. Ein virtueller Host kann für One-Way- oder Two-Way-TLS konfiguriert werden.

Southbound TLS (Apigee als Client, der sich mit dem Backend-Dienst verbindet) wird durch die Verwendung einer Zielserver Konfiguration unterstützt. Ein Zielserver kann für One-Way- oder Two-Way-TLS konfiguriert werden.

Apigee unterstützt viele TLS Konfigurationsoptionen.

Two-Way-TLS-Durchsetzung stellt sicher, dass der Client ein Zertifikat verwendet, das bereits in Apigee eingebunden wurde. OWASP bietet auch Best Practices für TLS.

In Apigee Hybrid ist TLS über den Ingress über einen Hostalias verfügbar, der ein ähnliches Konzept wie ein virtueller Host ist.

Im Folgenden finden Sie Richtlinien zum Sichern sensibler Daten:

  • Verwenden Sie eine Plattform, die One-Way- und Two-Way-TLS unterstützt, um auf Protokollebene zu schützen.
  • Verwenden Sie Richtlinien wie die AssignMessage-Richtlinie und 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 Datenmaskierung-Einstellungen, um sensible Daten im Edge Trace-Tool zu maskieren.
  • Achten Sie darauf, keine sensiblen Daten im Cache zu speichern. Verschlüsseln Sie sensible Daten, die im Cache gespeichert sind . In Edge können Sie sensible Daten im Ruhezustand 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 – Referenzen 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, z. B. Denial of Service.

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. Die integrierte XMLThreatProtection-Richtlinie schützt vor schädlichen XML-Nutzlasten.

A5:2017 – Fehlerhafte Zugriffssteuerung

Nachdem sich Nutzer angemeldet und Zugriff auf ein System erhalten haben, müssen geeignete Autorisierungskontrollen vorhanden sein damit Nutzer nur das sehen und tun können, was ihnen erlaubt ist. Ohne starke Zugriffskontrollen, können Angreifer unbefugt auf oft sensible Daten zugreifen oder Daten und das Systemverhalten böswillig manipulieren.

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

Zugriffskontrollen für die Edge-Benutzeroberfläche

Zugriffskontrollen für das Apigee-Entwicklerportal

  • Konfigurieren Sie die Einmalanmeldung (SSO) mit dem Identitätsanbieter Ihres Unternehmens.
  • Konfigurieren Sie die rollenbasierte Zugriffssteuerung , 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.

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

  • Der Zugriff auf APIs kann über API-Schlüssel, OAuth-Tokens, OAuth-Bereiche, Zertifikate, und andere Techniken erzwungen werden.
  • Der API-Anbieter konfiguriert, welche Ressourcen verfügbar sind, indem er ein API-Produkt definiert. Der Zugriff wird entweder manuell in der Benutzeroberfläche, über die Management API oder über das Entwicklerportal gewährt. Wenn der Anwendung eines Entwicklers Zugriff auf ein API-Produkt gewährt wird, erhält er eine Client-ID und ein Secret, die im Authentifizierungsprozess verwendet werden.
  • Apigee kann in jeden Identitätsanbieter eingebunden werden, um OAuth durchzufü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 – Sicherheitsfehlkonfiguration

Sicherheitsfehlkonfigurationen werden leicht übersehen, oft weil Administratoren und Entwickler fälschlicherweise davon ausgehen, dass die von ihnen verwendeten Systeme von Natur aus sicher sind. Eine Sicherheitsfehlkonfiguration kann auf viele verschiedene Arten erfolgen, z. B. durch das Vertrauen in Standardkonfigurationen oder 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 freigegebener 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 oder noch einen Schritt weiter gehen und freigegebene Abläufe in Ablauf-Hooks platzieren, um für jeden in derselben Umgebung wie ein freigegebener Ablauf bereitgestellten API-Proxy automatisch eine freigegebene Ablauflogik auszuführen.

Apigee-Produktversionen bieten Schutz vor Bibliotheken mit Sicherheitslücken. Apigee veröffentlicht möglicherweise zusätzliche Patches oder Updates, wenn neue Sicherheitslücken gefunden werden. Die öffentliche Cloud von Edge wird automatisch gepatcht. Kunden von Edge for Private Cloud (lokal) müssen Produktpatches selbst anwenden.

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

Mit Cross-Site-Scripting (XSS) können Angreifer Skripts in Nutzer-Webbrowsern ausführen, um Nutzer Sitzungen zu steuern, Websites zu bearbeiten oder Nutzer auf andere Weise zu schädigen. XSS-Probleme sind nicht unbedingt mit APIs verbunden, aber Apigee bietet Richtlinien zum Schutz vor Bedrohungen, die genutzt werden können, um die API vor XSS zu schützen. 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, eine der häufig implementierten Lösungen für die Same-Origin-Richtlinie, die von allen Browsern durchgesetzt wird, kann mit 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 RCE-Angriffen (Remote Code Execution) führen.

Apigee empfiehlt keine Deserialisierung. Die Richtlinien JSONThreatProtection und RegularExpressionProtection können jedoch vor schädlichen JSON-Nutzlasten schützen. Mit der JavaScript-Richtlinie können Nutzlasten auch auf schädliche Inhalte gescannt werden. Der Cache und andere Richtlinien können verwendet werden, um sich vor Wiederholungsangriffen zu schützen. Auf Infrastrukturebene hat die Apigee-Plattform auch integrierte Schutzmaßnahmen, um laufende Prozesse zu schützen.

A9:2017 – Komponenten mit bekannten Sicherheitslücken verwenden

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

Die regelmäßigen Produktversionen von Apigee bieten Schutz vor Sicherheitslücken in Komponenten, insbesondere wenn bestimmte Sicherheitslücken entdeckt werden. Die öffentliche Cloud von Apigee wird automatisch gepatcht und Apigee benachrichtigt Kunden von Edge for Private Cloud, wenn lokale Patches zur Installation verfügbar sind.

A10:2017 – Unzureichendes Logging und Monitoring

Wenn Sie in Ihren Systemen kein ausreichendes Logging, Monitoring und Vorfallmanagement 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

Fehlerbehandlung

Apigee bietet einen leistungsstarken, vielseitigen Fehler behandlungsmechanismus für API-Proxys. Ähnlich wie ein Java-Programm Ausnahmen abfangen kann, API-Proxys können 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 verfügbar über die Benutzeroberfläche oder über die Audits API.

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

Als OWASP die Liste für 2017 aktualisierte, wurden einige Sicherheitslücken aus der Liste von 2013 entfernt. Sie stellen jedoch weiterhin gültige Bedrohungen dar. In den folgenden Abschnitten wird beschrieben, wie Sie diese Bedrohungen mit Apigee beheben.

A8:2013 – Websiteübergreifende Anfragefälschung (CSRF, Cross-Site Request Forgery)

Bei websiteübergreifenden Anfragen zur Fälschung können Angreifer die Authentifizierungsdetails, das Sitzungscookie, und andere Daten eines Nutzers über HTTP an eine anfällige Webanwendung weiterleiten. So wird die Webanwendung dazu gebracht, zu glauben, dass die Anfragen legitime Anfragen des Nutzers sind.

Richtlinien:

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

A10:2013 – Nicht validierte Weiterleitungen

Wenn eine Webanwendung Weiterleitungen ausführt, aber nicht validiert, dass Weiterleitungen Nutzer zu vertrauenswürdigen, beabsichtigten Websites senden, können Angreifer Nutzer zu schädlichen Zielen senden, um Phishing, Malware-Ausführung und andere Angriffe durchzuführen.

Richtlinien:

  • Verwenden Sie OAuth und erzwingen Sie die Validierung bei jeder Anfrage.
  • Verhindern Sie unerwartete 302-Weiterleitungen, indem Sie in der API-Proxy-Logik nach Antwortcodes suchen und Weiterleitungen entsprechend verarbeiten.