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

39

No Stack Overflow, vejo muito código PHP em perguntas e respostas que possuem consultas MySQL altamente vulneráveis a ataques de injeção de SQL, apesar de as 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?

    
por Lightness Races in Orbit 15.03.2011 / 15:11
fonte

11 respostas

34

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

    
por 15.03.2011 / 15:16
fonte
26

O PHP torna realmente muito fácil para pessoas que sabem muito pouco criar páginas web dinâmicas úteis. Isso significa que o PHP atrairá muitos iniciantes, que criarão algo útil, aprenderão com outros exemplos úteis e darão a volta para ensinar aos outros como fazer essa coisa legal e útil. O resultado é um monte de código ruim e um suprimento de programadores que não conhecem nada melhor.

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

Esta constelação exata de problemas usados para infligir 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 entendia nada sobre segurança e nem as pessoas que queriam usar suas coisas. O resultado foi o Matt Wright Script Archives, que foi um fluxo interminável de problemas de segurança para os primeiros scripts CGI. Apesar dos esforços como o link , o problema não melhorou para o Perl até que os provedores de hospedagem compartilhada tornaram o PHP mais conveniente do que qualquer outra coisa. Isso levou ao problema de passar do Perl para o PHP.

    
por 15.03.2011 / 15:58
fonte
8

Infelizmente existem toneladas de tutoriais de PHP mais do que ruins por aí e alguns livros PHP mais antigos também são difíceis de dizer para as pessoas escreverem o código (não usando register_globals etc.)

Além disso, com magic_quotes_gpc sendo ativado no passado, as pessoas não se importavam em escapar porque "simplesmente funcionava".

    
por 15.03.2011 / 15:14
fonte
4

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

    
por 15.03.2011 / 15:34
fonte
2

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

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

Com certeza, 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.

O PHP (e outras linguagens de script) de fato diminuíram a barreira à entrada. Isso pode significar que mais recém-chegados à programação experimentem o PHP primeiro. Mas isso certamente também não significa que todos os programadores PHP são menos qualificados, ou menos capazes de aprender com seus erros do que programadores de outras linguagens.

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

Suspeito que as vulnerabilidades de segurança não estão restritas a um único idioma. É tentador eliminar todos os programadores PHP de alguma forma menos capazes, ou mais propensos a escrever códigos inseguros. Mas eu me pergunto o quanto disso é preconceito de linguagem, e quanto disso é fato?

    
por 11.09.2013 / 16:41
fonte
2

Acho que parte do problema são pessoas que simplesmente copiam código sem se dar ao trabalho de aprender o que estão fazendo, mas na minha opinião a maneira como ensinamos o porgamnming está quebrada e é uma das razões pelas quais há tanto código ruim . Ensinamos a sintaxe fora do contexto e, assim, os iniciantes não sabem quando usar alguma coisa e quando não querem ou quais problemas a sintaxe pretende resolver e quais problemas ela não pretende 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 como (claramente haveria mais etapas, isso é apenas um exemplo básico de construção de problemas básicos para problemas mais complexos do que apenas ensinar 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
por 11.09.2013 / 20:31
fonte
1

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

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

Eu tenho treinado desenvolvedores por muitos anos e posso ter empatia com pessoas que escrevem código horrível em tutoriais. Às vezes isso é o mais facilmente entendido. No entanto, de um lado, eu sempre aponto o código que é vulnerável e o transformo em um tópico secundário interessante.

    
por 15.03.2011 / 16:26
fonte
1

Autor original do PHP, Rasmus Lerdorf , em sua infame entrada no blog advoca o desenvolvimento" sem framework " . Embora para consultas SQL ele use o PDO, não há risco de injeção de SQL. Ainda é bastante feio e obsoleto, comparando com estruturas MVC modernas com camadas ORMs.

    
por 15.03.2011 / 17:03
fonte
1

Você pode culpar essa prática ruim no próprio PHP. Versões legadas do PHP (até cerca de 2006) escapariam de todas as variáveis de entrada GET e POST, de modo que elas fossem adequadas para a interpolação de consulta de banco de dados BY DEFAULT. Consulte o link

    
por 17.04.2011 / 12:23
fonte
0

Não confunda o propósito de um tutorial, que é simplesmente demonstrar algo, com o que deve ser feito em um ambiente de produção. Por exemplo, a maioria dos códigos do tutorial que escrevi tem pouca ou nenhuma verificação de erro / exceção. Eu tento lembrar ao leitor que o código só demonstra como realizar uma tarefa específica, não como cobrir todos os resultados possíveis.

    
por 26.11.2011 / 04:50
fonte
-1

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

    
por 25.11.2011 / 11:51
fonte

Tags