Como é que os proxies inversos melhoram a segurança da sua aplicação Web

Não é segredo que as empresas estão a utilizar cada vez mais aplicações Web nos dias de hoje. As aplicações Web permitem simplificar as operações empresariais, aumentar a eficiência e, assim, poupar despesas em tarefas que, de outro modo, seriam efectuadas manualmente. Apesar da sua crescente popularidade, as aplicações Web estão sujeitas a riscos e ciberataques. Este artigo fornece informações sobre

Não é segredo que as empresas estão a utilizar cada vez mais aplicações Web nos dias de hoje. As aplicações Web permitem simplificar as operações empresariais, aumentar a eficiência e, assim, poupar despesas em tarefas que, de outro modo, seriam efectuadas manualmente.

As aplicações Web estão sujeitas a riscos e ciberataques, apesar da sua crescente popularidade. Este artigo fornecerá informações sobre os ataques significativos aos quais uma aplicação Web é vulnerável. Em seguida, descobrirá como pode incorporar um proxy invertido para minimizar as ameaças.

Mas antes de nos debruçarmos sobre os aspectos de segurança, vejamos a arquitetura de uma aplicação Web típica.

Visão geral da arquitetura das aplicações Web

Aplicação Web

Na maioria dos casos, as aplicações Web consistem em servidores Web e páginas Web. Os servidores Web aceitam pedidos de clientes (os seus navegadores Web), que um servidor Web processa e devolve a resposta ao cliente.  

Enquanto o lado do servidor é codificado utilizando linguagens de programação dinâmicas, como PHP, Python, ASP.NET, etc., o lado do cliente é codificado utilizando HTML, CSS e JavaScript.

Pode consultar este artigo para obter mais informações sobre a estrutura das aplicações Web. A figura abaixo mostra uma comunicação cliente-servidor típica.

Toda a comunicação parece ser direta no diagrama acima, com os pedidos a viajar para trás e para a frente entre o cliente e o servidor. No entanto, nem sempre é esse o caso.

Infelizmente, as aplicações Web que utilizam a conceção acima descrita estão sujeitas a ciberataques por pessoas estranhas entre o cliente e o servidor.

Vejamos algumas das estatísticas mais interessantes sobre ataques cibernéticos antes de nos debruçarmos sobre a natureza desses ataques.

Quais são as principais ameaças a uma aplicação Web?

Estatísticas interessantes sobre ciberataques

De acordo com os dados da Positive Technologies sobre as vulnerabilidades das aplicações Web de 2018, os sectores financeiro e bancário representaram 28% de todas as aplicações Web atacadas. Indicam também que 14% dos ciberataques visam aplicações em linha nos sectores das telecomunicações e da indústria transformadora, e 11% visam aplicações de transportes.

Outros sectores que enfrentam riscos incluem as instituições governamentais (11%), as TI, o comércio eletrónico e os meios de comunicação social.

No que diz respeito 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 a aumentar. 

A partir destas estatísticas, podemos concluir que são necessárias algumas medidas rigorosas para proteger as aplicações Web das vulnerabilidades. Algumas das falhas de segurança ocorrem devido a problemas de codificação, enquanto outras razões podem dever-se a uma infraestrutura inadequada utilizada pela aplicação Web. É aqui que entra em cena o Web Application Firewall (WAF), que pode minimizar as vulnerabilidades filtrando pacotes, bloqueando o tráfego HTTP e o registo não autorizado. 

Analisá-la-emos mais adiante. Antes disso, uma breve panorâmica das principais ameaças à segurança.

Injeção de SQL (SQLi)

A injeção de SQLi -SQL é uma vulnerabilidade de segurança na Web que permite ao atacante manipular as consultas SQL que uma aplicação faz à base de dados. Ao fazê-lo, obtém acesso a informações potencialmente valiosas que qualquer pessoa não pode alcançar facilmente. 

Um exemplo simples e mais familiar seria tirar partido da entrada de dados do utilizador não higienizada em benefício do hacker. Vamos supor que existe uma caixa de texto que pede o ID do utilizador. Depois, com base no ID do utilizador, a consulta recupera todas as informações pertencentes a esse utilizador.

Assim, suponhamos que na caixa de texto o utilizador tinha introduzido o seguinte:

Identificação do utilizador: 228 ou 1=1

A consulta resultante seria a seguinte:

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

Em seguida, recupera todos os dados da tabela do utilizador, incluindo as palavras-passe, se a tabela contiver dados de palavras-passe.

Para mais informações sobre a SQLi, pode consultar aqui.

XSS (Cross-Site Scripting)

O XSS ocorre quando um utilizador injecta um script malicioso, principalmente em javascript, através de campos de entrada não higienizados. Normalmente, um atacante envia este script malicioso a um utilizador de quem não se suspeita. O browser do utilizador final não sabe que este script é nocivo e executa-o. 

Como resultado, este script malicioso pode aceder a todos os dados associados a cookies, tokens de sessão ou qualquer outra informação sensível. Além disso, estes scripts podem reescrever o HTML de uma página web.

Autenticação e gestão de sessões quebradas

Suponhamos que um utilizador tem de iniciar sessão numa aplicação Web utilizando as credenciais de início de sessão. Nesse caso, o algoritmo proprietário do sítio Web gera um ID de sessão único para toda a comunicação entre o utilizador e o servidor Web para essa sessão.

Se os programadores Web não tiverem encriptado os dados seguros que circulam entre o utilizador e o servidor Web, há grandes probabilidades de um intruso os roubar e fazer-se passar pelo utilizador. Este cenário ocorre principalmente quando se liga à Internet através de WiFi público em cafés.

Para mais informações, consulte este artigo.

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

Firewall de aplicação Web

O WAF é uma defesa de nível 7 no modelo OSI que pode ser colocada no ponto de entrada do servidor de destino, como mostra o diagrama abaixo. Protege a rede interna do servidor contra ataques e oculta a topologia de rede do servidor.

Para que o WAF funcione, é necessário efetuar configurações adicionais no servidor. Tal como as firewalls, o WAF filtra o tráfego HTTP de entrada e de saída que parece perigoso para a rede interna do servidor se não satisfizer as regras que definiu no WAF.

O WAF é também um tipo de proxy invertido que será abordado na próxima secção.

Proxy inverso

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

O cliente apenas conhece o endereço do servidor proxy, pelo que o servidor real é ocultado ao cliente.

Idealmente, pode utilizar um proxy invertido como uma Firewall de Aplicação Web (WAF), que discutimos acima. É possível implementar o WAF em aplicações Web em dispositivos com o proxy invertido configurado. Como resultado, o âmbito do WAF no reforço da segurança torna-se mais alargado. O atacante também não consegue ver a localização real do servidor Web.

Pode consultar este artigo para obter mais informações fundamentais sobre proxies inversos. Na próxima secção, analisaremos a utilização de um proxy reverso para mitigar os riscos da aplicação. No entanto, antes disso, vamos dar uma visão geral do que um proxy reverso faz.

Como funciona o proxy invertido?

Todos os proxies inversos efectuam todas as operações fundamentais seguintes:

1. O browser do cliente envia um pedido HTTP para um URL público. Vamos supor que o URL seja www.host.com na porta 80.
2. Depois, como habitualmente, o nome do anfitrião é resolvido em torno do servidor proxy invertido. Este servidor proxy reverso escuta este endereço e recebe o pedido.
3. Depois disso, o proxy reverso investiga o URL para determinar onde precisa de fazer o proxy do pedido. Normalmente, um proxy reverso pode usar qualquer componente do URL para decidir para onde encaminhar o pedido. Por exemplo, pode utilizar o anfitrião, o protocolo, o caminho, a porta ou a cadeia de caracteres de consulta. Normalmente, o caminho é o principal componente que decide o encaminhamento.
   1. As definições de configuração do proxy inverso determinam o URL de saída para o qual enviar o pedido. Este URL de saída é normalmente o servidor back-end responsável pelo fornecimento dos conteúdos. O servidor proxy invertido pode reescrever as partes do pedido. Pode, por exemplo, alterar ou adicionar segmentos de rota.
   2. O proxy reverso também deve atualizar algumas das informações do cabeçalho HTTP para indicar o servidor Web interno, além de remapear o URL. O cabeçalho "Host:", por exemplo, contém o nome do host a partir do qual o URL é solicitado.
   3. Assim, para concluir o mapeamento de URL, http://www.host.com pode ser remapeado para http://realhost.com:8080.As. Neste caso, o nome do anfitrião foi alterado para realhost. Em seguida, o número da porta também foi alterado para 8080.

4. Por fim, o proxy invertido envia o pedido para o servidor real, que o processa.
5. Depois de o servidor processar o pedido, envia a resposta para o proxy invertido.
6. Em seguida, o proxy invertido faz o seguinte:
   1. Modifica a resposta para que esta seja enviada corretamente para o cliente. Isto inclui o campo "Location:", que contém a localização do ficheiro no servidor.
   2. O proxy reverso remapeia os cabeçalhos e finalmente envia a resposta ao cliente.

Como proteger a sua aplicação Web com um proxy invertido

Uma vez que o nosso objetivo é ultrapassar os ciberataques mencionados anteriormente, o proxy invertido tem de executar funcionalidades adicionais para além dos passos mencionados acima.

Validação do conteúdo do pedido

Quando um cliente envia um pedido ao servidor, o proxy invertido higieniza a entrada comparando-a com a sua base de dados de assinaturas. Os programadores desenvolvem estas assinaturas com expressões regulares altamente avançadas. A decisão do proxy inverso de autorizar o pedido com a entrada do utilizador baseia-se unicamente na abordagem do filtro da lista de bloqueio e do filtro da lista branca.

Abordagem de filtro de lista negra

O filtro de lista negra armazena os pedidos nocivos conhecidos. Em seguida, compara cada pedido com as entradas da lista. Se encontrar uma correspondência, rejeita o pedido. As diferentes variações da mesma agressão devem ser registadas separadamente na lista. 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 pedidos válidos para um site específico. Como resultado, a lista branca impede ataques, permitindo apenas que pedidos conhecidos cheguem ao servidor. O processo de construção de uma lista branca, por outro lado, é moroso e requer o conhecimento de toda a gama de pedidos legítimos que um utilizador pode potencialmente enviar para um servidor. 

Além disso, pode ser complicado criar todos os pedidos válidos para centenas de milhares de fornecedores de bases de dados em caso de injeção de SQL

Quaisquer alterações a uma aplicação Web protegida necessitariam de uma atualização da lista branca. Como resultado, manter uma lista branca aumenta a carga administrativa. 

Validação do conteúdo da resposta

Antes de enviar a resposta do servidor de volta para o cliente, o proxy reverso valida-a. Normalmente, é utilizada uma lista negra para o fazer. O filtro da lista negra pode ocultar respostas conhecidas de clientes que não precisam de as ver. As mensagens de erro são um exemplo deste tipo de dados; o proxy invertido pode substituir o erro por uma mensagem de erro genérica que não contenha dados sensíveis.

Registo de pedidos e respostas

O proxy invertido também pode registar o pedido para análise posterior. A melhor abordagem é configurar o registo apenas para os pedidos que o proxy invertido bloqueou inicialmente. Deve examinar cuidadosamente os registos durante as primeiras fases da instalação. Isso é essencial para verificar se o proxy reverso não bloqueia nenhum pedido genuíno.

Conclusão

Neste artigo, esperamos que compreenda as vulnerabilidades de uma aplicação Web e como pode utilizar um proxy invertido para resolver estas ameaças. De facto, o proxy invertido não eliminará todas as possíveis vulnerabilidades associadas às aplicações Web.

No entanto, seria uma ótima estratégia para mitigar a maioria das ameaças encontradas em uma aplicação Web. Por fim, esperamos que aplique os conceitos aprendidos neste artigo caso tenha problemas de segurança na sua aplicação Web.