O que é o Firewall do Aplicativo Web do Azure?

Concluído

Aqui, você aprenderá os conceitos básicos do Firewall de Aplicativo Web do Azure. Esta visão geral ajudará você a avaliar se o Firewall de Aplicativo Web do Azure é uma ferramenta útil a ser adicionada à estratégia geral de segurança de rede da Contoso.

Visão geral do Firewall de Aplicativo Web do Azure

Talvez você ache que usuários mal-intencionados não vão atacar seus aplicativos Web. No entanto, testes indicaram que bots ou atores mal-intencionados investigam novos aplicativos Web em busca de pontos fracos minutos após sua implantação. Se você colocar um aplicativo na Web, suponha que os atores de ameaças testarão as vulnerabilidades do aplicativo quase que imediatamente. Você também pode presumir que essas investigações continuarão durante o tempo de vida do aplicativo.

A maioria dos testes mal-intencionados de aplicativos Web verifica a presença de uma ou mais vulnerabilidades comuns. Se elas forem encontradas, um ator de ameaça poderá usar essas vulnerabilidades para executar ataques como as seguintes explorações:

  • injeção SQL
  • Script entre sites
  • Inclusão de arquivo local e remoto
  • Ataques de inundação de HTTP/HTTPS
  • Ataques de bot mal-intencionado

Uma tarefa comum no ciclo de desenvolvimento do aplicativo Web envolve a escrita de código para fechar as falhas de segurança mais comuns. Escrever o código de segurança requer tempo, experiência e teste.

O Firewall de Aplicativo Web do Azure é um serviço do Azure que oferece proteção centralizada de aplicativos Web hospedados no Azure. O Firewall de Aplicativo Web do Azure protege aplicativos Web contra ameaças comuns, como injeção de SQL e cross-site scripting.

Diagram of an Azure virtual network with Azure Web Application Firewall. Bots and threats are blocked from a web app; legitimate requests are allowed.

Você pode implantar o Firewall de Aplicativo Web do Azure em minutos. Seus aplicativos Web obtêm imediatamente proteção avançada contra ameaças conhecidas, tudo sem escrever uma linha de código de segurança.

Principais recursos do Firewall de Aplicativo Web do Azure

Para ajudá-lo a avaliar o Firewall de Aplicativo Web do Azure, aqui estão alguns dos recursos importantes:

  • Regras gerenciadas: as regras que o Firewall de Aplicativo Web do Azure usa para detectar e impedir explorações comuns são criadas, mantidas e atualizadas pela equipe de segurança da Microsoft. Se uma regra for alterada ou um conjunto de regras (veja a descrição a seguir) for modificado, a Microsoft atualizará o Firewall de Aplicativo Web do Azure de maneira automática e direta.

    Observação

    Você não pode modificar nem excluir as regras gerenciadas oferecidas pelo Firewall de Aplicativo Web do Azure. No entanto, se uma regra específica for problemática para seu ambiente (por exemplo, se ela bloquear um tráfego legítimo para o aplicativo Web), você poderá criar exclusões ou desabilitar a regra ou o conjunto de regras. Crie também regras personalizadas para substituir o comportamento padrão.

  • Regras de bots: as regras de bots identificam os bots confiáveis e protegem você contra os bots mal-intencionados. Os bots mal-intencionados são detectados com base na Inteligência contra Ameaças da Microsoft.

  • Regras personalizadas: se as regras gerenciadas oferecidas pelo Firewall de Aplicativo Web do Azure não abrangerem uma ameaça específica ao seu aplicativo Web, você poderá criar uma regra personalizada.

  • Modos: o Firewall de Aplicativo Web do Azure pode operar em um destes dois modos: o modo de detecção registra em log apenas as solicitações que violam uma regra, enquanto o modo de prevenção registra em log e bloqueia as solicitações que violam uma regra.

  • Listas de exclusões: você poderá configurar o Firewall de Aplicativo Web do Azure para ignorar atributos específicos quando ele verificar as solicitações.

  • Políticas: você pode combinar um conjunto de regras gerenciadas, regras personalizadas, exclusões e outras configurações do Firewall de Aplicativo Web do Azure em um só elemento chamado política de Firewall de Aplicativo Web do Azure. Então, você pode aplicar essa política a vários aplicativos Web para facilitar o gerenciamento e a manutenção.

  • Limites de tamanho das solicitações: você pode configurar o Firewall de Aplicativo Web do Azure para sinalizar as solicitações que são muito pequenas ou muito grandes.

  • Alertas: o Firewall de Aplicativo Web do Azure integra-se ao Azure Monitor. Essa integração fornece alertas quase em tempo real quando o WAF detecta uma ameaça.

Ataques comuns impedidos pelo Firewall de Aplicativo Web do Azure

A tabela a seguir descreve os tipos mais comuns de ameaças mal-intencionadas que o Firewall de Aplicativo Web do Azure ajuda a proteger.

Ameaça Descrição
Script entre sites Um ator de ameaça usa um aplicativo Web para enviar código mal-intencionado para o navegador da Web de outro usuário. O navegador executa o código, que fornece ao script acesso aos dados de sessão, aos cookies e a outras informações confidenciais do usuário.
Inclusão de arquivo local Um invasor explora vulnerabilidades no tratamento de instruções include de um servidor, com mais frequência em scripts PHP. Ao passar texto especialmente configurado para a instrução include de um script, o invasor pode incluir arquivos que estão presentes localmente no servidor. O invasor poderá então ser capaz de acessar informações confidenciais e executar comandos de servidor.
Injeção de PHP O invasor insere texto especialmente configurado para induzir o servidor a executar comandos PHP. Esses comandos permitem que o invasor execute código PHP local ou remoto. O invasor poderá então ter acesso a dados confidenciais e executar comandos no servidor.
Ataques de protocolo Um invasor insere texto especialmente configurado em um cabeçalho de solicitação HTTP/HTTPS. Dependendo do texto específico injetado no cabeçalho, o invasor poderá enganar o servidor para exibir dados confidenciais ou códigos em execução.
Execução de comando remoto O invasor induz um servidor a executar comandos associados ao sistema operacional do servidor. Em um sistema UNIX, por exemplo, o invasor poderá fazer com que o servidor execute ls para obter uma listagem de diretórios.
Inclusão de arquivo remoto O mesmo que a inclusão de arquivo local, exceto pelo fato que o invasor envia o texto especialmente configurado do servidor que passa um arquivo remoto, ou seja, um arquivo em um servidor remoto controlado pelo invasor para a instrução include de um script.
Fixação da sessão Um invasor explora uma vulnerabilidade do aplicativo Web que lhe permita obter uma ID de sessão válida. O invasor induz um usuário a autenticar uma nova sessão com essa ID. Então, o invasor sequestra essa sessão validada pelo usuário.
injeção SQL Em um campo de formulário da Web, o invasor insere (ou "injeta") texto especialmente configurado para enganar o servidor e executar comandos SQL. Esses comandos permitem que o invasor acesse dados confidenciais, insira, atualize ou exclua dados ou execute operações SQL.

Todas as explorações listadas na tabela anterior só são possíveis quando o servidor confia na entrada recebida. Escrever código que verifica e corrige apenas essas explorações seria difícil e demorado. Apenas uma pequena fração das possíveis explorações que um aplicativo Web pode enfrentar está representada na tabela anterior. O Firewall de Aplicativo Web do Azure foi projetado para evitar esses ataques e muito mais.

Limpeza de entrada

As ameaças enfrentadas por aplicativos Web modernos são diversificadas e sofisticadas. No entanto, na maioria dos casos, a razão porque as explorações são possíveis é que o aplicativo Web confia implicitamente na entrada recebida.

Por exemplo, considere um formulário da Web que permite que um usuário de aplicativo Web autorizado entre na conta do usuário. O formulário consiste em apenas três elementos:

  • Uma caixa de texto de Nome de usuário
  • Uma caixa de texto de Senha
  • Um botão de Entrar

Quando um usuário autorizado preenche o formulário e seleciona Entrar, um script de aplicativo Web armazena o nome de usuário e a senha em variáveis. Suponha que essas variáveis sejam chamadas userName e userPassword, respectivamente. Em seguida, o script executaria a seguinte instrução:

sql = "SELECT * FROM users WHERE username='" + userName + "' AND password='" + userPassword + "'"

Por exemplo, se o nome de usuário for support e a senha for 1234ABCD, a variável sql terá o seguinte valor:

SELECT * FROM users WHERE username='support' AND password='1234ABCD'

O aplicativo Web executa essa instrução SQL. Se um registro for retornado da consulta, o aplicativo Web conectará o usuário.

Agora suponha que um invasor insira admin'-- no campo Nome de usuário e deixe o campo Senha em branco. Nesse caso, veja a instrução SQL resultante:

SELECT * FROM users WHERE username='admin'--' AND password=''

Em muitos sistemas SQL, os traços duplos (--) marcam o início de um comentário. Tudo depois de -- é ignorado, portanto, a instrução anterior é equivalente ao seguinte código:

SELECT * FROM users WHERE username='admin'

Supondo que haja um usuário chamado admin, esse comando fará o invasor entrar como o usuário administrador: uma grave violação.

Network diagram depicting two sign-in attempts, with Azure Web Application Firewall allowing the authorized sign-in and denying the unauthorized sign-in.

O exemplo anterior é uma instância de uma exploração chamada injeção de SQL. Os invasores podem tirar proveito da injeção de SQL e de outras explorações em aplicativos Web que confiam em todas as entradas.

O Firewall de Aplicativo Web do Azure cria uma barreira de não confiança entre um aplicativo Web e a entrada de usuário. O Firewall de Aplicativo Web do Azure pressupõe que toda a entrada é potencialmente mal-intencionada, de modo que limpa essa entrada.

A limpeza da entrada significa coisas diferentes, dependendo do contexto. Por exemplo, a limpeza da entrada pode significar a remoção de elementos de texto claramente perigosos, como indicadores de comentário SQL. Embora ocorra a limpeza, o resultado é uma entrada que pode não prejudicar o aplicativo Web nem seus dados de back-end.