Fortalecimento do Apache APISIX com o Coraza e o Conjunto de Regras Principais da OWASP

O Open Worldwide Application Security Project é uma comunidade online que produz artigos, metodologias, documentação, ferramentas e tecnologias gratuitamente disponíveis nas áreas de segurança de IoT, software de sistema e aplicações web. O OWASP fornece recursos gratuitos e abertos. É liderado por uma organização sem fins lucrativos chamada The OWASP Foundation. O OWASP Top 10 – 2021 é o resultado publicado de uma pesquisa recente baseada em dados abrangentes compilados de mais de 40 organizações parceiras.

– website OWASP

O OWASP regularmente publica um relatório de Top 10 de vulnerabilidades. O relatório aborda vulnerabilidades em aplicações web.

Neste post, gostaria de descrever como corrigir alguns deles através do Apache APISIX API Gateway.

OWASP Top 10 2021

Em 2021, o relatório menciona:

  • A01:2021-Controle de Acesso Quebrado
  • A02:2021-Falhas de Criptografia
  • A03:2021-Injeção
  • A04:2021-Inseguro
  • A05:2021-Configuração de Segurança Errada
  • A06:2021-Componentes Vulneráveis e Desatualizados
  • A07:2021-Falhas de Identificação e Autenticação
  • A08:2021-Falhas de Integridade de Software e Dados
  • A09:2021-Falhas de Registro e Monitoramento de Segurança
  • A10:2021-Força Bruta de Solicitação do Servidor

Para mais detalhes, por favor, consulte o relatório completo report.

Corrigir uma vulnerabilidade depende de sua natureza exata. Por exemplo, corrigir Componentes Vulneráveis e Desatualizados é um processo orientado, exigindo disciplina na gestão de versões e na retirada das mais antigas. No entanto, algumas são técnicas e exigem apenas uma configuração adequada no proxy reverso ou no Gateway de API, por exemplo, Solicitação de Forjar no Lado do Servidor.

Ninguém se Importa com Segurança

A segurança é um assunto delicado porque a fortalecimento da segurança não traz nenhum valor para o negócio. Gerentes orientados à carreira não se preocuparão com a segurança, pois não poderão mostrar que aumentaram o lucro da empresa em X% em sua próxima avaliação anual. A menos que o conselho considere a segurança seriamente, é provável que ninguém se importe. Por esta razão, a maioria das organizações implementa segurança baseada em verificação de caixas, aka, denegação plausível. Se você está interessado em implementar segurança corretamente, escrevi algumas reflexões em um post de blog anterior: “Trate a Segurança como um Risco.”

Tudo considerado, proteger aplicativos não terá muito orçamento, se é que tem algum. Portanto, devemos ser espertos sobre isso e procurar um componente existente. Felizmente, a OWASP oferece uma configuração pronta para lidar com os Top 10, que é corrigível via uma configuração chamada Conjunto de Regras Principais. Infelizmente, ele se destina ao ModSecurity:

ModSecurity, às vezes chamado de Modsec, é um firewall de aplicativos web de código aberto (WAF). Originalmente projetado como um módulo para o Apache HTTP Server, evoluiu para fornecer uma variedade de capacidades de filtragem de solicitação e resposta do Hypertext Transfer Protocol, juntamente com outras características de segurança, em diversas plataformas, incluindo o Apache HTTP Server, Microsoft IIS e Nginx. É um software livre lançado sob a licença Apache 2.0.

– ModSecurity na Wikipedia

Embora seja teoricamente possível configurar o Nginx via configuração do Apache APISIX, há uma maneira mais direta.

O Conjunto de Regras Principais da OWASP e Coraza

A descrição do Conjunto de Regras Principais é bastante relevante para nossas necessidades:

O Conjunto de Regras Principais do OWASP® ModSecurity (CRS) é um conjunto de regras de detecção de ataques genéricas para uso com o ModSecurity ou firewalls de aplicativos web compatíveis. O CRS visa proteger aplicativos web de uma ampla gama de ataques, incluindo as Dez Principais da OWASP, com um mínimo de alertas falsos. O CRS oferece proteção contra muitas categorias de ataques comuns, incluindo:

  • Injeção SQL (SQLi)
  • Cross Site Scripting (XSS)
  • Inclusão de Arquivo Local (LFI)
  • Inclusão de Arquivo Remoto (RFI)
  • Injeção de Código PHP
  • Injeção de Código Java
  • HTTPoxy
  • Shellshock
  • Injeção de Shell Unix/Windows
  • Fixação de Sessão
  • Detecção de Scripts/Scanner/Bot
  • Metadados/Fluxos de Erro

– Website do Conjunto de Regras Principais ModSecurity da OWASP®

A OWASP também fornece Coraza, uma porta do ModSecurity disponível como uma biblioteca Go. Coraza Proxy Wasm é construído sobre Coraza e implementa a ABI proxy-wasm, que especifica um conjunto de interfaces Wasm para proxies. Por fim, o Apache APISIX oferece integração proxy-wasm.

Juntando Tudo

Vamos resumir:

  1. A OWASP fornece uma lista dos 10 principais vulnerabilidades de segurança web.
  2. Implementa-os para o ModSecurity através do Conjunto de Regras Principais.
  3. Coraza é uma porta do ModSecurity, disponível como uma implementação proxy-wasm.

Podemos configurar o Apache APISIX com padrões razoáveis e seguros dessa forma. Vamos fazer isso.

Antes de mais nada: Coraza não faz parte da distribuição do Apache APISIX. No entanto, é simples adicioná-lo aqui com 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. Defina variáveis para maior manutenibilidade
  2. Obtenha a versão Coraza Wasm.
  3. Nas versões recentes do APISIX, o usuário é apisix para endurecer a segurança. Como precisamos instalar pacotes, devemos mudar para root.
  4. Instale unzip pois não está instalado, descompacte o arquivo baixado, remova o arquivo, desinstale unzip e mude o proprietário da pasta extraída.
  5. Mude de volta para o usuário apisix. 

O próximo passo é configurar o APISIX para usar o 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 do filtro definido no código Wasm
  2. Defina a prioridade mais alta para que execute antes de qualquer outro plugin.
  3. Caminho para o arquivo extraído (veja o Dockerfile acima)

Finalmente, podemos atribuir o plugin a rotas ou configurá-lo como uma regra global para aplicar a todas as rotas. Estou usando configuração estática:

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. Configure o plugin coraza-filter, agora que está disponível.
  2. Defina configurações. Aqui, definimos uma única, default, mas poderíamos definir várias e usar diferentes em diferentes rotas.
  3. Aumente o nível de log para ver o que acontece nos logs.
  4. Ligue o motor.
  5. Use a configuração Coraza.
  6. Use todas as regras. Poderíamos escolher as que queremos para um controle mais detalhado.
  7. Use a configuração default definida acima.

Prosseguimos para definir rotas para testar nossa configuração. Vamos chamar a rota para /get:

Shell

  

curl localhost:9080?user=foobar

A resposta é conforme o esperado:

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

Agora, vamos tentar enviar JavaScript na cadeia de consulta. Não há como essa solicitação ser esperada no lado do servidor, então nossa infraestrutura deve nos proteger disso.

Shell

  

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

A resposta é um código de status HTTP 403. Se olharmos no log, podemos ver as seguintes dicas:

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 fez o trabalho!

Conclusão

A maioria das organizações não incentiva a segurança. Portanto, precisamos ser inteligentes sobre isso e usar componentes existentes o máximo possível.

Podemos fortalecer o Apache APISIX contra o OWASP Top 10 usando o Coraza e o Core Ruleset.

Para ir além

O código-fonte completo deste post pode ser encontrado no GitHub.

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