terça-feira, 9 de setembro de 2008

SQL INJECTION - o que é e como se proteger

Quem sabe isso possa te ajudar!
SQL Injection - O que é & Se protegendo
#######################################
Tentando explicar melhor, SQL injection, como o proprio nome ja diz,
consiste em injetar codigo nas consultas SQL feitas por sistemas web. Em
geral o objetivo é subverter o sistema e conseguir algum acesso ou
informacao para poder atacá-lo.
Em geral, a injeção acontece quando a aplicação não valida os campos
informados pelo usuário, assim como no exemplo do Rodrigo. Além disso, nao
importa a linguagem de programacao, pois trata-se de um problema de
codificacao da aplicacao.
A dica é nunca confiar nos dados passados pelo usuário, sempre validar estes
dados antes de usá-los. No exemplo do Rodrigo, o programador não fez nenhuma
verificação nos dados passados e montou uma query SQL com eles. Esse foi o
problema.

OUTRA
####
Sim, conheço muito bem esse tipo de ataque, pois já presencie um! O BD não é
culpado disso, pois de acordo com estatística, mais de 80% dos programadores
não sabem se defender de ataques, que é uma estatística preocupante!! Os
aplicativos desenvolvidos na arquitetura C/S, também estão vulneráveis!!
Para que podemos nos proteger, o mais censato é utilizar StoreProcedure,
onde o usuário que tem acesso ao sistema só tem permissão de executa-las, ou
seja, não poderá: Incluir, Alterar, Consultar, Cria tabela ou Database, em
seu BD. Realizando tarefas com o banco, apenas por StoreProcedure. E para se
pensar em segurança, nunca utilize um só camade se segurança, pois para a
entrada de dados também tem que haver validações!!
Alguns bons artigos sobre esse assunto são:
http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod87.msp
x
http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod83.msp
x
Obs.: Artigos escritos para .NET mas, a lógica seria utilizada em qualquer
aplicação, até mesmo para Desktop!!
OUTRA
####
SQL Injection afeta tb aplicações C/S e a melhor maneira de evitá-lo é
validar todos os parâmetros recebidos pela aplicação. Nesse sentido,
expressões regulares são de grande auxílio. No banco de dados uma boa
prática seria usar stored procedure parametrizada, mas é importante ficar
atendo ao código construído, um artigo interessante que aborda o tema (query
parametrizadas) é
http://dotnetjunkies.com/WebLog/chris.taylor/archive/2004/10/13/28370.aspx
OUTRA
####
SQL Injection é uma técnica que passa dados maliciosos através de parâmetros
de forma arbitrária, ou seja, injeta-se dados num parâmetro que concatenado
ao comando SQL original gera resultados diferentes dos esperados. Analise o
comando:
"SELECT Login, Nome FROM Usuario WHERE Login = '" + sParam + "'"
Se sParam receber "1' OR '2'='2" teremos o seguinte resultado:
"SELECT Login, Nome FROM Usuario WHERE Login = '1' OR '2'='2'"
Provavelmente você não terá um Login = 1, mas o OU 2=2 será sempre
verdadeiro, com isso ao invés de retornar um único, ou nenhum, resultado,
você obterá toda relação de Login e Nome da tabela Usuario.
OUTRA
####
Depende de qual linguagem que vc usa, pois em cada uma a forma de tratar
isso é distinta.. O importante é o desenvolvedor lembrar de se preocupar com
isso..
Por exemplo, em .NET, utilizo de Commands, que por sua vez tem os parametros
já tipados.. ou seja, eu não tenho que "desenhar" a query na mao, e cuidar
das aspas simples por exemplo..
Num ASP ou PHP, qdo eu tenho que montar a query de qualquer forma, eu
utilizo uma funcao que trata as aspas simples, dobrando as mesmas (qdo ver '
ele coloca '' , de forma que o banco entende que akilo é uma aspas simples
DENTRO da string e não delimitador da mesma)
Ao não conseguir quebrar a minha string, o cara não consegue injetar codigo
sql..
O mais importante é lembrar de tratar isso
Rodrigo Araujo da Silva
rodrigo.araujo@banconcsp.com.br

OUTRA
#####
Na minha opinião o "culpado" é o desenvolvedor, mas nao quero causar
polemica. Eis alguns links que podem lhe ajudar:
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf

OUTRA
####
Há uns artigos bem interessantes (e didáticos) no site da Búfalo
Informática:
http://www.bufaloinfo.com.br/Seguranca/Tecnica.asp
http://www.bufaloinfo.com.br/Seguranca/artigo.asp

OUTRA
####
Deve-se remover caracteres "coringas" como "%", tbm remover "#".
remover tbm:
"anything", "select ", "like ", "'or'", " or ", "1=1", "where ", "drop table
", "'='", " and ", ";", "order by ", "not in", " top ", "delete ", "insert
", "union all ", "union select", " FROM ", "nothing", "SysObjects", "exec ",
"syscolumns", ,"MSysACEs", "MsysObjects", "MsysQueries", "MSysRelationships"
OUTRA
####
Em alguns países como Espanha e alguns outros da Europa, quando há invasão
via sistema, é aberto uma investigação e a empresa que desenvolveu a
aplicação é processada sem dó. Lá o código de defesa do consumidor é mais
rígido e prioriza o cliente até o último.

SQL Injection - Evitando com Expressão Regular
###############################################
usar replace para esse tipo de controle não é a mais adequada e eficiente.
Use expressões regulares:
http://wagnerelias.com/2006/01/02/expressao-regular/
SQL Injection - Comandos a Barrar no post do ASP
################################################
Muitos costumam usar um filtro como este:
"DELETE,DELETE FROM,DELETE *,DROP TABLE, SHOW
TABLES,SELECT,INSERT,WHERE,UNION,LIKE,--"
SQL Injection - Exemplo
#######################
No campo user:
' or '1'='1'--
ou
'OR"='

No campo senha:
qualquer coisa
Ex: www.autocia.com.br
http://www.windowsitpro.com/Article/ArticleID/45023/45023.html

SQL Injection - Forum de Debate
###############################
http://forum.wmonline.com.br/index.php?showtopic=91546
SQL Injection - Resolvendo
##########################
Vamos a explicação prática para o erro e solução da injeção de SQL.
Primeiro, este código estaria com a vulnerabilidade:
PreparedStatement pstmt = con.prepareStatement("SELECT Login, Nome FROM
Usuario WHERE Login = '"+sLogin+"' AND Senha = '"+sSenha+"'");
pstmt.execute();
O porquê:
Está se concatenando string, realizando a formação dinâmica do SQL a ser
executado no banco.
######
O q deveria se feito:
###########
PreparedStatement pstmt = con.prepareStatement("SELECT Login, Nome FROM
Usuario WHERE Login = ? AND Senha = ?"); pstmt.setString(1, sLogin);
pstmt.setString(2, sSenha); pstmt.execute();
O porquê:
O PreparedStatement diz para o banco pré-compilar o sql passado, realizando
os testes de filtragem nos campos com os valores passados nos "set"s. Isso
é, o banco testa os valores das variáveis com os valores dos campos, e não
pré-compila o SQL com os valores vindos do usuário. Assim a injeção de SQL
é eliminada, pois não existe a possibilidade de pré-compilar os valores de
entrada juntamente com o SQL de pesquisa.
######
Outra solução, e a melhor, é chamar um procedimento armazenado (Stored
Procedure), passando os valores de entrada.

SQL Injection - Se protegendo (Artigo)
######################################
http://www.freecode.com.br/drArtigos/art_detalhe.asp?s=14405511MMSP32824IBRE
JB

SQL Injection e PHP
###################
pode-se usar a biblioteca PEAR:DB que também vai resolver o sql injection.
Grato,
Renato Jr
Reações:

0 comentários: