O que torna os aplicativos da web um alvo fácil para hackers?

Os aplicativos da Web formam uma parte importante da superfície de ataque de uma organização e, de acordo com Relatório de investigação de violação de dados de 2020 da Verizon, os aplicativos da web são a causa mais significativa de violações de dados. Os ataques a aplicativos da Web são responsáveis por 43% de todas as violações de dados bem-sucedidas.

Esses sites contêm várias vulnerabilidades, como Execução Remota de Código (RCE), Falsificação de Solicitação do Lado do Servidor (SSRF), Inclusão de Arquivo Local (LFI), Injeção de Modelo do Lado do Servidor (SSTI) e muito mais. Algumas dessas vulnerabilidades permitem a invasão de redes corporativas. Essas vulnerabilidades são o resultado de erros cometidos por programadores. Os desenvolvedores confiam e esperam que seus aplicativos acabem nas mãos certas, o que geralmente acaba sendo o maior erro que eles já cometeram.

Nesta série de várias partes sobre aplicativos da Web, exploramos os erros e ameaças comuns que afetam os aplicativos da Web, além de apontar fatores relacionados aos aplicativos que atraem os agentes de ameaças. A primeira parte desta série de várias partes se concentra na entrada do usuário do aplicativo web e nas armadilhas de não validá-la ou higienizá-la. O artigo também esclarece as etapas que podem ser tomadas para evitar ataques a aplicativos e reduzir vulnerabilidades.

Regra #1: Nunca confie na entrada do usuário

Ao desenvolver um aplicativo, os programadores da Web devem se abster de aceitar dados dos usuários e, na verdade, devem presumir que todos os dados são ruins até que se prove o contrário. É assim que os agentes de ameaças aproveitam diferentes vulnerabilidades:

Execução remota de código

Em um caso em que a funcionalidade de upload de arquivo de imagem de um aplicativo carrega o nome do arquivo e o conteúdo em um servidor, o servidor os processa posteriormente. No entanto, se o aplicativo não validar as entradas do usuário, ele permitirá que o invasor carregue o arquivo de extensão de idioma do lado do servidor, como o .php arquivo. Isso permite ainda que o invasor execute comandos do sistema operacional no servidor.

Inclusão de arquivo local 

Da mesma forma, quando os aplicativos da web são mal codificados, os hackers podem injetar arquivos locais nas instruções de inclusão. Por exemplo, um invasor pode explorar a vulnerabilidade de inclusão de arquivos locais alterando o caminho de um arquivo PDF pelo de outro arquivo confidencial, como o passwd. Se o aplicativo não validar a entrada, o invasor pode simplesmente ler os arquivos internos do servidor.

Exemplo

URL de teste: https://vulnerable.site/somefile.php?file=validpdffile.pdf

Para 

URL de ataque: https://vulnerable.site/somefile.php?file =.. /etc/senha

Falsificação de solicitação do lado do servidor

Em um ataque que explora essa vulnerabilidade, os hackers obtêm acesso parcial ou total às solicitações enviadas pelo aplicativo, para abusar de uma funcionalidade. Isso permite que eles criem o aplicativo do lado do servidor para configurar solicitações HTTP que levam a domínios maliciosos escolhidos pelo atacante. Se o site não validar a entrada do usuário, o hacker poderá acessar arquivos internos do servidor e muito mais.

Exemplo

URL de teste: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js

Para

URL de ataque: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd

Injeção de SQL

Essa vulnerabilidade permite que hackers insiram ou injetem uma consulta em um campo de entrada para executar instruções SQL maliciosas. Isso permite que os atores recuperem dados confidenciais do banco de dados, evitando qualquer medida de segurança.

Exemplo

URL de teste:https://targetsite.com/somefile.php?id=2

No entanto, se o aplicativo da web não validar a entrada do usuário, o invasor poderá enviar algo assim:

URL de ataque: https://targetsite.com/somefile.php?id =' OU '1'='1'—+

A partir das instâncias e cenários acima, fica claro que, se a entrada do usuário não for devidamente validada ou higienizada, a maioria das vulnerabilidades dos aplicativos da web poderá ser explorada, levando a violações e perda de dados.

Como você pode reduzir as vulnerabilidades e evitar ataques

Vamos analisar o problema em questão antes de sugerirmos uma solução. O exemplo a seguir resume o problema:

Esse é um aplicativo de teste que aceita a entrada do usuário e retorna resultados com base nela.

Um usuário comum consulta tópicos como Python ou JAVA, enquanto hackers com intenção maliciosa enviariam algo assim:

Há vários símbolos que podemos injetar, como aspas simples ('), aspas duplas (“), colchetes angulares abertos e fechados (<>), iguais a (=), e colchetes abertos e fechados. Se o aplicativo da web os aceitar sem validá-los, os invasores poderão usar isso como uma arma para roubar cookies de sessão de outras pessoas, usando cargas XSS avançadas (cargas úteis de scripts entre sites).

Agora, vamos tentar entender a lógica do código:

A variável GET chamada $_OBTER no TOP aceita a entrada do usuário, o que permite que o webapp continue com esse nome de variável $vulparam. Como você deve ter notado, a variável de entrada do usuário $_OBTER não está validado. O aplicativo da web o está usando como está.

Para validar primeiro a entrada do usuário, usamos o entidades html () função que converte caracteres e símbolos em entidades HTML. Isso ajuda a evitar ataques de Cross-site Scripting (XSS) e o aplicativo web prossegue ainda mais. com a entrada codificada do usuário.

Resumo

Quase todas as vulnerabilidades do OWASP na Web são exploradas em sites do mundo real, pois os aplicativos da web não conseguem validar adequadamente a entrada do usuário antes de processá-la. Portanto, é importante que os desenvolvedores de aplicativos e os testadores de segurança colaborem regularmente entre si. Depois que o programador cria um recurso ou aplicativo específico, os testadores de segurança podem testá-lo antes de implantá-lo nos servidores de produção. Em última análise, isso economizará muito tempo e evitará qualquer perda de dados que possa ter resultado da exploração.