quer ajudar? Aqui estão suas opções:","Crunchbase","Sobre nós","Obrigado a todos pelo incrível apoio!","Links rápidos","Programa de afiliados","Premium","ProxyScrape teste premium","Verificador on-line Proxy","Proxy tipos","Proxy países","Proxy casos de uso","Importante","Cookie política","Isenção de responsabilidade","Política de privacidade","Termos e condições","Mídia social","Facebook","LinkedIn","Twitter","Quora","Telegrama","Discórdia","\n © Copyright 2024 - Thib BV | Brugstraat 18 | 2812 Mechelen | Bélgica | VAT BE 0749 716 760\n"]}
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.
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.
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.
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.
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.
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.
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.
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.
Todos os sites reversos proxies realizam todas as operações fundamentais a seguir:
Como nosso objetivo é superar os ataques cibernéticos mencionados anteriormente, o proxy reverso precisa executar funcionalidades adicionais além das etapas mencionadas acima.
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.
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.
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.
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.
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.
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.