Antigamente, quando o desenvolvimento da Web era baseado no fato de que os aplicativos de servidor enviavam solicitações para bancos de dados relacionais e emitiam saída HTML, esse código era frequentemente encontrado:
ou tal:
Desde então, aprendemos a usar abordagens mais seguras.
Amplamente utilizadas são ferramentas como mecanismos de modelo e ligação de parâmetros. Hoje, é raro encontrar concatenação de cordas perigosa.
Neste artigo, gostaria de compartilhar meus pensamentos sobre ataques injetando código. Aparentemente, eles ainda são uma ameaça no JavaScript.
Para entender o porquê, dividimos um dos exemplos malsucedidos em fragmentos mais simples. Assim:
function f(userInput: A): A { const firstCommand: A = ...; const secondCommand: A = ...; return firstCommand.concat(userInput.concat(secondCommand)); }
Obviamente, a
causa raiz dos ataques implementando o código é que não há diferença para um computador entre um comando e uma entrada do usuário! Portanto, um invasor pode inserir dados que serão processados como código.Naturalmente, como eu disse, existem defesas conhecidas contra esses ataques. Em vez disso:
"SELECT name FROM users WHERE login = \"" + login + "\""
melhor escrever algo como isto:
query("SELECT name FROM users WHERE login = :login", {login})
Portanto, o comando
SELECT name FROM users WHERE login =:login está claramente separado dos dados
{login} . Ao mesmo tempo, mecanismos internos garantem que os dados sejam preparados para uso em uma consulta SQL. Escapar de aspas e injetar código malicioso falhará.
No entanto, o desenvolvimento de aplicativos da web está crescendo. Não só isso é cada vez mais encontrado:
{ paramA: "the value of the A parameter", paramB: "the value of the A parameter", }
mas também isso:
{ paramA: "the value of the A parameter", paramB: {$in: [ "the value of the B parameter", "the value of the C parameter", ]}, }
Uma diferença significativa entre as duas opções é que o valor do parâmetro é um objeto que inclui um comando!
Digamos que os valores sejam lidos no
userInput :
{ paramA: userInput.paramA, paramB: {$in: [ userInput.paramB[0], userInput.paramB[1], ]}, }
Não há necessidade de se preocupar com o fato de o usuário fornecer uma string maliciosa. Tudo será tratado de maneira segura.
O problema é que os valores dos parâmetros podem ser não apenas valores simples, como
the value of the A parameter , mas também comandos, por exemplo
{$in: ["B", "C"]} . O usuário pode enviar uma solicitação de várias maneiras, após a descriptografia da qual um objeto é obtido (formulário, JSON ou XML) e, portanto, o código pode ser atacado por injeção.
Suponha que
userInput.paramA seja
{$empty: false} . Em seguida, a consulta é a seguinte:
{ paramA: {$empty: false}, paramB: {$in: [ userInput.paramB[0], userInput.paramB[1], ]}, }
Novamente, verifica-se que, para um computador, comandos confiáveis são indistinguíveis de entradas não confiáveis do usuário.
Só que agora não se trata de cadeias confiáveis e não confiáveis, mas de objetos confiáveis e não confiáveis.Para evitar esse problema, você deve sempre escrever comandos para que eles não possam ser recebidos do usuário. Isso pode ser realizado, entre outras coisas, usando a abordagem usada em
React e
Snabbdom-Signature (esta é uma pequena biblioteca para proteção contra injeção no DOM virtual), ou seja, marcando cada objeto de comando
Symbol para que ele não possa ser enviado pela rede.
Eu admito, eu próprio sempre pensei que, como não há banco de dados SQL ou se eu uso o DOM virtual, ataques por injeção de código não me ameaçam. Quão errado eu estava!
LOOKING.HOUSE - o projeto coletou mais de 150 pontos de espelho em 40 países. Você pode executar rapidamente comandos host, ping, traceroute e mtr.
