NGINX-Tutorial: Kubernetes-Apps vor SQL-Injection schützen

NGINX | 22. März 2022

Dieses Tutorial ist eines von vier Tutorials, in denen Konzepte aus „Microservices März 2022: Kubernetes-Netzwerke“ praktisch umgesetzt werden:

Kubernetes-Latenz durch automatische Skalierung reduzieren
Kubernetes-APIs mit Ratenbegrenzung schützen
Kubernetes-Apps vor SQL-Injection schützen (dieser Beitrag)
Verbessern Sie Verfügbarkeit und Ausfallsicherheit mit einem Canary-Deployment

Sie wünschen eine ausführliche Anleitung zur Verwendung von NGINX für noch mehr Kubernetes-Netzwerk-Anwendungsfälle? Laden Sie unser kostenloses E-Book herunter: „Kubernetes-Datenverkehr mit NGINX verwalten: Ein Praxisleitfaden“.

Sie arbeiten in der IT-Abteilung eines beliebten lokalen Geschäfts, das eine Vielzahl von Waren verkauft – von Kissen bis hin zu Fahrrädern. Das Geschäft steht kurz vor der Eröffnung seines ersten Onlineshops, hat jedoch zuvor einen Sicherheitsexperten damit beauftragt, die Website einem Penetrationstest zu unterziehen bevor sie öffentlich zugänglich gemacht wird. Leider hat der Sicherheitsexperte ein Problem entdeckt: Der Onlineshop ist anfällig für SQL-Injection-Angriffe. Dem Sicherheitsexperten gelang es, diese Schwachstelle auszunutzen und vertrauliche Informationen aus Ihrer Datenbank abzurufen, darunter Benutzernamen und Passwörter.

Dein Team hat sich an dich – den Kubernetes-Engineer – gewandt, um die Situation zu retten. Zum Glück weißt du, dass sich SQL-Injection (wie auch andere Sicherheitslücken) mithilfe von Kubernetes-Tools zur Datenverkehrsverwaltung eindämmen lässt. Du hast bereits einen Ingress-Controller bereitgestellt, um die App zugänglich zu machen, und kannst mit einer einzigen Konfiguration sicherstellen, dass die Sicherheitslücke nicht ausgenutzt werden kann. Nun kann der Onlineshop pünktlich an den Start gehen. Gut gemacht!

Übersicht über das Lab und das Tutorial

Dieser Blog begleitet das Lab zu Einheit 3 des Microservices March 2022 – „Sicherheitsmuster für Microservices in Kubernetes“ und zeigt, wie sich SQL-Injection-Angriffe mit NGINX und dem NGINX Ingress Controller blockieren lassen.

Um das Tutorial durchzuführen, benötigen Sie einen Rechner mit:

2 CPUs oder mehr
2 GB freier Arbeitsspeicher
20 GB freier Speicherplatz
Internetverbindung
Container- oder VM-Manager wie Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox oder VMware Fusion/Workstation
minikube installiert
Helm installiert
Eine Konfiguration, mit der Sie ein Browserfenster öffnen können. Falls das nicht möglich ist, müssen Sie herausfinden, wie Sie über einen Browser auf die entsprechenden Dienste zugreifen können.

Damit Sie das Labor und das Tutorial optimal nutzen können, empfehlen wir Ihnen, vor Beginn Folgendes zu tun:

Sehen Sie sich die Aufzeichnung des live gestreamten konzeptionellen Überblicks an
Lesen Sie die Hintergrund-Blogbeiträge und sehen Sie sich das Webinar und das Video an
Sehen Sie sich die 16-minütige Videozusammenfassung des Labs an:

&amp;amp;amp;amp;amp;amp;nbsp;

In diesem Tutorial werden folgende Technologien verwendet:

NGINX Open Source
NGINX Ingress Controller (basierend auf NGINX Open Source)
BusyBox
Helm
minikube
Eine einfache App mit Sicherheitslücken, die für dieses Lab entwickelt wurde

Die Anleitungen für jede Aufgabe enthalten den vollständigen Text der YAML-Dateien, die zur Konfiguration der Apps verwendet werden. Sie können den Text auch aus unserem GitHub-Repository kopieren. Neben dem Text jeder YAML-Datei finden Sie einen Link zu GitHub.

Dieses Tutorial umfasst vier Aufgaben:

Cluster und anfällige App bereitstellen
App hacken
Einen NGINX-Sidecar-Container verwenden, um bestimmte Anfragen zu blockieren
NGINX Ingress Controller zum Filtern von Anfragen konfigurieren

Aufgabe 1: Cluster und anfällige Anwendung bereitstellen

In dieser Aufgabe stellen Sie einen Minikube-Cluster bereit und installieren Podinfo als Beispielanwendung mit Sicherheitslücken.

Minikube-Cluster erstellen

Stellen Sie einen minikube-Cluster bereit. Nach einigen Sekunden bestätigt eine Meldung, dass die Bereitstellung erfolgreich war.

$ minikube start 
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Installieren Sie die anfällige Anwendung

Hier stellen Sie eine einfache E-Commerce-Anwendung bereit, die aus zwei Microservices besteht:

Eine MariaDB-Datenbank
Ein PHP-Microservice, der eine Verbindung zur Datenbank herstellt und Daten abruft

Führen Sie die folgenden Schritte aus:

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens „1-app.yaml“ mit folgendem Inhalt (oder kopieren Sie sie von GitHub).

apiVersion: apps/v1 kind: Deployment 
metadata: 
  name: app 
spec: 
  selector: 
    matchLabels: 
      app: app 
  template: 
    metadata: 
      labels: 
        app: app 
    spec: 
      containers: 
        - name: app 
          image: f5devcentral/microservicesmarch:1.0.3 
          ports: 
            - containerPort: 80 
          env: 
            - name: MYSQL_USER 
              value: dan 
            - name: MYSQL_PASSWORD 
              value: dan 
            - name: MYSQL_DATABASE 
              value: sqlitraining 
            - name: DATABASE_HOSTNAME 
              value: db.default.svc.cluster.local 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: app 
spec: 
  ports: 
    - port: 80 
      targetPort: 80 
      nodePort: 30001 
  selector: 
    app: app 
  type: NodePort 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: db 
spec: 
  selector: 
    matchLabels: 
      app: db 
  template: 
    metadata: 
      labels: 
        app: db 
    spec: 
      containers: 
        - name: db 
          image: mariadb:10.3.32-focal 
          ports: 
            - containerPort: 3306 
          env: 
            - name: MYSQL_ROOT_PASSWORD 
              value: root 
            - name: MYSQL_USER 
              value: dan 
            - name: MYSQL_PASSWORD 
              value: dan 
            - name: MYSQL_DATABASE 
              value: sqlitraining 

--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: db 
spec: 
  ports: 
    - port: 3306 
      targetPort: 3306 
  selector: 
    app: db

Stellen Sie die App und die API bereit:

$ kubectl apply -f 1-app.yaml deployment.apps/app created 
service/app created 
deployment.apps/db created 
service/db created

Vergewissern Sie sich, dass die Podinfo-Pods bereitgestellt wurden. Dies erkennen Sie am Wert Running in der Spalte STATUS. Die vollständige Bereitstellung kann 30–40 Sekunden dauern. Warten Sie daher, bis der Status beider Pods Running lautet, bevor Sie mit dem nächsten Schritt fortfahren (führen Sie den Befehl bei Bedarf erneut aus).

$ kubectl get podsNAME                  READY   STATUS    RESTARTS   AGE 
app-d65d9b879-b65f2   1/1     Running   0          37s 
db-7bbcdc75c-q2kt5    1/1     Running   0          37s

Öffnen Sie die App in Ihrem Browser:

$ minikube service app|-----------|------|-------------|--------------| 
| NAMESPACE | NAME | TARGET PORT |     URL      | 
|-----------|------|-------------|--------------| 
| default   | app  |             | No node port | 
|-----------|------|-------------|--------------| 
😿  service default/app has no node port 
🏃  Starting tunnel for service app. 
|-----------|------|-------------|------------------------| 
| NAMESPACE | NAME | TARGET PORT |          URL           | 
|-----------|------|-------------|------------------------| 
| default   | app  |             | http://127.0.0.1:55446 | 
|-----------|------|-------------|------------------------| 
🎉  Opening service default/app in default browser...

Challenge 2: Hacke die App

Die Beispielanwendung ist recht einfach aufgebaut. Sie umfasst eine Startseite mit einer Liste von Artikeln (zum Beispiel Kissen) sowie mehrere Produktseiten mit Details wie einer Beschreibung und dem Preis. Die Daten werden in der MariaDB-Datenbank gespeichert. Bei jedem Seitenaufruf wird eine SQL-Abfrage an die Datenbank gesendet.

Für die Startseite werden alle Einträge aus der Datenbank abgerufen.
Für eine Produktseite wird das Element anhand seiner ID abgerufen.

Wenn Sie die Produktseite für „Kissen“ öffnen, fällt Ihnen möglicherweise auf, dass die URL auf „/product/1“ endet. Die „1“ ist die ID des Produkts. Um zu verhindern, dass Schadcode direkt in die SQL-Abfrage eingefügt wird, sollten Benutzereingaben bereinigt werden, bevor Anfragen an Backend-Dienste weitergeleitet werden. Doch was passiert, wenn die App nicht richtig konfiguriert ist und die Eingabe nicht maskiert wird, bevor sie in die SQL-Abfrage an die Datenbank eingefügt wird?

Exploit 1

Um herauszufinden, ob die App Eingaben ordnungsgemäß maskiert, führen Sie ein einfaches Experiment durch: Ändern Sie die ID in eine ID, die nicht in der Datenbank vorhanden ist.

Ändern Sie das letzte Element in der URL manuell von 1 in -1. Die Fehlermeldung Invalid product id "-1" weist darauf hin, dass die Produkt-ID nicht maskiert wird – stattdessen wird die Zeichenfolge direkt in die Abfrage eingefügt. Das ist nur gut, wenn Sie ein Hacker sind!

Nehmen wir an, die Datenbankabfrage sieht etwa so aus:

SELECT * FROM some_table WHERE id = "1"

Um die durch die fehlende Maskierung der Eingabe verursachte Schwachstelle auszunutzen, ersetzen Sie 1 durch -1" <malicious_query> -- //, sodass Folgendes entsteht:

Das Anführungszeichen (") nach -1 schließt die erste Abfrage ab.
Nach dem Anführungszeichen können Sie Ihre eigene bösartige Abfrage hinzufügen.
Die Sequenz -- // verwirft den Rest der Abfrage.

Wenn Sie also beispielsweise das letzte Element in der URL in ‑1" oder 1 -- // ändern, wird die Abfrage wie folgt kompiliert:

SELECT * FROM some_table WHERE id = "-1" OR 1 -- //" 
                                     -------------- 
                                     ^ injected ^

Dadurch werden alle Zeilen aus der Datenbank ausgewählt, was bei einem Hack nützlich ist. Um herauszufinden, ob dies der Fall ist, ändern Sie das Ende der URL in ‑1". Die daraufhin angezeigte Fehlermeldung liefert Ihnen weitere nützliche Informationen über die Datenbank:

Fatal error: Uncaught mysqli_sql_exception: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"-1""' at line 1 in /var/www/html/product.php:23 Stack trace: #0 /var/www/html/product.php(23): mysqli->query('SELECT * FROM p...') #1 {main} thrown in /var/www/html/product.php on line 23

Nun können Sie damit beginnen, den eingeschleusten Code zu manipulieren, um zu versuchen, die Datenbankergebnisse nach ID zu sortieren:

-1" OR 1 ORDER BY id DESC -- //

Das Ergebnis ist die Produktseite für den letzten Eintrag in der Datenbank.

Exploit 2

Die Datenbank dazu zu zwingen, die Ergebnisse zu sortieren, ist zwar interessant, aber nicht besonders nützlich, wenn Ihr Ziel das Hacken ist. Der Versuch, Benutzernamen und Passwörter aus der Datenbank auszulesen, lohnt sich deutlich mehr.

Man kann davon ausgehen, dass es in der Datenbank eine Benutzertabelle mit Benutzernamen und Passwörtern gibt. Aber wie lässt sich der Zugriff von der Produkttabelle auf die Benutzertabelle ausweiten?

Die Lösung besteht darin, Code wie diesen einzuschleusen:

-1" UNION SELECT * FROM users -- //

wobei

‑1" erzwingt, dass die erste Abfrage eine leere Ergebnismenge zurückgibt.
UNION führt zwei Datenbanktabellen zusammen – in diesem Fall products und users –, sodass Sie Informationen (Passwörter) abrufen können, die nicht in der ursprünglichen Tabelle (products) enthalten sind.
SELECT * FROM users wählt alle Zeilen in der Tabelle users aus.
Die Sequenz „-- //“ verwirft alles, was nach der schädlichen Abfrage folgt.

Wenn Sie die URL so ändern, dass sie mit dem eingeschleusten Code endet, erhalten Sie eine neue Fehlermeldung:

Fatal error: Uncaught mysqli_sql_exception: The used SELECT statements have a different number of columns in /var/www/html/product.php:23 Stack trace: #0 /var/www/html/product.php(23): mysqli->query('SELECT * FROM p...') #1 {main} thrown in /var/www/html/product.php on line 23

Diese Meldung zeigt, dass die Tabellen products und users nicht dieselbe Anzahl an Spalten haben, sodass die Anweisung UNION nicht ausgeführt werden kann. Sie können die Anzahl der Spalten jedoch durch Ausprobieren ermitteln, indem Sie der Anweisung SELECT nacheinander einzelne Spalten (Feldnamen) als Parameter hinzufügen. Eine naheliegende Vermutung für einen Feldnamen in einer users-Tabelle ist password. Probieren Sie es also damit:

# select 1 column-1" UNION SELECT password FROM users; -- //
# select 2 columns 
-1" UNION SELECT password,password FROM users; -- //
# select 3 columns 
-1" UNION SELECT password,password,password FROM users; -- /
# select 4 columns 
-1" UNION SELECT password,password,password,password FROM users; -- //
# select 5 columns
-1" UNION SELECT password,password,password,password,password FROM users; -- //

Die letzte Abfrage ist erfolgreich (woraus Sie schließen können, dass die Tabelle users fünf Spalten enthält), und Sie sehen das Passwort eines Benutzers:

Zu diesem Zeitpunkt kennen Sie den Benutzernamen, der zu diesem Passwort gehört, noch nicht. Da Sie jedoch die Anzahl der Spalten in der Tabelle users kennen, können Sie dieselben Abfragetypen wie zuvor verwenden, um diese Information offenzulegen. Nehmen Sie an, dass der Name des relevanten Feldes username lautet. Und das erweist sich als richtig – die folgende Abfrage legt sowohl den Benutzernamen als auch das Passwort aus der Tabelle users offen. Das ist großartig – es sei denn, diese App wird auf Ihrer Infrastruktur gehostet!

-1" UNION SELECT username,username,password,password,username FROM users where id=1 -- //

Aufgabe 3: Bestimmte Anfragen mit einem NGINX-Sidecar-Container blockieren

Der Entwickler der Onlineshop-App muss offensichtlich mehr darauf achten, Benutzereingaben zu bereinigen (beispielsweise durch die Verwendung parametrisierter Abfragen). Als Kubernetes-Engineer können Sie jedoch ebenfalls dazu beitragen, SQL-Injection-Angriffe zu verhindern, indem Sie dafür sorgen, dass sie die App gar nicht erst erreichen. Dadurch fällt es weniger ins Gewicht, dass die App anfällig ist.

Es gibt viele Möglichkeiten, Ihre Apps zu schützen. Im weiteren Verlauf dieses Labs konzentrieren wir uns auf zwei davon:

In dieser Aufgabe fügen Sie einen Sidecar-Container in den Pod ein, der den gesamten Datenverkehr über einen Proxy leitet und alle Anfragen ablehnt, deren URL UNION enthält. Zunächst stellen Sie NGINX Open Source als Sidecar bereit und anschließend testen Sie, ob bösartige Abfragen herausgefiltert werden. Hinweis: Wir verwenden diese Technik nur zur Veranschaulichung. In der Praxis ist die manuelle Bereitstellung von Proxys als Sidecars nicht die beste Lösung (dazu später mehr).
In Aufgabe 4 verwenden wir den NGINX Ingress Controller, um den gesamten eingehenden Datenverkehr des Clusters zu filtern.

NGINX Open Source als Sidecar bereitstellen

Erstellen Sie eine YAML-Datei namens „2-app-sidecar.yaml“ mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Wichtige Aspekte der Konfiguration sind:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: app 
spec: 
  selector: 
    matchLabels: 
      app: app 
  template: 
    metadata: 
      labels: 
        app: app 
    spec: 
      containers: 
        - name: app 
          image: f5devcentral/microservicesmarch:1.0.3 
          ports: 
            - containerPort: 80 
          env: 
            - name: MYSQL_USER 
              value: dan 
            - name: MYSQL_PASSWORD 
              value: dan 
            - name: MYSQL_DATABASE 
              value: sqlitraining 
            - name: DATABASE_HOSTNAME 
              value: db.default.svc.cluster.local 
        - name: proxy # <-- sidecar 
          image: "nginx" 
          ports: 
            - containerPort: 8080 
          volumeMounts: 
            - mountPath: /etc/nginx 
              name: nginx-config 
      volumes: 
        - name: nginx-config 
          configMap: 
            name: sidecar 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: app 
spec: 
  ports: 
    - port: 80 
      targetPort: 8080 # <-- the traffic is routed to the proxy 
      nodePort: 30001 
  selector: 
    app: app 
  type: NodePort 
--- 
apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: sidecar 
data: 
  nginx.conf: |- 
    events {} 
    http { 
      server { 
        listen 8080 default_server; 
        listen [::]:8080 default_server; 

        location ~* "(\'|\")(.*)(drop|insert|md5|select|union)" { 
            deny all; 
        } 

        location / { 
            proxy_pass http://localhost:80/; 
        } 
      } 
    } 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: db 
spec: 
  selector: 
    matchLabels: 
      app: db 
  template: 
    metadata: 
      labels: 
        app: db 
    spec: 
      containers: 
        - name: db 
          image: mariadb:10.3.32-focal 
          ports: 
            - containerPort: 3306 
          env: 
            - name: MYSQL_ROOT_PASSWORD 
              value: root 
            - name: MYSQL_USER 
              value: dan 
            - name: MYSQL_PASSWORD 
              value: dan 
            - name: MYSQL_DATABASE 
              value: sqlitraining 

--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: db 
spec: 
  ports: 
    - port: 3306 
      targetPort: 3306 
  selector: 
    app: db

Ein Sidecar-Container mit NGINX Open Source wird auf Port 8080 gestartet.
NGINX leitet den gesamten Datenverkehr an die App weiter.
Jede Anfrage, die (neben anderen Zeichenfolgen) SELECT oder UNION enthält, wird abgelehnt (siehe den ersten location-Block im Abschnitt ConfigMap).
Der Dienst für die App leitet den gesamten Datenverkehr zunächst an den NGINX-Container weiter.

Sidecar bereitstellen:

$ kubectl apply -f 2-app-sidecar.yaml deployment.apps/app configured 
service/app configured 
configmap/sidecar created 
deployment.apps/db unchanged 
service/db unchanged

Den Sidecar als Filter testen

Testen Sie, ob der Sidecar den Datenverkehr filtert, indem Sie zur App zurückkehren und die SQL-Injection erneut versuchen. NGINX blockiert die Anfrage, bevor sie die App erreicht!

-1" UNION SELECT username,username,password,password,username FROM users where id=1 -- //

Aufgabe 4: NGINX Ingress Controller zum Filtern von Anfragen konfigurieren

Ihre App wie in Aufgabe 3 zu schützen, ist als Lernerfahrung interessant, aber wir empfehlen dies aus folgenden Gründen nicht für den Produktivbetrieb:

Es handelt sich nicht um eine umfassende Sicherheitslösung.
Sie ist nicht skalierbar (dieser Schutz lässt sich nicht ohne Weiteres auf mehrere Apps anwenden).
Die Aktualisierung ist kompliziert und ineffizient.

Eine wesentlich bessere Lösung besteht darin, mit dem NGINX Ingress Controller denselben Schutz auf alle Ihre Anwendungen auszuweiten! Mit Ingress-Controllern lassen sich verschiedenste Sicherheitsfunktionen zentralisieren – vom Blockieren von Anfragen, wie es eine Web Application Firewall (WAF) tut, bis hin zur Authentifizierung und Autorisierung.

In dieser Aufgabe stellen Sie den NGINX Ingress Controller bereit, konfigurieren das Traffic-Routing, und überprüfen, ob der Filter die SQL-Injection blockiert.

NGINX Ingress Controller bereitstellen

Am schnellsten lässt sich der NGINX Ingress Controller mit Helm installieren.

Fügen Sie das NGINX-Repository zu Helm hinzu:

$ helm repo add nginx-stable https://helm.nginx.com/stable

Laden Sie den auf NGINX Open Source basierenden NGINX Ingress Controller herunter und installieren Sie ihn. Er wird von F5 NGINX gepflegt. Beachten Sie den Parameter enableSnippets=true: Mithilfe von Snippets wird NGINX so konfiguriert, dass die SQL-Injection blockiert wird. Die letzte Ausgabezeile bestätigt die erfolgreiche Installation.

$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 \ --set controller.enableSnippets=true
NAME: main  
LAST DEPLOYED: Day Mon DD hh:mm:ss YYYY  
NAMESPACE: default  
STATUS: deployed  
REVISION: 1  
TEST SUITE: None  
NOTES: The NGINX Ingress Controller has been installed.

Vergewissern Sie sich, dass der Pod des NGINX Ingress Controllers bereitgestellt wurde. Dies erkennen Sie am Wert Running in der Spalte STATUS.

$ kubectl get pods   NAME                                READY   STATUS  ...
main-nginx-ingress-779b74bb8b-mtdkr 1/1     Running ...

      ... RESTARTS   AGE 
      ... 0          18s

Datenverkehr an Ihre App weiterleiten

Erstellen Sie eine YAML-Datei namens 3-ingress.yaml mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Sie definiert das Ingress-Manifest, das erforderlich ist, um den Datenverkehr an die App weiterzuleiten (diesmal nicht über den Sidecar-Proxy). Beachten Sie den Block annotations:, in dem ein Snippet verwendet wird, um die Konfiguration des NGINX Ingress Controllers mit demselben location-Block wie in der ConfigMap-Definition in Challenge 3 anzupassen: Er lehnt jede Anfrage ab, die (neben anderen Zeichenfolgen) SELECT oder UNION enthält.

apiVersion: v1 kind: Service 
metadata: 
  name: app-without-sidecar 
spec: 
  ports: 
    - port: 80 
      targetPort: 80 
  selector: 
    app: app 
--- 
apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: entry 
  annotations: 
    nginx.org/server-snippets: | 
      location ~* "(\'|\")(.*)(drop|insert|md5|select|union)" { 
          deny all; 
      } 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: app-without-sidecar 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix

Stellen Sie die Ingress-Ressource bereit:

$ kubectl apply -f 3-ingress.yaml service/app-without-sidecar created 
ingress.networking.k8s.io/entry created

Filterfunktion überprüfen

Starten Sie einen temporären BusyBox-Container, um eine Anfrage mit dem korrekten Hostnamen an den Pod des NGINX Ingress Controllers zu senden.

$ kubectl run -ti --rm=true busybox --image=busybox$ wget --header="Host: example.com" -qO- main-nginx-ingress 
<!DOCTYPE html> 
<html lang="en"> 

<head> 
# ...

Versuchen Sie die SQL-Injection. Der Statuscode 403 Forbidden bestätigt, dass NGINX den Angriff blockiert!

$ wget --header="Host: example.com" -qO- 'main-nginx-ingress/product/-1"%20UNION%20SELECT%20username,username,password,password,username%20FROM%20users%20where%2 0id=1%20--%20//' 
wget: server returned error: HTTP/1.1 403 Forbidden

Nächste Schritte

Kubernetes ist standardmäßig nicht sicher. Ein Ingress-Controller kann Schwachstellen durch SQL-Injection (und viele andere Schwachstellen) eindämmen. Beachten Sie jedoch, dass die soeben mit dem NGINX Ingress Controller implementierte WAF-ähnliche Funktionalität weder eine echte WAF noch eine sichere Architektur von Anwendungen ersetzt. Ein versierter Hacker kann den UNION-Hack mit einigen kleinen Änderungen am Code dennoch zum Laufen bringen. Weitere Informationen zu diesem Thema finden Sie unter „Leitfaden für Penetrationstester zur SQL-Injection (SQLi)“.

Dennoch ist ein Ingress-Controller ein leistungsstarkes Werkzeug, mit dem Sie einen Großteil Ihrer Sicherheitsfunktionen zentralisieren und so Effizienz und Sicherheit steigern können. Dazu gehören Anwendungsfälle für die zentrale Authentifizierung und Autorisierung (mTLS, Single Sign-on) und sogar eine robuste WAF wie F5 NGINX App Protect WAF.

Die Komplexität Ihrer Anwendungen und Architektur erfordert möglicherweise eine präzisere Steuerung. Wenn Ihre Organisation Zero Trust und Ende-zu-Ende-Verschlüsselung benötigt, sollten Sie ein Service Mesh wie das dauerhaft kostenlose F5 NGINX Service Mesh in Betracht ziehen, um die Kommunikation zwischen Diensten im Kubernetes-Cluster (Ost-West-Datenverkehr) zu steuern. Service Meshes werden in Einheit 4, „Fortgeschrittene Strategien für Kubernetes-Bereitstellungen“, behandelt.

Weitere Informationen zum Bezug und zur Bereitstellung von NGINX Open Source finden Sie unter nginx.org.

Wenn Sie den auf NGINX Plus basierenden NGINX Ingress Controller mit NGINX App Protect testen möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Wenn Sie den auf NGINX Open Source basierenden NGINX Ingress Controller ausprobieren möchten, sehen Sie sich die NGINX Ingress Controller-Releases in unserem GitHub-Repository an oder laden Sie einen vorgefertigten Container von DockerHub herunter.