Por que a proteção contra injeção de SQL não é uma alta prioridade?

No Stack Overflow, vejo muitos códigos PHP em perguntas e respostas que têm consultas MySQL altamente vulneráveis ​​a ataques de injeção de SQL, apesar das soluções básicas estarem amplamente disponíveis por mais de uma década.

Existe uma razão pela qual esses tipos de trechos de código ainda estão em uso hoje?

Eu acho que é principalmente devido a) ignorância, b) preguiça. Os iniciantes geralmente não sabem muito sobre injeção de sql e, mesmo quando ouvem falar, ignoram porque é muito mais simples e fácil codificar dessa maneira.

O PHP deliberadamente torna muito, muito fácil para as pessoas que sabem muito pouco criar páginas da web dinâmicas úteis. Isso significa que o PHP atrairá muitos iniciantes, que criam algo útil, aprendem com outros exemplos úteis e se voltam para ensinar aos outros como fazer essa coisa interessante e útil. O resultado é um monte de código incorreto e uma oferta de programadores que não conhecem melhor.

Isso só piora o fato de uma grande fração de programadores competentes não querer nada com PHP. Isso reduz a base de pessoas experientes que estão dispostas a ensinar melhor aos outros. Mas por que eles evitam PHP? Bem, para uma combinação de fatores. Em parte, eles não gostam de lidar com as verrugas da linguagem. E em parte é porque eles preferem trabalhar com um bom código, e não há muito bom PHP por aí.

Essa constelação exata de problemas costumava infligir o Perl. Como um exemplo brilhante, considere o caso de Matt Wright, um adolescente entusiasmado que se propôs a fornecer muitos scripts CGI úteis, bem documentados e fáceis de instalar nos anos 90. Infelizmente, ele não entendeu nada sobre segurança e nem as pessoas que queriam usar as coisas dele. O resultado foi o Matt Wright Script Archives, que era um fluxo interminável de problemas de segurança para os primeiros scripts CGI. Apesar de esforços como http://www.scriptarchive.com/nms.html , o problema não melhorou para o Perl até que os provedores de hospedagem compartilhada tornassem o PHP mais conveniente do que qualquer outra coisa. Isso levou ao problema de mudar de Perl para PHP.

Infelizmente, existem toneladas de mais do que o mau tutoriais PHP lá fora, e alguns livros de PHP mais velhos também sugava dizendo às pessoas para escrever código adequado (sem uso de register_globals etc.).

Além disso, com magic_quotes_gpca ativação no passado, as pessoas não se preocupavam em escapar porque "simplesmente funcionava".

Pessoalmente, acredito que o PHP é fácil de usar, então naturalmente é fácil usá-lo mal.

Como humano e programador, acho incrivelmente fácil cometer erros e ignorar certas coisas, principalmente quando pressionado pelo tempo.

É fácil, e talvez muito tentador, culpar uma certa língua, por ser muito acessível para o seu próprio bem. Mas isso seria encobrir o problema maior da falibilidade humana, independentemente do idioma escolhido para a programação.

É verdade que percorremos um longo caminho desde a linguagem assembly, e acho que seria uma programação muito mais produtiva em uma linguagem mais moderna, como PHP, Python, Ruby ou Java.

PHP (e outras linguagens de script) de fato reduziram a barreira à entrada. Isso pode significar que mais novatos em programação experimentam o PHP primeiro. Mas isso certamente também não significa que todos os programadores PHP são de alguma forma menos qualificados ou menos capazes de aprender com seus erros do que os programadores de outras linguagens.

Rasmus Lerdorf criou o PHP em sua forma original em 1994 e evoluiu consideravelmente desde então. Na sua encarnação mais moderna, ele suporta programação orientada a objetos, bem como estruturas excelentes, como o Symfony. O PHP, como linguagem, se libertou de suas restrições originais e cresceu para oferecer grande flexibilidade na maneira como os programadores podem optar por usá-lo. Você pode usá-lo para criar um script de 9.000 linhas de código espaguete, ou pode ser usado no contexto de uma estrutura moderna de MVC, como o Symfony: a escolha é sua!

Eu suspeito fortemente que as vulnerabilidades de segurança não estejam restritas a um único idioma. É tentador ignorar todos os programadores de PHP como de alguma forma menos capazes ou mais propensos a escrever código inseguro. Mas me pergunto quanto disso é preconceito de linguagem e quanto disso é fato.

Acho que parte do problema são pessoas que simplesmente copiam o código sem se incomodarem em aprender o que estão fazendo, mas, na minha opinião, o modo como ensinamos a porgamnming está quebrado e é uma das razões pelas quais há tanto código ruim. Ensinamos sintaxe fora de contexto e, assim, os iniciantes não sabem quando usar algo e quando não usar ou quais problemas a sintaxe pretende solucionar e quais problemas não se destinam a resolver. Então eles usam um martelo quando uma chave teria sido a melhor ferramenta.

Então, por exemplo, em vez de ensinar apenas sintaxe, você organiza o curso da seguinte maneira (é claro que haveria mais etapas, este é apenas um exemplo básico de criação de problemas básicos a mais complexos, em vez de apenas ensinar a sintaxe):

1. É assim que você configura uma página da web básica
2. É assim que você faz a página da Web extrair dados de um banco de dados
3. É assim que você envia dados de uma página da web para um banco de dados
4. É assim que você garante que os dados corretos sejam enviados.
5. É assim que você protege seu banco de dados contra entrada de dados maliciosos

Eu acho que você encontrará uma quantidade semelhante de exemplos do MS SQL + ASP / ASP.NET que são igualmente vulneráveis.

Sinto que o problema decorre em parte do fato de que, quando você está tentando ensinar alguma coisa, digamos, filtrando dados usando uma cláusula WHERE, realmente não deseja desorganizar seu exemplo, escapando adequadamente da string de consulta ou usando um comando parametrizado.

Treino desenvolvedores há muitos anos e posso simpatizar com pessoas que escrevem código horrível em tutoriais. Às vezes, isso é o mais fácil de entender. No entanto, de lado, sempre aponto o código que é vulnerável e o transformo em um tópico interessante.

O autor original do PHP, Rasmus Lerdorf , em sua infame entrada no blog defende o desenvolvimento "sem estrutura" . Embora para consultas SQL ele use o DOP, não há risco de injeção de SQL. Ainda bastante feio e obsoleto em comparação com as estruturas MVC modernas com as camadas ORMs.

Você pode culpar essa má prática pelo próprio PHP. As versões herdadas do PHP (até cerca de 2006) escapavam a todas as variáveis ​​de entrada GET e POST, de forma que elas eram adequadas para a interpolação de consulta ao banco de dados BY DEFAULT. Veja http://php.net/manual/en/security.magicquotes.php

Não confunda o objetivo de um tutorial, que é demonstrar algo de forma simples, com o que deve ser feito em um ambiente de produção. Por exemplo, a maioria dos códigos de tutorial que escrevi possui pouca ou nenhuma verificação de erro / exceção. Tento lembrar ao leitor que o código apenas demonstra como executar uma tarefa específica, não como cobrir todos os resultados possíveis.

Quando eu estava aprendendo PHP, olhei para alguns desses livros PHP + MySQL, e sim, sinto que isso contribui para essa má prática. Mas eu tenho simpatia, porque eles estão ensinando a linguagem , não boas práticas de programação. Caso contrário, onde isso terminaria?