Bom vendo todo mundo comentar sobre Prepared Statements e tal… é bacana e é fortemente recomendada MAAAAAAAS… lembrando que utilizando você estará delegando pro BD o processamento, portanto cuidado ao utilizá-la pois em certas circunstâncias pode acarretar em perda de performance…

Mais dois cents!

[s]

sinto não ter atendido sua expectativa. eu falei dos riscos de usar as funções de escape e o que pode-se usar para bypassar estes controles. Não falei apenas das funções de ascii e char, as funções foram apresentadas como ferramenta para burlar os controles de escape.

Se você espera o passo-a-passo de como fazer isso, sinto muito, o post não é um how-to de como fazer SQL Injection, se você pegar um script e testar vai ver o que acontece.

Obrigado pelo comentário.

Serviu apenas para apresentar a função ascii e char do MySQL (que já deveria ser do conhecimento de muitos).

realmente tem muitas coisas que acabam passando despercebidas.

Obrigado pelo comentário.

eu não recomendo ficar validando, fazendo substituição de strings especificas, o melhor dos mundos é usar prepared statements e/ou fazer uma validação positiva, deixar passar apenas o conjunto de strings que você precisa e não trazem risco a aplicação.

Obrigado pelo comentário.

realmente as prepared statements são uma boa opção para tratar vulnerabilidades de SQL Injection, além do ganho de performance por elas manterem um plano de execução em cache. Eu recomendo também usar prepared statements, inclusive está no texto.

Quanto ao escape, ele tem outras necessidades, por exemplo a que foi comentada pelo Ulisses.

Obrigado pelo comentário.

Muito bom o artigo. Aposto que como eu, muita gente via essas funções do MySQL (char, ascii…) com uma certa ingenuidade.

Não sei porque usa:
“Você chegou até aqui procurando por “” através do http://www.google.com.”

Eu não cheguei aqui via Google, portanto está furado.

Falow, t+

P.s.: Ainda bem que o wordpress limita a injeção de código, você não pode ver parâmetro…

Abs.

select “codigoPHPaqui” into dumpfile “/var/www”

select “” into dumpfile “/var/www”

duh! a página removeu meu codigo php

[]‘s

além da famosa funcao char(), ainda temos a funcão hex() e a unhex(), mas as vezes nem é preciso utilizá-las, bastando converter para hex em qualquer lugar e socar na consulta ex:

select concat(user,0xa,password) from 0x6d7973716c2e75736572;

sendo:
0x6d7973716c2e75736572 == mysql.user

As funcoes que citou não protejem contra ataques de SQL Injection sem dúvida.. mas olhando para o cenário que montou PHP + MySQL elas são de grande utilidade contra duas funcionalidades que eu poderia chamar de “chave” em um ataque, que são:

select concat(user,0xa,password) from 0x6d7973716c2e75736572 into outfile “/var/www”;

OU pior…

select “” into dumpfile “/var/www”;

Tanto dumpfile como outfile EXIGEM que sejam utilizado aspas, se não utilizar as funções que falou o servidor estará desprotegido contra um possível fuzzing para procurar diretórios que estejam com permissao incorreta e subir um backdoor…

Fica as meus dois cents!

Grande abraço!