Indurimento di Apache APISIX con Coraza e Core Ruleset dell’OWASP

Il Project Open Worldwide Application Security è una comunità online che produce articoli, metodologie, documentazione, strumenti e tecnologie gratuitamente disponibili nei campi della sicurezza dei dispositivi IoT, del software di sistema e delle applicazioni web. OWASP fornisce risorse gratuite e aperte ed è guidato da un’organizzazione no-profit chiamata The OWASP Foundation. La OWASP Top 10 – 2021 è il risultato pubblicato di una recente ricerca basata su dati completi compilati da oltre 40 organizzazioni partner.

– sito web OWASP

OWASP pubblica regolarmente un rapporto sulle top 10 vulnerabilità. Il rapporto si concentra su vulnerabilità nelle applicazioni web.

In questo post, vorrei descrivere come risolvere alcune di esse tramite il Gateway API Apache APISIX.

La OWASP Top 10 2021

Nel 2021, il rapporto menziona:

  • A01:2021-Controllo di accesso interrotto
  • A02:2021-Fallimenti crittografici
  • A03:2021-Iniezione
  • A04:2021-Insicure
  • A05:2021-Configurazione di sicurezza errata
  • A06:2021-Componenti vulnerabili e obsoleti
  • A07:2021-Fallimenti di identificazione e autenticazione
  • A08:2021-Fallimenti dell’integrità del software e dei dati
  • A09:2021-Fallimenti di registrazione e monitoraggio della sicurezza
  • A10:2021-Richiesta di furto del server

Per ulteriori dettagli, si prega di consultare il rapporto completo report.

La correzione di una vulnerabilità dipende dalla sua natura esatta. Ad esempio, risolvere Componenti vulnerabili e obsoleti è un processo guidato, che richiede disciplina nella gestione delle versioni e nel pensionamento delle versioni più vecchie. Alcune, tuttavia, sono tecniche e richiedono solo una configurazione corretta nel reverse proxy o nel Gateway API, ad esempio, Forgiatura di richieste lato server.

A Niente Cura Sulla Sicurezza

La sicurezza è un argomento delicato perché rafforzare la sicurezza non aggiunge alcun valore al business. I manager orientati alla carriera non si preoccuperanno della sicurezza poiché non saranno in grado di mostrare di aver aumentato il profitto dell’azienda del X% nella loro prossima valutazione annuale. A meno che il consiglio di amministrazione non consideri seriamente la sicurezza, è probabile che nessuno se ne curi. Per questo motivo, la maggior parte delle organizzazioni implementa una sicurezza basata su controllo, alias, plausibile deniability. Se sei interessato a implementare la sicurezza correttamente, ho scritto alcune riflessioni in un post precedente: “Trattare la Sicurezza come un Rischio.”

Tutto sommato, la sicurezza delle applicazioni non riceverà un grande budget, se non nessuno. Pertanto, dobbiamo essere intelligenti al riguardo e cercare un componente esistente. Fortunatamente, l’OWASP offre una configurazione pronta all’uso per gestire i primi 10, che è risolvibile tramite una configurazione denominata Core Rule Set. Purtroppo, si rivolge a ModSecurity:

ModSecurity, talvolta chiamato Modsec, è un firewall per applicazioni web open-source (WAF). In origine progettato come modulo per il server HTTP Apache, si è evoluto per offrire una serie di capacità di filtraggio delle richieste e delle risposte del protocollo HTTP e altre funzionalità di sicurezza su diversi piattaforme, tra cui Apache HTTP Server, Microsoft IIS e Nginx. È un software gratuito rilasciato con licenza Apache 2.0.

– ModSecurity su Wikipedia

Sebbene teoricamente possibile configurare Nginx tramite la configurazione di Apache APISIX, esiste un altro modo più semplice.

Il set di regole Core di OWASP e Coraza

La descrizione del set di regole Core è piuttosto rilevante per le nostre esigenze:

Il set di regole Core di OWASP® ModSecurity (CRS) è un insieme di regole di rilevamento degli attacchi generiche per l’uso con ModSecurity o firewall per applicazioni web compatibili. Il CRS mira a proteggere le applicazioni web da una vasta gamma di attacchi, inclusa la top ten di OWASP, con un minimo di falsi allarmi. Il CRS offre protezione contro molte categorie di attacchi comuni, tra cui:

  • Iniezione SQL (SQLi)
  • Cross Site Scripting (XSS)
  • Inclusione di File Locale (LFI)
  • Inclusione di File Remoto (RFI)
  • Iniezione di Codice PHP
  • Iniezione di Codice Java
  • HTTPoxy
  • Shellshock
  • Iniezione di Shell Unix/Windows
  • Fissazione della Sessione
  • Rilevamento di Script/Scanner/Bot
  • Metadata/Error Leakages

– Sito web OWASP® ModSecurity Core Rule Set

OWASP fornisce anche Coraza, una versione di ModSecurity disponibile come libreria Go. Coraza Proxy Wasm si basa su Coraza e implementa l’ABI proxy-wasm, che specifica un set di interfacce Wasm per i proxy. Infine, Apache APISIX offre l’integrazione proxy-wasm.

Mettendo tutto insieme

Riassumiamo:

  1. OWASP fornisce un elenco delle Top 10 vulnerabilità di sicurezza web.
  2. Le implementa per ModSecurity tramite il Core Ruleset.
  3. Coraza è una versione di ModSecurity, disponibile come implementazione proxy-wasm.

Possiamo configurare Apache APISIX con impostazioni predefinite sane e sicure in questo modo. Facciamolo.

Prima di tutto: Coraza non fa parte della distribuzione di Apache APISIX. Tuttavia, è semplice aggiungerla qui con 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. Definisci variabili per una maggiore manutenibilità
  2. Ottieni la versione Coraza Wasm.
  3. Nelle recenti versioni di APISIX, l’utente è apisix per irrobustire la sicurezza. Poiché abbiamo bisogno di installare pacchetti, dobbiamo passare a root.
  4. Installa unzip poiché non è installato, scompatt
  5. Torna al user apisix. 

Il passo successivo è configurare APISIX stesso per utilizzare il plugin Coraza Wasm.

YAML

  

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

  1. Nome del filtro impostato nel codice Wasm
  2. Imposta la priorità più alta in modo che venga eseguito prima di qualsiasi altro plugin.
  3. Percorso del file estratto (vedi il Dockerfile sopra)

Infine, possiamo assegnare il plugin a route o impostarlo come regola globale da applicare a ogni route. Sto utilizzando una configurazione statica:

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. Configura il plugin coraza-filter, ora che è disponibile.
  2. Definisci le configurazioni. Qui, ne definiamo una sola, default, ma potremmo definirne diverse e utilizzare diverse configurazioni per diverse route.
  3. Aumenta il livello di log per vedere cosa succede nei log.
  4. Attiva il motore.
  5. Utilizza la configurazione Coraza.
  6. Utilizza tutte le regole. Potremmo scegliere quelle che vogliamo per un controllo più granulare.
  7. Utilizza la configurazione default definita sopra.

Procediamo a definire le route per testare la nostra configurazione. Chiamiamo la route a /get:

Shell

  

curl localhost:9080?user=foobar

La risposta è come previsto:

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

Ora, proviamo a inviare JavaScript nella stringa di query. Non c’è modo che questa richiesta sia prevista lato server, quindi la nostra infrastruttura dovrebbe proteggerci da essa.

Shell

  

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

La risposta è un codice di stato HTTP 403. Se guardiamo il log, possiamo vedere i seguenti indizi:

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 ha fatto il lavoro!

Conclusione

La maggior parte delle organizzazioni non incentiva la sicurezza. Pertanto, dobbiamo essere intelligenti al riguardo e utilizzare componenti esistenti il più possibile.

Possiamo rinforzare Apache APISIX contro le 10 vulnerabilità più pericolose di OWASP utilizzando Coraza e il Core Ruleset.

Per andare oltre

Il codice sorgente completo per questo post è disponibile su GitHub.

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