Uma função eval
por si só não é mal, e há um ponto sutil que eu não acredito que você esteja fazendo:
Permitir que um programa execute entrada arbitrária do usuário é ruim
Eu escrevi código que usava um tipo de função eval
e era seguro: o programa e os parâmetros eram codificados. Às vezes, não há recurso de linguagem ou biblioteca para fazer o que o programa precisa e executar um comando shell é o caminho curto. "Eu tenho que terminar de codificar isso em algumas horas, mas escrever Java / .NET / PHP / qualquer código levará dois dias. Ou eu posso eval
em cinco minutos."
Depois de permitir que os usuários executem o que quiserem, mesmo que estejam bloqueados por privilégio de usuário ou por trás de uma tela "segura", você cria vetores de ataque. Toda semana, algum CMS aleatório, software de blog, etc. tem uma falha de segurança corrigida onde um atacante pode explorar um buraco como este. Você está contando com toda a pilha de software para proteger o acesso a uma função que pode ser usada para rm -rf /
ou outra coisa catastrófica (note que é improvável que o comando tenha sucesso, mas falhará depois de causar um pouco de dano).
Is there any historical fact for this fear becoming part of the popular culture, instead of putting the same attention to the other possibly dangerous features?
Sim, existe um precedente histórico. Devido aos inúmeros erros que foram corrigidos ao longo dos anos em vários softwares que permitem que atacantes remotos executem códigos arbitrários, a idéia de eval
caiu em desuso. Bibliotecas e linguagens modernas têm conjuntos ricos de funcionalidades que tornam eval
menos importante, e isso não é por acaso. Isso torna as funções mais fáceis de usar e reduz o risco de uma exploração.
Tem havido muita atenção em muitos recursos potencialmente inseguros em idiomas populares. Se alguém recebe mais atenção é principalmente uma questão de opinião, mas os recursos eval
certamente têm um problema de segurança que é fácil de entender. Por um lado, eles permitem a execução de comandos do sistema operacional, incluindo built-ins de shell e programas externos que são padrão (por exemplo, rm
ou del
). Dois, combinados com outras façanhas, um invasor pode carregar seu próprio script executável ou shell e executá-lo através de seu software, abrindo a porta para que quase tudo aconteça (nada disso é bom).
Este é um problema difícil. O software é complexo e uma pilha de software (por exemplo, LAMP ) é várias peças de software que interagem entre si de formas complexas. Tenha cuidado ao usar recursos de linguagem como esse e nunca permita que os usuários executem comandos arbitrários.