Como o site Proxies reverso aumenta a segurança do seu aplicativo da Web

Proxies, Mar-06-20245 minutos de leitura

Não é segredo que as empresas estão usando cada vez mais aplicativos da Web nos dias de hoje. Os aplicativos Web tornam conveniente simplificar as operações corporativas, aumentar a eficiência e, assim, economizar despesas com tarefas que, de outra forma, seriam feitas manualmente. Apesar de sua crescente popularidade, os aplicativos Web estão sujeitos a riscos e ataques cibernéticos. Este artigo fornecerá informações sobre

Não é segredo que as empresas estão usando cada vez mais aplicativos da Web nos dias de hoje. Os aplicativos da Web tornam conveniente simplificar as operações corporativas, aumentar a eficiência e, assim, economizar despesas com tarefas que, de outra forma, seriam feitas manualmente.

Os aplicativos da Web estão sujeitos a riscos e ataques cibernéticos, apesar de sua crescente popularidade. Este artigo fornecerá informações sobre os ataques significativos aos quais um aplicativo Web está vulnerável. Em seguida, você descobrirá como pode incorporar um proxy reverso para minimizar as ameaças.

Mas antes de mergulhar nos aspectos de segurança, vamos dar uma olhada na arquitetura de um aplicativo da Web típico.

Visão geral da arquitetura de aplicativos da Web

Aplicativo da Web

Na maioria das circunstâncias, os aplicativos da Web consistem em servidores da Web e páginas da Web. Os servidores da Web aceitam solicitações de clientes (seus navegadores da Web), que um servidor da Web processa e retorna a resposta ao cliente.  

Enquanto o lado do servidor é codificado usando linguagens de programação dinâmicas, como PHP, Python, ASP.NET etc., o lado do cliente é codificado usando HTML, CSS e JavaScript. A comunicação entre o cliente e o servidor ocorre por meio do protocolo HTTP.

Você pode consultar este artigo para obter mais informações sobre a estrutura dos aplicativos da Web. A figura abaixo mostra uma comunicação cliente-servidor típica.

Toda a comunicação parece ser direta no diagrama acima, com as solicitações indo e voltando entre o cliente e o servidor. No entanto, esse nem sempre é o caso.

Infelizmente, os aplicativos da Web que usam o design acima estão sujeitos a ataques cibernéticos por pessoas de fora entre o cliente e o servidor.

Vamos dar uma olhada em algumas das estatísticas mais interessantes sobre ataques cibernéticos antes de nos aprofundarmos na natureza desses ataques.

Quais são as principais ameaças a um aplicativo da Web?

Estatísticas empolgantes sobre ataques cibernéticos

De acordo com os dados de vulnerabilidades de aplicativos da Web da Positive Technologies de 2018, os setores financeiro e bancário foram responsáveis por 28% de todos os aplicativos da Web atacados. Também indica que 14% dos ataques cibernéticos visam aplicativos on-line nos setores de telecomunicações e manufatura, e 11% visam aplicativos de transporte.

Outros setores que enfrentam riscos incluem instituições governamentais (11%), TI, comércio eletrônico e mídia de massa.

Com relação aos tipos de ataques, outro relatório, da F5, afirma que os ataques de cross-site scripting (de 4% para 54%) e de injeção de SQL (SQLi) (de 15% para 76%) estão aumentando. 

Com base nessas estatísticas, podemos concluir que são necessárias algumas medidas rigorosas para proteger os aplicativos da Web contra vulnerabilidades. Algumas das falhas de segurança ocorrem devido a problemas de codificação, enquanto outros motivos podem ser devidos à infraestrutura inadequada usada pelo aplicativo da Web. É aqui que entra em cena o WAF (Web Application Firewall), que pode minimizar as vulnerabilidades filtrando pacotes, bloqueando o tráfego HTTP e registrando registros não autorizados. 

Exploraremos isso mais detalhadamente a seguir. Antes disso, uma breve visão geral das ameaças significativas à segurança.

Injeção de SQL (SQLi)

SQLi - A injeção de SQL é uma vulnerabilidade de segurança da Web que permite que o invasor manipule as consultas SQL que um aplicativo faz ao banco de dados. Ao fazer isso, ele obtém acesso a informações potencialmente valiosas que qualquer pessoa não pode acessar facilmente. 

Um exemplo simples e mais familiar seria aproveitar a entrada não higienizada do usuário para a vantagem do hacker. Vamos supor que haja uma caixa de texto que solicite o ID do usuário. Então, com base no ID do usuário, a consulta recupera todas as informações pertencentes a esse usuário.

Portanto, suponha que, na caixa de texto, o usuário tenha inserido o seguinte:


ID do usuário: 228 ou 1=1

Então, a consulta resultante seria a seguinte:

SELECT * FROM Users WHERE UserId = 228 OR 1=1;

Em seguida, ele recuperaria todos os dados da tabela do usuário, inclusive as senhas, se a tabela contiver dados de senha.

Para obter mais informações sobre o SQLi, você pode consultar aqui.

XSS (Cross-Site Scripting)

O XSS ocorre quando um usuário injeta um script mal-intencionado, principalmente em javascript, por meio de campos de entrada não higienizados. Normalmente, um invasor envia esse script mal-intencionado a um usuário que não é suspeito. O navegador do usuário final não sabe que esse script é prejudicial e o executa. 

Como resultado, esse script mal-intencionado pode acessar todos os dados associados a cookies, tokens de sessão ou qualquer outra informação confidencial. Além disso, esses scripts podem reescrever o HTML de uma página da Web.

Autenticação e gerenciamento de sessão quebrados

Suponha que um usuário tenha que fazer login em um aplicativo da Web usando as credenciais de login. Nesse caso, o algoritmo proprietário do site gera um ID de sessão exclusivo para toda a comunicação entre o usuário e o servidor da Web para essa sessão.

Se os desenvolvedores da Web não criptografaram os dados seguros que trafegam entre o usuário e o servidor da Web, há grandes chances de um invasor roubá-los e agir como o usuário. Esse cenário ocorre principalmente quando você faz login na Internet usando WiFi público em cafeterias.

Você pode consultar este artigo para obter mais detalhes.

Quais são os métodos para evitar ataques na Web?

Firewall de aplicativo da Web

O WAF é uma defesa de camada 7 no modelo OSI que pode ser colocada no ponto de entrada do servidor de destino, conforme mostrado no diagrama abaixo. Ele protege a rede interna do servidor contra ataques e oculta a topologia de rede do servidor.

Para que o WAF funcione, você deve fazer configurações adicionais no servidor. Assim como os firewalls, o WAF filtra o tráfego HTTP de entrada e saída que parece perigoso para a rede interna do servidor se não atender às regras que você definiu no WAF.

O WAF também é um tipo de proxy reverso que discutiremos na próxima seção.

Inverter Proxy

A função de um servidor proxy é ocultar seu endereço IP e substituí-lo pelo do servidor proxy . Bem, um proxy reverso também faz o mesmo e aumenta a segurança do servidor da Web, ocultando-o, bem como a topologia da rede interna do servidor.

O cliente só conhece o endereço do servidor proxy e, portanto, o servidor real fica oculto para o cliente.

Idealmente, você pode usar um proxy reverso como um WAF (Web Application Firewall) que discutimos acima. Você pode implementar o WAF em aplicativos da Web em dispositivos com o proxy reverso configurado. Como resultado, o escopo do WAF no aprimoramento da segurança se torna mais amplo. O invasor também não consegue ver o local real do servidor da Web.

Você pode consultar este artigo para obter mais informações fundamentais sobre o proxies reverso. Na próxima seção, veremos como usar um proxy reverso para atenuar os riscos do aplicativo. No entanto, antes disso, vamos apresentar a você uma visão geral do que faz um proxy reverso.

Como funciona o site proxy reverso?

Todos os sites reversos proxies realizam todas as operações fundamentais a seguir:

  1. O navegador do cliente envia uma solicitação HTTP para um URL público. Vamos supor que o URL seja www.host.com em porta 80.
  2. Em seguida, como de costume, o nome do host é resolvido pelo servidor proxy reverso. Esse servidor proxy reverso escuta esse endereço e recebe a solicitação.
  3. Depois disso, o proxy reverso investiga o URL para determinar para onde precisa proxy a solicitação. Normalmente, um proxy reverso pode usar qualquer componente de URL para decidir para onde encaminhar a solicitação. Por exemplo, ele pode usar host, protocolo, caminho, porta ou string de consulta. Normalmente, o caminho é o principal componente que decide o roteamento.
    1. As definições de configuração do proxy reverso determinam o URL de saída para o qual enviar a solicitação. Esse URL de saída geralmente é o servidor de back-end responsável por fornecer o conteúdo. O servidor proxy reverso pode reescrever as partes da solicitação. Ele pode, por exemplo, alterar ou adicionar segmentos de rota.
    2. A próxima etapa é a renovação do cabeçalho da solicitação; o site proxy reverso também deve atualizar algumas das informações do cabeçalho HTTP para indicar o servidor da Web interno, além de remapear o URL. O cabeçalho "Host:", por exemplo, contém o nome do host do qual o URL é solicitado.
    3. Portanto, para concluir o mapeamento de URL, http://www.host.com poderia ser remapeado para http://realhost.com:8080.As. Nesse caso, você pode ver que o nome do host foi alterado para realhost. Em seguida, o número porta também foi alterado para 8080.

  1. Por fim, o site proxy reverso envia a solicitação para o servidor real, que a processa.
  2. Depois que o servidor processa a solicitação, ele envia a resposta para o site reverso proxy.
  3. Em seguida, o site proxy reverso faz o seguinte:
    1. Ele modifica a resposta para que ela seja enviada corretamente ao cliente. Isso inclui o campo "Location:", que contém o local do servidor do arquivo.
    2. O site proxy reverso remapeia os cabeçalhos e, por fim, envia a resposta ao cliente.

Como proteger seu aplicativo da Web com reversão proxy

Como nosso objetivo é superar os ataques cibernéticos mencionados anteriormente, o proxy reverso precisa executar funcionalidades adicionais além das etapas mencionadas acima.

Validação do conteúdo da solicitação

Quando um cliente envia uma solicitação ao servidor, o site proxy reverso higieniza a entrada comparando-a com seu banco de dados de assinaturas. Os programadores desenvolvem essas assinaturas com expressões regulares altamente avançadas. A decisão do proxyreverso de permitir a solicitação com a entrada do usuário será baseada exclusivamente na abordagem de filtro de lista de bloqueio e filtro de lista branca.

Abordagem de filtro de lista negra

O filtro de lista negra armazena as solicitações prejudiciais conhecidas. Em seguida, ele compara cada solicitação com as entradas da lista. Se encontrar uma correspondência, ele rejeita a solicitação. Diferentes variações da mesma agressão devem ser registradas separadamente na lista. Você poderá impedir apenas as agressões conhecidas usando listas negras. A abrangência da lista negra contribui para a sua eficácia. 

Abordagem de filtro de lista branca

Um filtro de lista branca captura toda a coleção de solicitações válidas para um site específico. Como resultado, a lista branca impede ataques, permitindo que apenas solicitações conhecidas cheguem ao servidor. O processo de criação de uma lista branca, por outro lado, é demorado e requer conhecimento de toda a gama de solicitações legítimas que um usuário pode potencialmente enviar a um servidor. 

Além disso, pode ser muito trabalhoso criar todas as solicitações válidas para centenas de milhares de fornecedores de bancos de dados existentes em caso de injeção de SQL

Qualquer modificação em um aplicativo da Web protegido exigiria uma atualização da lista de permissões. Como resultado, manter uma lista de permissões aumenta a carga administrativa. 

Validação do conteúdo da resposta

Antes de enviar a resposta do servidor de volta para o cliente, o site proxy reverso a valida. Normalmente, uma lista negra é usada para fazer isso. O filtro da lista negra pode ocultar respostas conhecidas de clientes que não precisam visualizá-las. As mensagens de erro são um exemplo desse tipo de dados; o proxy reverso pode substituir o erro por uma mensagem de erro genérica que não contenha dados confidenciais.

Registro de solicitações e respostas

O proxy reverso também pode registrar a solicitação para análise posterior. A melhor abordagem é configurar o registro apenas para as solicitações que o proxy reverso bloqueou inicialmente. Você deve examinar cuidadosamente os registros durante os primeiros estágios da instalação. Isso é essencial para verificar se o proxy reverso não bloqueia nenhuma solicitação genuína.

Conclusão

Neste artigo, esperamos que você entenda as vulnerabilidades em um aplicativo da Web e como pode usar um proxy reverso para resolver essas ameaças. De fato, o proxy reverso não eliminará todas as possíveis vulnerabilidades associadas aos aplicativos da Web.

No entanto, essa seria uma ótima estratégia para atenuar a maioria das ameaças que você encontra em um aplicativo Web. Por fim, esperamos que você aplique os conceitos aprendidos neste artigo caso tenha problemas de segurança em seu aplicativo Web.