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


39

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?


37
culpe os tutoriais on-line mal escritos. na maioria das vezes, as pessoas simplesmente copiam e colam o código que encontram na rede. O JavaScript também é outra vítima dessa prática.
KJYe.Name

34
Culpe os blogs. Ah, e W3Schools ...
Brian Driscoll

13
Sim, absolutamente W3Schools - consulte w3fools.com
DisgruntledGoat

2
Eu sempre vejo pessoas alertando sobre a injeção de sql - então nem acho que a premissa dessa pergunta seja válida. Ele é uma alta prioridade.
GrandmasterB

3
O que estou vendo em muitas respostas é que é mais fácil ensinar PHP criticamente quebrado do que ensinar, bem, PHP que não está criticamente quebrado. Você não pode aceitar esse argumento e ainda afirmar que o PHP não é uma linguagem ruim
user16764 1/12/12

Respostas:


34

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.


8
Eu tentei corrigir essas coisas em outro lugar, apenas para saber que isso não é relevante para o problema em questão. Portanto, como muitas pessoas preferem um hack simples a uma boa solução um pouco mais complexa, maus exemplos são deixados em paz.
l0b0

6
A maioria das pessoas realmente não se importa com a injeção de SQL até serem atingidas por ela. Então, de repente, eles se perguntam para onde foram suas mesas.
Joel Etherton

1
O outro motivo é que a injeção de SQL nem sempre é vista como uma preocupação relevante para aplicativos internos. (Não que eles estão certos.)
John Fisher

1
Não esqueça que existem respostas para responder à pergunta. Frequentemente, é o pseudo-código (ou SQL) que se destina a responder à pergunta, não necessariamente fornece uma solução segura para copiar e colar (apesar de como a resposta pode ser usada na realidade).
Dalin Seivewright

1
@ l0b0 Conheço alguém que levou as pessoas a levar a sério as correções de injeção de SQL, demonstrando um ataque de injeção de SQL contra o código de produção atual.
user16764

26

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.


Como você disse, o problema não é perl ou PHP, é que essas linguagens permitem que os iniciantes façam muitas coisas, o que é bom, mas nem sempre fornecem maneiras de fazê-las bem que são tão óbvias.
Zachary K

2
@ZacharyK: Isso não é culpa do idioma, por padrão?
Lightness Races com Monica

6
@ tomalak-geretkal: Você usa a palavra "falha" como se tornar possível a realização de tarefas é uma coisa ruim. As mesmas características que levam a muitos códigos incorretos também levam a muitos problemas reais resolvidos. Não está claro que isso seja algo ruim no geral.
btilly

Re 'falta': se HTML (ou melhor, os navegadores interpretação dela) tinha sido tão tolerante a falhas como XSL, nunca teria sido um world wide web ...
Benjol

8

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".


4

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


2

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.


Eu não disse nada sobre "todos os programadores de PHP".
Lightness Races com Monica

2

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

é mais ou menos assim que eu fui ensinado php +1
Rémi

1

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.


6
Isso não deve ser um aparte. Isso deve fazer parte da lição básica. Possivelmente com um aviso grande e gordo sobre a maneira errada de fazer as coisas. As pessoas tendem a cortar e colar o que vêem pela primeira vez, e você realmente deseja que seja o caminho certo para fazer as coisas.
btilly

Certamente, no mundo .NET, a parametrização é bastante direta atualmente e deve ser realmente uma coisa da 'página um'.
Alan B

1

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.


5
Certamente é possível projetar em excesso sites com estruturas complexas que você simplesmente não precisa. Eu diria que as sugestões de Rasmus estão no ponto criminalmente perigoso, mas há definitivamente um meio termo.
Lightness Races com Monica

hoje em dia, o uso do ORM não é um excesso de engenharia; é padrão. Então, está usando o padrão MVC.
vartec

3
@artec: dificilmente é "padrão" apenas porque todas as ovelhas estão usando (e, pelo que vale a pena, nem todas as ovelhas estão usando). Para pequenos scripts, pode ser facilmente um excesso de engenharia.
Lightness Races com Monica

1
@Tomalak: é padrão, porque essa é a maneira de implementar projetos limpos e sustentáveis. "pequenos scripts" tendem a crescer com o tempo e a se transformar em monstruosidades não sustentáveis.
Vartec

2
@artec: Eu acho que você não entendeu o significado de "padrão".
Lightness Races com Monica

1

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


2
Houve um tempo em que escaparia de TODAS as variáveis ​​como se elas estivessem entrando no MySQL especificamente, se elas estavam ou não . Nota para os designers de linguagem: quando você se encontra tendo que implementar stripslashes(), já fez isso errado.
Dan Ray

0

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.


3
Desculpe, mas absolutamente nenhum exemplo de código deve misturar consultas mySQL com PHP. Isso é simplesmente fazer errado.
Raynos 26/11/11

1
E irresponsável.
Lightness Races com Monica

-1 para most tutorial code I have written has little or no error/exception checking..
yannis

Eu posso ver o ponto do OP. Irresponsável é, quando um empregador contrata alguém que não tem conhecimento sobre injeção de SQL e afins.
Raffael 27/11

Eu acho que essa abordagem é defensável se você incluir comentários diretamente no código dizendo "Não use isso na produção!". Dessa forma, as cópias / passadores não têm desculpa.
19411 Benjol

-1

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?


2
Porém, ao ensinar o idioma, você ainda deve usar as APIs preferidas em seus exemplos. Como sempre, use a forma paramétrica de consultas SQL, possivelmente com uma nota de rodapé como "Nunca pense em usar interpolação para criar SQL. Parece um pouco mais fácil, mas é extremamente propenso a vulnerabilidades de segurança".
Jan Hudec

Sim, bons pontos. As notas de rodapé seriam um bom lembrete, e isso também vale para os tutoriais online. Com toda a seriedade, porém, seria ótimo se autores de livros de todas as línguas pudessem incorporar os conselhos da OWASP nos textos iniciantes. Mesmo apenas como uma referência. A Fundação OWASP faz um bom trabalho.
Steve Rathbone

@indifferentDrum: Você também pode ensinar as pessoas a dirigir com os pés - não significa que é uma boa ideia.
Lightness Races com Monica
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.