Como resolver vulnerabilidades da Web com Apache APISIX API Gateway

O Open Worldwide Application Security Project é uma comunidade online que produz artigos, metodologias, documentação, ferramentas e tecnologias disponíveis gratuitamente nas áreas de IoT, software de sistema e segurança de 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 pesquisas recentes baseadas em dados abrangentes compilados de mais de 40 organizações parceiras.

- Site da OWASP

O OWASP publica regularmente um relatório das 10 principais vulnerabilidades. O relatório visa vulnerabilidades em aplicativos da web.

Neste post, gostaria de descrever como corrigir alguns deles por meio do Apache APISIX API Gateway .

Os 10 melhores do OWASP 2021

Em 2021, o relatório menciona:

• A01:2021-Controle de acesso quebrado
• A02:2021-Falhas criptográficas
• A03:2021-Injeção
• A04:2021-Inseguro
• A05:2021-Configuração incorreta de segurança
• A06:2021-Componentes vulneráveis e desatualizados
• A07:2021-Falhas de identificação e autenticação
• A08:2021-Falhas de software e integridade de dados
• A09:2021-Falhas de registro e monitoramento de segurança
• A10:2021-Falsificação de solicitação do lado do servidor

Para mais detalhes, consulte o relatório completo.

A correção de uma vulnerabilidade depende de sua natureza exata. Por exemplo, a correção de componentes vulneráveis e desatualizados é orientada por processos, exigindo disciplina no gerenciamento de versões e na desativação de versões mais antigas. Alguns, no entanto, são técnicos e requerem apenas configuração adequada no proxy reverso ou API Gateway, por exemplo , Server Side Request Forgery .

Ninguém se preocupa com segurança

A segurança é um assunto delicado porque o fortalecimento da segurança não traz nenhum valor para o negócio. Os gestores orientados para a carreira não se importarão com a segurança, pois não serão capazes de demonstrar que aumentaram o lucro da empresa em X% na 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 segurança baseada em caixas de seleção, também conhecida como negação plausível. Se você estiver interessado em implementar a segurança adequadamente, escrevi algumas reflexões em uma postagem anterior do blog: Trate a segurança como um risco .

Resumindo, proteger aplicativos não exigirá muito orçamento, se houver. Portanto, devemos ser espertos e procurar um componente existente. Felizmente, o OWASP oferece uma configuração pronta para uso para lidar com o Top 10, que pode ser corrigida por meio de uma configuração chamada Core Rule Set . Infelizmente, ele tem como alvo o ModSecurity:

ModSecurity, às vezes chamado de Modsec, é um firewall de aplicativo da web (WAF) de código aberto. Originalmente projetado como um módulo para o Apache HTTP Server, ele evoluiu para fornecer uma variedade de recursos de filtragem de solicitações e respostas do Hypertext Transfer Protocol, juntamente com outros recursos de segurança em diversas plataformas diferentes, incluindo Apache HTTP Server, Microsoft IIS e Nginx. É um software gratuito lançado sob a licença Apache 2.0.

-- ModSecurity na Wikipédia

Embora seja teoricamente possível configurar o Nnginx por meio da configuração Apache APISIX, há outra maneira mais direta.

O Conjunto de Regras Básicas da OWASP e Coraza

A descrição do Core Ruleset é bastante relevante para as nossas necessidades:

O OWASP® ModSecurity Core Rule Set (CRS) é um conjunto de regras genéricas de detecção de ataques para uso com ModSecurity ou firewalls de aplicativos da web compatíveis. O CRS visa proteger aplicações web de uma ampla gama de ataques, incluindo o OWASP Top Ten, com um mínimo de alertas falsos. O CRS oferece proteção contra muitas categorias de ataques comuns, incluindo:

• Injeção SQL (SQLi)
• Scripting entre sites (XSS)
• Inclusão de arquivo local (LFI)
• Inclusão remota de arquivos (RFI)
• Injeção de código PHP
• Injeção de código Java
• HTTPoxy
• Trauma pós guerra
• Injeção de Shell Unix/Windows
• Fixação de Sessão
• Scripting/Scanner/Detecção de Bot
• Vazamentos de metadados/erros

- Site do conjunto de regras principais do OWASP® ModSecurity

OWASP também fornece Coraza , uma versão do ModSecurity disponível como uma biblioteca Go. O Coraza Proxy Wasm é construído sobre o Coraza e implementa o proxy-wasm ABI , que especifica um conjunto de interfaces Wasm para proxies. Finalmente, 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 da web
2. Ele os implementa para ModSecurity por meio do Core Ruleset
3. Coraza é uma versão do ModSecurity, disponível como uma implementação proxy-wasm

Podemos configurar o Apache APISIX com padrões sensatos e seguros desta forma. Vamos fazê-lo.

Comecemos pelo princípio: Coraza não faz parte da distribuição Apache APISIX. No entanto, é simples adicioná-lo aqui com o Docker:

 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 manutenção
2. Obtenha o lançamento do Coraza Wasm
3. Nas versões recentes do APISIX, o usuário é apisix para aumentar a segurança. Como precisamos instalar pacotes, devemos mudar para root .
4. Instale unzip porque não está instalado, descompacte o arquivo baixado, remova o arquivo, desinstale unzip e altere o proprietário da pasta extraída
5. Voltar para o usuário apisix

O próximo passo é configurar o próprio APISIX para usar o plugin Coraza Wasm.

 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 seja executado antes de qualquer outro plugin
3. Caminho para o arquivo extraído, veja o Dockerfile acima

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

 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 um único, default , mas poderíamos definir vários e usar diferentes em rotas diferentes
3. Aumente o nível do log para ver o que acontece nos logs
4. Ligue o motor
5. Usar a configuração do Coraza
6. Use todas as regras. Poderíamos escolher aqueles que desejamos para um controle mais refinado
7. Use a configuração default definida acima

Prosseguimos definindo rotas para https://httpbin.org/ para testar nossa configuração. Vamos chamar a rota para /get :

 curl localhost:9080?user=foobar

A resposta é a esperada:

 { "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 essa solicitação ser esperada no lado do servidor, portanto nossa infraestrutura deve nos proteger dela.

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

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

 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 os componentes existentes tanto quanto possível.

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

Ir adiante:

• Top 10 de segurança OWASP
• Conjunto de regras principais do OWASP ModSecurity
• OWASP Coraza WAF
• APISIX - Integrar com Coraza

O código-fonte completo desta postagem pode ser encontrado no GitHub .

Publicado originalmente em A Java Geek em 4 de fevereiro de 2024