SQL Injection e as funções de escape no php
“A maioria das técnicas para tratamento de SQL Injection fazem referência a funções de escape ou o popular magic_quotes do php, porém poucos devem saber que estas técnicas são ineficazes para evitar este tipo de ataque. A simples adição de uma barra invertida (” “) em uma string que contenha um apóstrofo (” ‘ “) não irá eliminar a possibilidade de exploração de ataques baseados em SQL Injection. (…)”
Enviado por Wagner Elias (weliasΘconviso·com·br) – referência (wagnerelias.com).
• Publicado por Augusto Campos em
2008-12-02
@brlinuxblog
Feed RSS
Caramba, pessoal, será que é tão difícil utilizar prepared statements? Elas ELIMINAM o problema de SQL Injection.
Pergunta: existe alguma vulnerabilidade na função mysql_real_escape_string()?
$data = $_POST['user_input'];
if (! ($conn = mysql_connect ())) die ("wtf?");
$query = "INSERT INTO table (field) VALUES ('" . mysql_real_escape_string ($data, $conn) . "');";
mysql_query ($query, $conn);
Fazer um site seguro é um trabalho.
Existem centenas maneiras de escapar das sql injections, principalmente se o site utilizar Ajax, isto não é algo preocupante nos dias de hj e só atinge quem ainda esta começando a programar em PHP.
Um jeito mais simples de todos para não deixar as sql injections aconteçerem é passar os parametros para outra página, colocando-a dentro de um iframe!
João Marcus,
o texto faz referência a prepared statements, é o que eu recomendo. O post é para atentar aos que confiam em funções de escape.
Douglas,
discordo completamente de você, pois atuo especificamente com segurança de aplicações e lhe garanto que muitas das aplicações que se mostram seguras tem falhas de SQL Injection. Se é apenas para iniciantes o que leva projetos open sources maduros a ter falhas como esta?
Quanto ao AJAX, não vejo o que o AJAX pode alterar/mudar referente a validação de inputs…Pode dar exemplos?
I-frame para tratar problemas de SQL Injection? Pode ser mais específico?
Grande abraço
Quanto ao AJAX, não vejo o que o AJAX pode alterar/mudar referente a validação de inputs…Pode dar exemplos?
O uso de AJAX requer maior atençao com ataques de Cross-Site Scripting e de Cross-Site Request Forgery. Na minha opinião, SQL Injection é um problema causado por amadorismo no desenvolvimento. Ataques de XSS e CSRF podem ser mais difíceis de evitar.
Agora, sobre o uso de IFrames para evitar SQL Injection… Não entendi a lógica.
atualmente o que vemos são sites grandes com falhas bobas, e ferramentas para descobrir vulnerabilidades são fáceis, qualquer garotinho com um acunetix pode fazer grandes estragos ;]
“Existem centenas maneiras de escapar das sql injections, principalmente se o site utilizar Ajax, isto não é algo preocupante nos dias de hj e só atinge quem ainda esta começando a programar em PHP.
Um jeito mais simples de todos para não deixar as sql injections aconteçerem é passar os parametros para outra página, colocando-a dentro de um iframe!”
É triste ver que existem pessoas que tem este tipo deturpado de visão e ainda tem coragem de escrever isto para outras pessoas lerem.
Centenas de maneiras de escapar de SQL Injection?
Bom, se existir o planeta realmente deveria ter mais programadores como você(ninja), pois conforme números coletados no maior banco de dados de vulnerabilidades que é o CVE (cve.mitre.org), comprovam atualmente que este tipo de falha é a mais comum que existe no mundo! Sendo numerada no TOP 10 da OWASP de 2007 como a segunda falha mais encontrada nos sites…
Só atinge quem está começando a programar em PHP?
Meu caro, para esclarecer a cada 10 sites que atendo como consultor pelo menos 8 tem falha de SQL Injection, não fale uma besteira destas, mesmo programadores experientes erram, e erram feio tentando utilizar técnicas como estas que exemplificou, vou entender “colocar as informações dentro de um iframe” como utilizar o método POST…
Uma curiosidade que surgiu foi quando você afirmou que com AJAX é possível, se puder exemplificar seria lega…
SQL Injection ou Ataques de Injeção de SQL, são sim uma preocupação ou melhor, deviria ter sido uma preocupação desde dua descoberta à 10 anos atraz, e não pense que é fácil mitigar, simplemente utilizar Prepared Statements por exemplo que dependendo do contexto em que o software ou página estiver fica inviável utilizar pois pode trazer problemas de performance…
Não sou de ficar respondendo comentário mesmo porque as vezes quando leio coisas como esta que escreveu fico imaginando se a pessoa do outro lado quer ser TROLL ou está realmente falando sério.
Mas deste vez infelizmente não pude aguentar, as pessoas PRECISAM tratar SEGURANÇA e desenvolvimento como uma coisa séria…
NUNCA!