Aprimorando o 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 gratuitas e disponíveis para todos nos campos de segurança de IoT, software de sistema e aplicações web. A OWASP fornece recursos gratuitos e abertos. É liderada por uma organização sem fins lucrativos chamada The OWASP Foundation. A OWASP Top 10 – 2021 é o resultado publicado de uma pesquisa recente baseada em dados abrangentes compilados de mais de 40 organizações parceiras.

– site da OWASP

A OWASP publica regularmente um relatório de top 10 de vulnerabilidades. O relatório destina-se a vulnerabilidades em aplicações web.

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

A 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 verifique 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 aposentadoria das mais antigas. No entanto, algumas são técnicas e exigem apenas a configuração adequada no proxy reverso ou na API Gateway, por exemplo, Solicitação de Forjamento do Lado do Servidor.

Ninguém Se Importa Com Segurança

A segurança é um assunto delicado porque aperfeiçoar a 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 esse motivo, a maioria das organizações implementa a segurança baseada em caixas de seleção, ou seja, denegação plausível. Se você estiver interessado em implementar a segurança corretamente, escrevi alguns pensamentos 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 terá algum. Portanto, devemos ser espertos e procurar um componente existente. Felizmente, a OWASP oferece uma configuração pronta para lidar com os Top 10, que é corrigida por meio de uma configuração chamada Conjunto de Regras Principais. Infelizmente, isso 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 várias plataformas diferentes, incluindo o Apache HTTP Server, o Microsoft IIS e o 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á outra maneira mais direta.

O Conjunto de Regras Principais da OWASP e o 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 ataque comuns, incluindo:

  • SQL Injection (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 do OWASP® ModSecurity

O 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. O OWASP fornece uma lista das 10 principais vulnerabilidades de segurança web.
  2. Ele as implementa 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 maneira. Vamos fazer isso.

Antes de tudo: 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 melhor 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 dono da pasta extraída.
  5. Switch back para o usuário apisix. 

O próximo passo é configurar o próprio 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 ele 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 rotas diferentes.
  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 string de consulta. Não há como esta requisiçã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 para o 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 e usar componentes existentes o máximo possível.

Podemos fortalecer o Apache APISIX contra as 10 principais vulnerabilidades do OWASP usando o Coraza e o Core Ruleset.

Para ir além

O código-fonte completo deste post está disponível no GitHub.

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