sql injection
como saber se meu software está vulnerável a sql injection? como testar isso?
se minhas consultas são feitas apenas em campos do tipo string, isolados por aspas, tem algum perigo?
Grato!
se minhas consultas são feitas apenas em campos do tipo string, isolados por aspas, tem algum perigo?
Grato!
Vitor Rubio
Curtidas 0
Respostas
Michael
24/11/2005
Olá!
SQL Injection só é problema se vc concatenar comandos SQL com strings vindas de algum componente ou controle que o usuário possa editar, como um Edit, por exemplo.
Se vc trata os dados antes de repassá-los ao banco, não há problema algum.
[]´s
SQL Injection só é problema se vc concatenar comandos SQL com strings vindas de algum componente ou controle que o usuário possa editar, como um Edit, por exemplo.
Se vc trata os dados antes de repassá-los ao banco, não há problema algum.
[]´s
GOSTEI 0
Massuda
24/11/2005
Geralmente o perigo é pegar diretamente algo que o usuário digita e montar uma SQL concatenando o que o usuário digitou com coisas válidas. O exemplo (reproduzido [url=http://msdn.microsoft.com/msdnmag/issues/04/09/sqlinjection/default.aspx]deste artigo[/url]) é uma tela de login que pede nome de usuário e senha; vamos imaginar que você está usando os valores de dois Edits na tela de login para montar uma SQL assim......se o usuário e senha for válido, essa SQL retorna 1 senão ela retorna 0. Vamos supor que você considere o login OK se a SQL não retornar zero.
O problema de SQL injection acontece quando alguém informa este nome de usuário......que faz sua SQL virar......dependendo do seu banco de dados, tudo que vir depois de ´--´ será considerado comentário, sendo ignorado. Dá para perceber que essa SQL injetada irá sempre retornar um número maior que zero desde que a tabela não esteja vazia. Pronto! Sem fazer muito esforço, alguem conseguiu fazer login no seu sistema sem ser cadastrado. Note que as strings informadas pelo usuário estão todas isoladas por aspas.
Para evitar isso você pode analisar o que o usuário digitou nos edits (por exemplo, poderia aceitar apenas letras e números no edits) ou mudar seu teste para evitar o problema.
Mais exemplos no artigo (em inglês) que citei no início.
var
SQL: string;
...
SQL := ´SELECT Count(*) FROM Users WHERE UserName="´ +
EditUsername.Text + ´" AND Password="´ +
EditPassword.Text + ´"´;O problema de SQL injection acontece quando alguém informa este nome de usuário...
" or 1=1 --
SELECT Count(*) FROM Users WHERE UserName="" or 1=1 --" AND Password=""
Para evitar isso você pode analisar o que o usuário digitou nos edits (por exemplo, poderia aceitar apenas letras e números no edits) ou mudar seu teste para evitar o problema.
Mais exemplos no artigo (em inglês) que citei no início.
GOSTEI 0
Michael
24/11/2005
Em geral, se vc usar parâmetros nos comandos SQL, e passar os dados via TFields, o Delphi irá colocar ´´ no final do valor, mesmo que tenha outras ´´ no meio. Isso elimina o problema.
[]´s
[]´s
GOSTEI 0
Massuda
24/11/2005
se vc usar parâmetros nos comandos SQL, e passar os dados via TFields, o Delphi irá colocar ´´ no final do valor, mesmo que tenha outras ´´ no meio. Isso elimina o problema.
Sim, eventuais aspas no valor serão ´escapadas´. Mas infelizmente, nem todo mundo usa SQL parametrizada, é comum ver código que monta SQL como no exemplo que passei.GOSTEI 0
Vitor Rubio
24/11/2005
se na hora de concaternar as strings pra fazer uma query, ao invés de eu concatenar assim:
eu usar a função quotedstr, asssim:
se eu fizer desse jeito, eu evito a sql injection?
var
SQL: string;
...
SQL := ´SELECT Count(*) FROM Users WHERE UserName="´ +
EditUsername.Text + ´" AND Password="´ +
EditPassword.Text + ´"´;eu usar a função quotedstr, asssim:
var
SQL: string;
...
SQL := ´SELECT Count(*) FROM Users WHERE UserName=
quotedstr(EditUsername.Text) + ´ AND Password= ´ +
quotedstr(EditPassword.Text);se eu fizer desse jeito, eu evito a sql injection?
GOSTEI 0
Massuda
24/11/2005
QuotedStr evita o problema porque ´escapa´ as aspas contidas na string.
GOSTEI 0