Beveiliging van Apache APISIX met OWASP’s Coraza en Core Ruleset

Het Open Worldwide Application Security Project is een online gemeenschap die vrij beschikbare artikelen, methodologieën, documentatie, tools en technologieën produceert op het gebied van IoT, systeemsoftware en webapplicatiebeveiliging. OWASP biedt gratis en openbare bronnen. Het wordt geleid door een non-profit genaamd The OWASP Foundation. De OWASP Top 10 – 2021 is het gepubliceerde resultaat van recent onderzoek dat is gebaseerd op uitgebreide gegevens verzameld van meer dan 40 partnerorganisaties.

– OWASP website

OWASP publiceert regelmatig een Top 10 kwetsbaarheidsrapport. Het rapport richt zich op kwetsbaarheden in webapplicaties.

In deze post wil ik beschrijven hoe enkele van hen te herstellen via de Apache APISIX API Gateway.

De OWASP Top 10 2021

In 2021 vermeldt het rapport:

  • A01:2021-Broken Access Control
  • A02:2021-Cryptographic Failures
  • A03:2021-Injection
  • A04:2021-Insecure
  • A05:2021-Security Misconfiguration
  • A06:2021-Vulnerable and Outdated Components
  • A07:2021-Identification and Authentication Failures
  • A08:2021-Software and Data Integrity Failures
  • A09:2021-Security Logging and Monitoring Failures
  • A10:2021-Server-Side Request Forgery

Voor meer informatie, gelieve het volledige rapport te controleren.

Het oplossen van een kwetsbaarheid hangt af van de precieze aard ervan. Bijvoorbeeld, het oplosen van Kwetsbare en verouderde componenten is procesgestuurd, waarbij discipline vereist is bij het beheer van versies en het buiten gebruik stellen van oudere versies. Sommige zijn echter technisch en vereisen enkel de juiste configuratie in de reverse proxy of API Gateway, bijvoorbeeld Server Side Request Forgery.

Niemand geeft om beveiliging

Beveiliging is een gevoelig onderwerp omdat het versterken van beveiliging geen waarde toevoegt aan het bedrijf. Carrièregestuurde managers zullen niet om beveiliging geven, aangezien ze niet in staat zullen zijn om te laten zien dat ze de winst van het bedrijf met X% hebben verhoogd bij hun volgende jaarlijkse evaluatie. Tenzij de raad van bestuur beveiliging serieus neemt, zullen de kansen groot zijn dat niemand erom geeft. Daarom implementeren de meeste organisaties checkbox-gebaseerde beveiliging, ook wel plausibele ontkenning genoemd. Als u geïnteresseerd bent in het correct implementeren van beveiliging, heb ik enkele gedachten geschreven in een vorig blogbericht: “Behandel Beveiliging als een Risico.”

Al met al zal het beveiligen van applicaties niet veel budget krijgen, zo niet helemaal. Daarom moeten we er slim over zijn en naar een bestaand component zoeken. Gelukkig biedt de OWASP een uit-de-doos configuratie aan om te hanteren voor de Top 10, die opgelost kan worden via een configuratie genaamd Core Rule Set. Helaas richt het zich op ModSecurity:

ModSecurity, soms ook aangeduid als Modsec, is een open-source web application firewall (WAF). Oorspronkelijk ontworpen als een module voor de Apache HTTP Server, is het zich ontwikkeld tot een reeks Hypertext Transfer Protocol-aanvraag- en antwoordfiltercapaciteiten samen met andere beveiligingsfuncties op verschillende platforms, waaronder Apache HTTP Server, Microsoft IIS en Nginx. Het is vrije software uitgebracht onder de Apache-licentie 2.0.

– ModSecurity op Wikipedia

Hoewel het in theorie mogelijk is om Nginx via Apache APISIX-configuratie in te stellen, is er een andere eenvoudigere manier.

Het OWASP Core Ruleset en Coraza

De beschrijving van het Core Ruleset is vrij relevant voor onze behoeften:

Het OWASP® ModSecurity Core Rule Set (CRS) is een verzameling generieke aanvalsdetectieruimels voor gebruik met ModSecurity of compatibele web application firewalls. Het CRS heeft als doel webtoepassingen te beschermen tegen een breed scala aan aanvallen, waaronder de OWASP Top Ten, met een minimum aan valse waarschuwingen. Het CRS biedt bescherming tegen veel voorkomende aanvalscategorieën, waaronder:

  • SQL Injection (SQLi)
  • Cross Site Scripting (XSS)
  • Lokale Bestand Inclusie (LFI)
  • Externe Bestand Inclusie (RFI)
  • PHP Code Injection
  • Java Code Injection
  • HTTPoxy
  • Shellshock
  • Unix/Windows Shell Injection
  • Sessie Fixatie
  • Scripting/Scanner/Bot Detection
  • Metadata/Error Leakages

– OWASP® ModSecurity Core Rule Set website

OWASP biedt ook Coraza, een port van ModSecurity die beschikbaar is als een Go-bibliotheek. Coraza Proxy Wasm is gebouwd op basis van Coraza en implementeert de proxy-wasm ABI, die een reeks Wasm-interfaces voor proxies specificeert. Ten slotte biedt Apache APISIX proxy-wasm integratie.

Putting It All Together

Laten we het samenvatten:

  1. OWASP biedt een lijst van de Top 10 webbeveiligingskwetsbaarheden.
  2. Het implementeert deze voor ModSecurity via het Core Ruleset.
  3. Coraza is een port van ModSecurity, beschikbaar als een proxy-wasm implementatie.

We kunnen Apache APISIX op deze manier configureren met redelijke en veilige standaarden. Laten we dat doen.

Eerst het belangrijkste: Coraza maakt geen deel uit van de Apache APISIX-distributie. Toch is het eenvoudig om het hier toe te voegen met 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

  1. Definieer variabelen voor betere onderhoudbaarheid
  2. Haal de Coraza Wasm release op.
  3. In recente APISIX-versies is de gebruiker apisix om de beveiliging te versterken. Aangezien we pakketten moeten installeren, moeten we overschakelen naar root.
  4. Installeer unzip omdat dit niet geïnstalleerd is, pak de gedownloade archief, verwijder het archief, deinstalleer unzip, en wijzig de eigenaar van de uitgepakte map.
  5. Switch terug naar gebruiker apisix. 

De volgende stap is het configureren van APISIX zelf om de Coraza Wasm-plugin te gebruiken.

YAML

  

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

  1. Naam van de filter die in de Wasm-code is ingesteld
  2. Stel de hoogste prioriteit in zodat deze voor alle andere plugins wordt uitgevoerd.
  3. Pad naar het uitgepakte bestand (zie de Dockerfile hierboven)

Tot slot kunnen we de plugin aan routes toewijzen of deze instellen als een globale regel om toe te passen op elke route. Ik gebruik statische configuratie:

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

  1. Configureer de coraza-filter plugin, nu deze beschikbaar is.
  2. Definieer configuraties. Hier definiëren we er één, default, maar we kunnen er meerdere definiëren en verschillende gebruiken in verschillende routes.
  3. Verhoog het logniveau om te zien wat er in de logs gebeurt.
  4. Zet de motor aan.
  5. Gebruik Coraza-setup.
  6. Gebruik alle regels. We konden er voor kiezen en de gewenste kiezen voor meer gedetailleerde controle.
  7. Gebruik de hierboven gedefinieerde default configuratie.

We gaan verder met het definiëren van routes om onze setup te testen. Laten we de route naar /get noemen:

Shell

  

curl localhost:9080?user=foobar

De reactie is zoals verwacht:

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

Probeer nu JavaScript in de query tekst te sturen. Er is geen manier dat deze aanvraag van tevoren op de serverzijde wordt verwacht, dus ons infrastructuur moet ons hierbij beschermen.

Shell

  

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

De reactie is een 403 HTTP-statuscode. Als we in de log kijken, kunnen we de volgende aanwijzingen zien:

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 heeft het werk gedaan!

Conclusie

De meeste organisaties bieden geen stimulansen voor beveiliging. Daarom moeten we er slim over denken en zoveel mogelijk bestaande componenten gebruiken.

We kunnen Apache APISIX tegen de OWASP Top 10 harden door Coraza en het Core Ruleset te gebruiken.

Om Verder Te Gaan

Het volledige broncode voor deze post is te vinden op GitHub.

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