So beheben Sie Web-Schwachstellen mit dem Apache APISIX API Gateway

Das Open Worldwide Application Security Project ist eine Online-Community, die frei verfügbare Artikel, Methoden, Dokumentationen, Tools und Technologien in den Bereichen IoT, Systemsoftware und Webanwendungssicherheit produziert. Das OWASP stellt kostenlose und offene Ressourcen zur Verfügung. Es wird von einer gemeinnützigen Organisation namens The OWASP Foundation geleitet. Die OWASP Top 10 – 2021 sind das veröffentlichte Ergebnis einer aktuellen Forschung, die auf umfassenden Daten von über 40 Partnerorganisationen basiert.

-- OWASP-Website

Das OWASP veröffentlicht regelmäßig einen Top-10-Schwachstellenbericht. Der Bericht zielt auf Schwachstellen in Webanwendungen ab.

In diesem Beitrag möchte ich beschreiben, wie man einige davon über das Apache APISIX API Gateway beheben kann.

Die OWASP Top 10 2021

Im Jahr 2021 erwähnt der Bericht:

• A01:2021 – Zugangskontrolle defekt
• A02:2021 – Kryptografische Fehler
• A03:2021 – Injektion
• A04:2021 – Unsicher
• A05:2021 – Fehlkonfiguration der Sicherheit
• A06:2021 – Anfällige und veraltete Komponenten
• A07:2021 – Identifikations- und Authentifizierungsfehler
• A08:2021 – Software- und Datenintegritätsfehler
• A09:2021 – Fehler bei der Sicherheitsprotokollierung und -überwachung
• A10:2021-Serverseitige Anforderungsfälschung

Weitere Einzelheiten finden Sie im vollständigen Bericht .

Die Behebung einer Schwachstelle hängt von ihrer genauen Art ab. Das Reparieren anfälliger und veralteter Komponenten ist beispielsweise prozessgesteuert und erfordert Disziplin bei der Verwaltung von Versionen und der Außerbetriebnahme älterer Komponenten. Einige sind jedoch technischer Natur und erfordern lediglich eine ordnungsgemäße Konfiguration im Reverse-Proxy oder API-Gateway, z . B. Server Side Request Forgery .

Niemand kümmert sich um Sicherheit

Sicherheit ist ein heikles Thema, da die Stärkung der Sicherheit keinen Mehrwert für das Unternehmen bringt. Karriereorientierte Manager werden sich nicht um Sicherheit kümmern, da sie bei ihrer nächsten jährlichen Bewertung nicht nachweisen können, dass sie den Gewinn des Unternehmens um X % gesteigert haben. Wenn der Vorstand die Sicherheit nicht ernst nimmt, wird es wahrscheinlich niemanden interessieren. Aus diesem Grund implementieren die meisten Unternehmen Kontrollkästchen-basierte Sicherheit, auch bekannt als plausible Leugnung. Wenn Sie daran interessiert sind, Sicherheit richtig zu implementieren, habe ich in einem früheren Blogbeitrag einige Gedanken dazu niedergeschrieben: Behandeln Sie Sicherheit als Risiko .

Alles in allem wird die Sicherung von Anwendungen, wenn überhaupt, nicht viel Budget erfordern. Daher müssen wir klug vorgehen und nach einer vorhandenen Komponente suchen. Glücklicherweise bietet der OWASP eine sofort einsatzbereite Konfiguration zur Handhabung der Top 10, die über eine Konfiguration namens „Core Rule Set“ behoben werden kann. Leider zielt es auf ModSecurity ab:

ModSecurity, manchmal auch Modsec genannt, ist eine Open-Source-Webanwendungs-Firewall (WAF). Ursprünglich als Modul für den Apache HTTP Server konzipiert, hat es sich weiterentwickelt und bietet eine Reihe von Hypertext Transfer Protocol-Anforderungs- und Antwortfilterfunktionen sowie andere Sicherheitsfunktionen für eine Reihe verschiedener Plattformen, darunter Apache HTTP Server, Microsoft IIS und Nginx. Es handelt sich um freie Software, die unter der Apache-Lizenz 2.0 veröffentlicht wird.

– ModSecurity auf Wikipedia

Während es theoretisch möglich ist, Nnginx über die Apache APISIX-Konfiguration zu konfigurieren, gibt es eine andere, einfachere Möglichkeit.

Der OWASP-Kernregelsatz und Coraza

Die Beschreibung des Kernregelsatzes ist für unsere Bedürfnisse ziemlich relevant:

Das OWASP® ModSecurity Core Rule Set (CRS) ist ein Satz generischer Regeln zur Angriffserkennung zur Verwendung mit ModSecurity oder kompatiblen Webanwendungs-Firewalls. Ziel des CRS ist es, Webanwendungen mit einem Minimum an Fehlalarmen vor einer Vielzahl von Angriffen, einschließlich der OWASP Top Ten, zu schützen. Das CRS bietet Schutz vor vielen gängigen Angriffskategorien, darunter:

• SQL-Injection (SQLi)
• Cross-Site-Scripting (XSS)
• Lokale Dateieinbindung (LFI)
• Remote File Inclusion (RFI)
• PHP-Code-Injection
• Java-Code-Injection
• HTTPoxy
• Neurose
• Unix/Windows-Shell-Injection
• Sitzungsfixierung
• Scripting/Scanner/Bot-Erkennung
• Metadaten-/Fehlerlecks

– OWASP® ModSecurity Core Rule Set-Website

OWASP stellt außerdem Coraza bereit, eine Portierung von ModSecurity, die als Go-Bibliothek verfügbar ist. Coraza Proxy Wasm basiert auf Coraza und implementiert die Proxy-Wasm-ABI , die eine Reihe von Wasm-Schnittstellen für Proxys angibt. Schließlich bietet Apache APISIX eine Proxy-WasM-Integration.

Alles zusammenfügen

Fassen wir zusammen:

1. Das OWASP stellt eine Liste der zehn größten Sicherheitslücken im Internet bereit
2. Es implementiert sie für ModSecurity über den Core Ruleset
3. Coraza ist eine Portierung von ModSecurity, verfügbar als Proxy-Wasm-Implementierung

Auf diese Weise können wir Apache APISIX mit vernünftigen und sicheren Standardeinstellungen konfigurieren. Lass es uns tun.

Das Wichtigste zuerst: Coraza ist nicht Teil der Apache APISIX-Distribution. Es ist jedoch ganz einfach, es hier mit Docker hinzuzufügen:

 FROM apache/apisix:3.8.0-debian ENV VERSION 0.5.0 #1 ENV CORAZA_FILENAME coraza-proxy-wasm-${VERSION}.zip #1 ADD https://github.com/corazawaf/coraza-proxy-wasm/releases/download/$VERSION/$CORAZA_FILENAME . #2 USER root #3 RUN <<EOF apt-get install zip -y #4 unzip $CORAZA_FILENAME -d /usr/local/apisix/proxywasm rm $CORAZA_FILENAME apt-get remove zip -y chown -R apisix:apisix /usr/local/apisix/proxywasm EOF USER apisix #5

1. Definieren Sie Variablen für eine bessere Wartbarkeit
2. Holen Sie sich die Coraza Wasm-Veröffentlichung
3. In neueren APISIX-Versionen ist der Benutzer apisix , um die Sicherheit zu erhöhen. Da wir Pakete installieren müssen, müssen wir zu root wechseln.
4. Installieren Sie unzip , da es nicht installiert ist, entpacken Sie das heruntergeladene Archiv, entfernen Sie das Archiv, deinstallieren Sie unzip und ändern Sie den Besitzer des extrahierten Ordners
5. Wechseln Sie zurück zum Benutzer apisix

Der nächste Schritt besteht darin, APISIX selbst für die Verwendung des Coraza Wasm-Plugins zu konfigurieren.

 wasm: plugins: - name: coraza-filter #1 priority: 7999 #2 file: /usr/local/apisix/proxywasm/coraza-proxy-wasm.wasm #3

1. Der im Wasm-Code festgelegte Name des Filters
2. Legen Sie die höchste Priorität fest, damit es vor allen anderen Plugins ausgeführt wird
3. Pfad zur extrahierten Datei, siehe Dockerfile oben

Schließlich können wir das Plugin Routen zuweisen oder es als globale Regel festlegen, die auf jede Route angewendet wird. Ich verwende eine statische Konfiguration:

 global_rules: - id: 1 plugins: coraza-filter: #1 conf: directives_map: #2 default: - SecDebugLogLevel 9 #3 - SecRuleEngine On #4 - Include @crs-setup-conf #5 - Include @owasp_crs/*.conf #6 default_directives: default #7

1. Konfigurieren Sie das coraza-filter -Plugin jetzt, da es verfügbar ist
2. Definieren Sie Konfigurationen. Hier definieren wir einen einzigen, default , aber wir könnten auch mehrere definieren und unterschiedliche auf unterschiedlichen Routen verwenden
3. Erhöhen Sie die Protokollebene, um zu sehen, was in den Protokollen passiert
4. Schalten Sie den Motor ein
5. Verwenden Sie das Coraza-Setup
6. Benutzen Sie alle Regeln. Für eine detailliertere Kontrolle könnten wir die gewünschten auswählen
7. Verwenden Sie die oben definierte default

Wir definieren weiterhin Routen zu https://httpbin.org/ , um unser Setup zu testen. Rufen wir die Route zu /get auf:

 curl localhost:9080?user=foobar

Die Antwort ist wie erwartet:

 { "args": { "user": "foobar" }, "headers": { "Accept": "*/*", "Host": "localhost", "User-Agent": "curl/8.4.0", "X-Amzn-Trace-Id": "Root=1-65b9fa13-75900dc029e156ec764ae204", "X-Forwarded-Host": "localhost" }, "origin": "192.168.65.1, 176.153.7.175", "url": "http://localhost/get?user=foobar" }

Versuchen wir nun, JavaScript in der Abfragezeichenfolge zu senden. Diese Anfrage wird auf keinen Fall serverseitig erwartet, daher sollte uns unsere Infrastruktur davor schützen.

 curl 'localhost:9080?user=<script>alert(1)</script>'

Die Antwort ist ein 403-HTTP-Statuscode. Wenn wir uns das Protokoll ansehen, können wir die folgenden Hinweise sehen:

 Coraza: Warning. XSS Attack Detected via libinjection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection Coraza: Warning. Javascript method detected Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1

Coraza hat den Job gemacht!

Abschluss

Die meisten Organisationen bieten keine Anreize für Sicherheit. Daher müssen wir klug vorgehen und vorhandene Komponenten so weit wie möglich nutzen.

Mit Coraza und dem Core Ruleset können wir Apache APISIX gegenüber den OWASP Top 10 absichern.

Um weiter zu gehen:

• OWASP-Sicherheit Top 10
• OWASP ModSecurity Core-Regelsatz
• OWASP Coraza WAF
• APISIX – Integration mit Coraza

Den vollständigen Quellcode für diesen Beitrag finden Sie auf GitHub .

Ursprünglich veröffentlicht bei A Java Geek am 4. Februar 2024