Comment remédier aux vulnérabilités Web avec Apache APISIX API Gateway

L'Open Worldwide Application Security Project est une communauté en ligne qui produit des articles, des méthodologies, de la documentation, des outils et des technologies disponibles gratuitement dans les domaines de l'IoT, des logiciels système et de la sécurité des applications Web. L'OWASP fournit des ressources gratuites et ouvertes. Il est dirigé par une organisation à but non lucratif appelée la Fondation OWASP. Le Top 10 de l'OWASP - 2021 est le résultat publié d'une recherche récente basée sur des données complètes compilées par plus de 40 organisations partenaires.

-- Site Internet de l'OWASP

L'OWASP publie régulièrement un rapport Top 10 des vulnérabilités. Le rapport cible les vulnérabilités des applications Web.

Dans cet article, j'aimerais décrire comment corriger certains d'entre eux via Apache APISIX API Gateway .

Le Top 10 OWASP 2021

En 2021, le rapport mentionne :

• A01 : 2021 – Contrôle d’accès cassé
• A02 : 2021 – Défaillances cryptographiques
• A03 : 2021-Injection
• A04 : 2021 – Non sécurisé
• A05 : 2021 – Mauvaise configuration de la sécurité
• A06 : 2021 – Composants vulnérables et obsolètes
• A07 : 2021-Échecs d’identification et d’authentification
• A08 : 2021 – Défaillances des logiciels et de l’intégrité des données
• A09 : 2021 – Échecs de journalisation et de surveillance de la sécurité
• A10 : 2021-Faux de requête côté serveur

Pour plus de détails, veuillez consulter le rapport complet.

La correction d'une vulnérabilité dépend de sa nature exacte. Par exemple, la réparation des composants vulnérables et obsolètes est régie par des processus, ce qui nécessite de la discipline dans la gestion des versions et le retrait des anciennes. Certains, cependant, sont techniques et nécessitent uniquement une configuration appropriée dans le proxy inverse ou la passerelle API, par exemple , Server Side Request Forgery .

Personne ne se soucie de la sécurité

La sécurité est un sujet délicat car le renforcement de la sécurité n'apporte aucune valeur à l'entreprise. Les managers axés sur la carrière ne se soucieront pas de la sécurité car ils ne pourront pas démontrer qu'ils ont augmenté les bénéfices de l'entreprise de X % lors de leur prochaine évaluation annuelle. À moins que le conseil d’administration ne prenne la sécurité au sérieux, il y a de fortes chances que personne ne s’en soucie. Pour cette raison, la plupart des organisations mettent en œuvre une sécurité basée sur des cases à cocher, c'est-à-dire un déni plausible. Si vous souhaitez mettre en œuvre correctement la sécurité, j'ai écrit quelques réflexions dans un article de blog précédent : Traitez la sécurité comme un risque .

Dans l’ensemble, la sécurisation des candidatures ne nécessitera pas beaucoup de budget, voire aucun. Par conséquent, nous devons être intelligents et rechercher un composant existant. Heureusement, l'OWASP propose une configuration prête à l'emploi pour gérer le Top 10, qui peut être corrigée via une configuration nommée Core Rule Set . Malheureusement, il cible ModSecurity :

ModSecurity, parfois appelé Modsec, est un pare-feu d'application Web (WAF) open source. Conçu à l'origine comme un module pour le serveur HTTP Apache, il a évolué pour fournir une gamme de fonctionnalités de filtrage des requêtes et des réponses du protocole de transfert hypertexte ainsi que d'autres fonctionnalités de sécurité sur un certain nombre de plates-formes différentes, notamment le serveur HTTP Apache, Microsoft IIS et Nginx. Il s'agit d'un logiciel libre publié sous la licence Apache 2.0.

-- ModSecurity sur Wikipédia

Bien qu'il soit théoriquement possible de configurer Nnginx via la configuration Apache APISIX, il existe un autre moyen plus simple.

L'ensemble de règles de base de l'OWASP et Coraza

La description de l'ensemble de règles de base est assez pertinente par rapport à nos besoins :

L'OWASP® ModSecurity Core Rule Set (CRS) est un ensemble de règles génériques de détection d'attaques à utiliser avec ModSecurity ou des pare-feu d'applications Web compatibles. Le CRS vise à protéger les applications Web contre un large éventail d'attaques, y compris le OWASP Top Ten, avec un minimum de fausses alertes. Le CRS offre une protection contre de nombreuses catégories d’attaques courantes, notamment :

• Injection SQL (SQLi)
• Scripts intersites (XSS)
• Inclusion de fichiers locaux (LFI)
• Inclusion de fichiers distants (RFI)
• Injection de code PHP
• Injection de code Java
• HTTPoxy
• Choc d'obus
• Injection de shell Unix/Windows
• Fixation de session
• Script/Scanner/Détection de robots
• Fuites de métadonnées/erreurs

-- Site Web de l'ensemble de règles de base OWASP® ModSecurity

OWASP fournit également Coraza , un portage de ModSecurity disponible sous forme de bibliothèque Go. Coraza Proxy Wasm est construit sur Coraza et implémente l' ABI proxy-wasm , qui spécifie un ensemble d'interfaces Wasm pour les proxys. Enfin, Apache APISIX propose une intégration proxy-wasm.

Mettre tous ensemble

Résumons :

1. L'OWASP fournit une liste des 10 principales vulnérabilités de sécurité Web
2. Il les implémente pour ModSecurity via le Core Ruleset
3. Coraza est un portage de ModSecurity, disponible en tant qu'implémentation proxy-wasm

Nous pouvons ainsi configurer Apache APISIX avec des valeurs par défaut saines et sécurisées. Faisons-le.

Tout d'abord : Coraza ne fait pas partie de la distribution Apache APISIX. Pourtant, il est simple de l'ajouter ici avec Docker :

 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. Définir des variables pour une meilleure maintenabilité
2. Obtenez la version Coraza Wasm
3. Dans les versions récentes d'APISIX, l'utilisateur est apisix pour renforcer la sécurité. Comme nous devons installer des packages, nous devons passer à root .
4. Installez unzip car il n'est pas installé, décompressez l'archive téléchargée, supprimez l'archive, désinstallez unzip et changez le propriétaire du dossier extrait
5. Revenir à l'utilisateur apisix

L'étape suivante consiste à configurer APISIX lui-même pour utiliser le plugin Coraza Wasm.

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

1. Nom du filtre défini dans le code Wasm
2. Définissez la priorité la plus élevée pour qu'il s'exécute avant tout autre plugin
3. Chemin d'accès au fichier extrait, voir le Dockerfile ci-dessus

Enfin, nous pouvons attribuer le plugin aux routes ou le définir comme règle globale à appliquer à chaque route. J'utilise une configuration statique :

 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. Configurez le plugin coraza-filter maintenant qu'il est disponible
2. Définir les configurations. Ici, nous en définissons un seul, default , mais nous pourrions en définir plusieurs et en utiliser différents dans différentes routes.
3. Augmentez le niveau de journalisation pour voir ce qui se passe dans les journaux
4. Allumer le moteur
5. Utiliser la configuration Coraza
6. Utilisez toutes les règles. Nous pourrions choisir ceux que nous voulons pour un contrôle plus précis
7. Utiliser la configuration default définie ci-dessus

Nous procédons à la définition de routes vers https://httpbin.org/ pour tester notre configuration. Appelons la route vers /get :

 curl localhost:9080?user=foobar

La réponse est celle attendue :

 { "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" }

Essayons maintenant d'envoyer du JavaScript dans la chaîne de requête. Il est impossible que cette requête soit attendue côté serveur, notre infrastructure devrait donc nous en protéger.

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

La réponse est un code d'état HTTP 403. Si nous regardons le journal, nous pouvons voir les indices suivants :

 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 a fait le travail !

Conclusion

La plupart des organisations n'encouragent pas la sécurité. Par conséquent, nous devons être intelligents et utiliser autant que possible les composants existants.

Nous pouvons renforcer Apache APISIX par rapport au Top 10 OWASP en utilisant Coraza et le Core Ruleset.

Pour aller plus loin:

• Top 10 de la sécurité OWASP
• Ensemble de règles de base OWASP ModSecurity
• OWASP Coraza WAF
• APISIX - Intégrer avec Coraza

Le code source complet de cet article peut être trouvé sur GitHub .

Publié initialement sur A Java Geek le 4 février 2024