paint-brush
Como resolver vulnerabilidades da Web com Apache APISIX API Gatewaypor@nfrankel
254 leituras

Como resolver vulnerabilidades da Web com Apache APISIX API Gateway

por Nicolas Fränkel9m2024/02/10
Read on Terminal Reader

Muito longo; Para ler

Podemos fortalecer o Apache APISIX contra o OWASP Top 10 usando Coraza e o Core Ruleset.
featured image - Como resolver vulnerabilidades da Web com Apache APISIX API Gateway
Nicolas Fränkel HackerNoon profile picture


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:



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


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