Renforcement d’Apache APISIX avec Coraza et le jeu de règles principales de l’OWASP

Le Open Worldwide Application Security Project est une communauté en ligne qui produit des articles, des méthodologies, des documents, des outils et des technologies disponibles gratuitement dans les domaines de la sécurité des IoT, des logiciels système et des applications web. OWASP fournit des ressources gratuites et ouvertes. Elle est dirigée par une organisation à but non lucratif appelée The OWASP Foundation. Le OWASP Top 10 – 2021 est le résultat publié de recherches récentes basées sur des données complètes compilées auprès de plus de 40 organisations partenaires.

– Site web OWASP

OWASP publie régulièrement un rapport sur les 10 principales vulnérabilités. Le rapport vise les vulnérabilités dans les applications web.

Dans ce post, je souhaite décrire comment corriger certaines d’entre elles via le Gateway API Apache APISIX.

Le OWASP Top 10 2021

En 2021, le rapport mentionne:

A01:2021-Contrôle d’accès défectueux
A02:2021-Échecs cryptographiques
A03:2021-Injection
A04:2021-Insecure
A05:2021-Mauvaise configuration de sécurité
A06:2021-Composants vulnérables et obsolètes
A07:2021-Échecs d’identification et d’authentification
A08:2021-Échecs d’intégrité logicielle et de données
A09:2021-Échecs de journalisation et de surveillance de sécurité
A10:2021-Forage de requête côté serveur

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

La correction d’une vulnérabilité dépend de sa nature exacte. Par exemple, la correction de Composants vulnérables et obsolètes est axée sur les processus, nécessitant une discipline dans la gestion des versions et le retrait des plus anciennes. Certaines, cependant, sont techniques et nécessitent uniquement une configuration appropriée dans le proxy inverse ou le API Gateway, par exemple, Forgerie de requête côté serveur.

Personne ne se soucie de la sécurité

La sécurité est un sujet délicat car l’endurcissement de la sécurité n’apporte aucune valeur au business. Les managers tournés vers leur carrière ne se soucieront pas de la sécurité car ils ne pourront pas montrer qu’ils ont augmenté le profit de l’entreprise de X% lors de leur prochaine évaluation annuelle. À moins que le conseil d’administration ne prenne sérieusement en compte la sécurité, il est probable que personne ne s’en soucie. Pour cette raison, la plupart des organisations mettent en place une sécurité basée sur des cases à cocher, alias, déni plausible. Si vous souhaitez mettre en place la sécurité correctement, j’ai écrit quelques réflexions dans un billet de blog précédent : « Traiter la sécurité comme un risque. »

Tout compte fait, la sécurisation des applications ne disposera pas d’un grand budget, si tant est qu’il y en ait. Par conséquent, nous devons être intelligents à ce sujet et chercher un composant existant. Heureusement, OWASP propose une configuration prête à l’emploi pour gérer les 10 premiers, qui est corrigeable via une configuration appelée Core Rule Set. Malheureusement, il cible ModSecurity :

ModSecurity, parfois appelé Modsec, est un pare-feu d’applications web open-source (WAF). Conçu à l’origine comme un module pour le serveur HTTP Apache, il a évolué pour offrir une gamme de capacités de filtrage des requêtes et réponses HTTP, ainsi que d’autres fonctionnalités de sécurité, sur de nombreuses plates-formes différentes, notamment Apache HTTP Server, Microsoft IIS et Nginx. Il est librement distribué sous la licence Apache 2.0.

– ModSecurity sur Wikipédia

Bien qu’il soit théoriquement possible de configurer Nginx via la configuration Apache APISIX, il existe une autre façon plus directe.

Le jeu de règles Core et Coraza de l’OWASP

La description du jeu de règles Core est assez pertinente pour nos besoins:

Le jeu de règles ModSecurity Core (CRS) de l’OWASP® est un ensemble de règles de détection d’attaques génériques pour l’utilisation avec ModSecurity ou des pare-feux d’applications web compatibles. Le CRS vise à protéger les applications web contre une large gamme d’attaques, y compris le top dix de l’OWASP, avec un minimum de faux alertes. Le CRS offre une protection contre de nombreuses catégories d’attaques courantes, notamment:

Injection SQL (SQLi)

Cross Site Scripting (XSS)

Inclusion de fichiers locaux (LFI)

Inclusion de fichiers à distance (RFI)

Injection de code PHP

Injection de code Java

HTTPoxy

Shellshock

Injection de shell Unix/Windows

Fixation de session

Détection de scripts/scanners/bots

Métadonnées/Fuites d’erreurs

– Site web du jeu de règles de base ModSecurity d’OWASP®

OWASP fournit également Coraza, une version de ModSecurity disponible en tant que bibliothèque Go. Coraza Proxy Wasm est construit sur Coraza et met en œuvre l’ABI proxy-wasm, qui spécifie un ensemble d’interfaces Wasm pour les proxies. Enfin, Apache APISIX offre une intégration proxy-wasm.

Mettre tout ensemble

Résumons:

OWASP fournit une liste des 10 principales vulnérabilités de sécurité web.
Il les met en œuvre pour ModSecurity via le jeu de règles de base.
Coraza est une version de ModSecurity, disponible en tant qu’implémentation proxy-wasm.

Nous pouvons configurer Apache APISIX avec des valeurs par défaut saines et sécurisées de cette manière. Faisons-le.

Premièrement : Coraza ne fait pas partie de la distribution d’Apache APISIX. Cependant, il est simple d’y l’ajouter avec Docker:

Dockerfile

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

Définir des variables pour une meilleure maintenabilité
Obtenir la version Coraza Wasm.
Dans les dernières versions d’APISIX, l’utilisateur est apisix pour renforcer la sécurité. Comme nous devons installer des paquets, nous devons passer à root.
Installer 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.
Revenir à l’utilisateur apisix.

La prochaine étape consiste à configurer APISIX pour utiliser le plugin Wasm Coraza.

YAML

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

Nom du filtre défini dans le code Wasm
Définir la priorité la plus élevée pour qu’il s’exécute avant tout autre plugin.
Chemin vers le fichier extrait (voir le Dockerfile ci-dessus)

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

YAML

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

Configurer le plugin coraza-filter, maintenant qu’il est disponible.
Définir les configurations. Ici, nous définissons un seul, default, mais nous pourrions en définir plusieurs et utiliser des configurations différentes pour différentes routes.
Augmenter le niveau de journalisation pour voir ce qui se passe dans les journaux.
Activer le moteur.
Utiliser la configuration Coraza.
Utiliser toutes les règles. Nous pourrions choisir celles que nous voulons pour un contrôle plus précis.
Utiliser la configuration default définie ci-dessus.

Nous passons à la définition des routes pour tester notre configuration. Appelons la route vers /get:

Shell

curl localhost:9080?user=foobar

La réponse est conforme à ce qui est attendu:

JSON

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

Maintenant, essayons d’envoyer du JavaScript dans la chaîne de requête. Il n’est pas prévu que cette requête soit traitée côté serveur, donc notre infrastructure devrait nous protéger contre cela.

Shell

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 indications suivantes:

Plain Text

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 son travail!

Conclusion

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

Nous pouvons renforcer Apache APISIX contre les 10 principaux risques d’OWASP en utilisant Coraza et le jeu de règles de base.

Pour Aller Plus Loin

APISIX – Intégration avec Coraza

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

Source:
https://dzone.com/articles/hardening-apache-apisix-with-the-owasps-coraza-and