Unificado, automatizado e pronto para transformar dados em inteligência.
Ontdek hoe u de ware waarde van uw gegevens kunt ontsluiten.
A injeção de código é uma vulnerabilidade crítica que permite que um terceiro execute o código no software do servidor. A injeção de linguagem de expressão é um tipo de execução remota de código que divulga dados confidenciais do servidor. O código remoto executa e exibe variáveis, senhas, funções ou código. Na pior das hipóteses, ele pode dar a um invasor controle remoto do servidor.
A injeção de linguagem de expressão é uma vulnerabilidade que afeta as páginas do JavaServer (JSP), as páginas do Active Server (ASP) e outras linguagens de expressão hospedadas em um servidor da Web. Essas linguagens são linguagens interpretadas, portanto, qualquer código enviado ao servidor é compilado durante o tempo de execução do aplicativo, em oposição às linguagens compiladas padrão com arquivos executáveis binários. Em uma linguagem interpretada, o código é compilado no servidor quando um usuário faz uma solicitação para uma página.
Quando um aplicativo de linguagem de expressão (EL, expression language) é vulnerável à injeção de linguagem de expressão, um invasor envia código criado para o aplicativo como entrada, seja na sequência de consulta ou em um objeto de forma. O código é compilado no tempo de execução e pode exibir variáveis, senhas e outras informações confidenciais. As vulnerabilidades de EL são comuns em versões desatualizadas de linguagens interpretadas, portanto, os aplicativos legados devem ser testados quanto à penetração antes de implantá-los na produção. Depois de um evento crítico, as organizações precisam de planos de recuperação de desastres para corrigir a divulgação e as explorações de dados.
Qualquer aplicativo que execute uma linguagem interpretada deve remover o código e os caracteres especiais da entrada. Sem limpar a entrada, o aplicativo aceitará o código e o executará no servidor. A maioria das vulnerabilidades de injeção de EL envolve JSP, por isso usaremos o código JSP no exemplo a seguir. O trecho abaixo é um exemplo de uma única linha de código vulnerável à injeção de EL:
<spring:message code="${param['message']}" text=""/>Neste exemplo, o atributo de código usa um parâmetro que contém uma string. Se um invasor injetar código no parâmetro, ele será compilado e executado no servidor. Os usuários não veem esse código em sua página local da Web, portanto, os invasores usam scripts comuns para encontrar vulnerabilidades de injeção de EL.
Semelhante a qualquer vulnerabilidade de injeção, a vulnerabilidade de injeção EL não resulta de validação de entrada no aplicativo do servidor. Usando o mesmo exemplo acima, a sequência de mensagens pode ser uma sequência inocente de caracteres, mas também pode ser um código. Em vez de enviar uma sequência inocente, suponha que o usuário tenha enviado o seguinte:
${"aaaa".toString().concat(T(java.lang.Runtime).getRuntime().exec('ls -l'))}A entrada acima tenta executar o comando do sistema “ls -l” no servidor. Este comando lista os arquivos e diretórios no diretório atual. Com uma lista de arquivos, um invasor pode tentar enviar outro comando para abrir e exibir o conteúdo de um arquivo em sua janela. Um arquivo pode conter dados confidenciais, como senhas. A partir daí, o invasor poderia acessar o servidor e realizar ações maliciosas adicionais.
O teste de penetração, tanto na caixa branca quanto na caixa preta, detectará vulnerabilidades de injeção de EL. O teste White Box é um método em que os profissionais de segurança analisam o código para detectar vulnerabilidades. As empresas fornecem o código aos revisores de segurança e identificam todas as vulnerabilidades de código em um relatório. É uma abordagem proativa comum para proteção de dados.
O teste de penetração de caixa preta usa a mesma forma de varreduras e detecção de vulnerabilidade que um invasor. Os profissionais de segurança atacam o aplicativo sem conhecer o código, para que qualquer validação ou defesa possa ser testada. O teste de caixa cinza é uma combinação de teste de caixa preta e caixa branca e é frequentemente um método escolhido para teste de penetração de aplicativos da web.
A melhor maneira de detectar ataques de injeção EL é validar o código e remover a entrada com caracteres específicos. Por exemplo, a entrada para um campo nominal não deve ter caracteres “<” or “>”. Os desenvolvedores devem usar bibliotecas criadas para detectar esses caracteres e removê-los ou descartar a entrada e exibir um erro para o usuário.
Outros caracteres também podem ser maliciosos. Em uma página JSP, os trechos de código começam com os caracteres “<%” characters and end with the “%>”. Esses caracteres juntos devem ser removidos da entrada. Os invasores realizarão várias combinações de código malicioso para contornar a detecção, por isso a melhor maneira de detectá-lo é usar uma biblioteca criada para validação de entrada. Os aplicativos SIEM também podem detectar exploits e fornecer análise se seu aplicativo for um destino.
As vulnerabilidades de injeção de EL devem ser tratadas como questões críticas de segurança. Sempre teste seus aplicativos de linguagem interpretada quanto a vulnerabilidades de injeção e quaisquer outros que possam divulgar dados confidenciais. Os desenvolvedores devem usar ferramentas de validação para detectar e interromper a injeção de EL, e os aplicativos legados que usam JSP e ASP devem ser monitorados atentamente quanto a ataques.
A Pure Storage tem a infraestrutura de segurança e o monitoramento de ameaças em vigor para proteger seus aplicativos contra ataques de segurança.
Prepare-se para o evento mais valioso do ano.
Acesse vídeos e demonstrações sob demanda para ver do que a Everpure é capaz.
Charlie Giancarlo sobre o por que de gerenciar dados — e não o armazenamento — é o futuro. Descubra como uma abordagem unificada transforma as operações de TI corporativas.
Cargas de trabalho avançadas exigem velocidade, segurança e escala compatíveis com a IA. Sua pilha está pronta?