Na última semana, disponibilizamos em nossas redes sociais uma imagem contendo um pedaço de código com uma vulnerabilidade e junto, as perguntas: “Seu código é seguro?” e “Consegue apontar uma possível vulnerabilidade nesse código?”.
Hoje iremos falar um pouco mais sobre a vulnerabilidade apresentada e iniciar uma série de blog posts que tem o objetivo de conversar e explicar mais sobre desenvolvimento seguro, e como introduzir sua equipe à essa cultura.
Introdução – Entendendo um SQL Injection
SQL Injection é um tipo de ataque de injeção que possibilita a execução de instruções SQL mal-intencionadas. Essas instruções controlam um servidor de banco de dados atrás de um aplicativo da web.
Os invasores podem usar vulnerabilidades de SQL Injection para ignorar as medidas de segurança do aplicativo. Podem também executar autenticação e autorização de uma página ou aplicativo da Web e recuperar o conteúdo de todo o banco de dados SQL. Além disso, podem usar o SQL Injection para adicionar, modificar e excluir registros no banco de dados.
Uma vulnerabilidade de SQL Injection pode afetar qualquer site ou aplicativo da Web que use um banco de dados SQL como MySQL, Oracle, MS SQL Server entre outros. Os criminosos podem usá-lo para obter acesso não autorizado aos seus dados confidenciais: informações do cliente, dados pessoais, segredos comerciais, propriedade intelectual e muito mais.
Os ataques de SQL Injection são uma das vulnerabilidades de aplicativos da Web mais antigas, prevalentes e mais perigosas. A organização OWASP (Projeto de segurança de aplicativos da Web abertos) lista as injeções no documento OWASP Top 10 desde 2017 como uma das principais ameaças à segurança de aplicativos da Web.
Overview da falha
Na linha 12, o método login() chama uma consulta SQL criada com uma entrada proveniente de fonte não confiável. Essa chamada pode permitir que um invasor modifique o conteúdo da instrução ou execute comandos SQL arbitrários.
Erros de SQL Injection ocorrem quando:
- Os dados entram no programa a partir de uma fonte não confiável.
No código de exemplo, a entrada dos dados ocorre pelo método login() na linha 12.
- Os dados são usados para construir dinamicamente uma consulta SQL.
No código de exemplo, os dados são passados para a função prepareStatement() na linha 23.
Exemplo 1
O código a seguir cria e executa dinamicamente uma consulta SQL que procura por itens correspondentes ao nome especificado. A consulta restringe os itens exibidos àqueles em que o proprietário corresponde ao nome de usuário atualmente autenticado.
A consulta pretende executar o seguinte código:
No entanto, como a consulta é construída dinamicamente concatenando uma cadeia de consultas de base constante e uma entrada de usuário, a consulta só se comportará corretamente se itemName não contiver um caractere de aspas simples. Se um invasor com o nome de usuário “joao” digitar a string “name ‘OR’ a ‘=’ a” para itemName, a consulta se tornará a seguinte:
The addition of the OR ‘a’=’a’ condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:
A adição da condição OR ‘a’ = ‘a’ faz com que a cláusula WHERE seja sempre avaliada como verdadeira, dessa forma, a consulta se torna logicamente equivalente à consulta muito mais simples:
Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta retorne apenas itens pertencentes ao usuário autenticado. A consulta agora retorna todas as entradas armazenadas na tabela de itens, independentemente do proprietário especificado.
Exemplo 2
Este exemplo examina os efeitos de um valor malicioso passado para a consulta criada e executada no Exemplo 1. Se um invasor com o nome de usuário “joao” digitar a string “name”; DELETE FROM items; – “para itemName, a consulta original se tornará as duas consultas a seguir:
Muitos servidores de banco de dados, incluindo o Microsoft SQL Server, permitem que várias instruções SQL separadas por ponto e vírgula sejam executadas ao mesmo tempo. Embora essa sequência de ataques resulte em um erro no Oracle e em outros servidores de banco de dados que não permitem a execução em lote de instruções separadas por ponto e vírgula, em bancos de dados que permitem a execução em lote, esse tipo de ataque permite que o invasor execute comandos arbitrários no banco de dados.
Observe o par de hifens à direita (-), que especifica para a maioria dos servidores de banco de dados que o restante da instrução deve ser tratado como um comentário e não executado [4]. Nesse caso, o caractere de comentário serve para remover as aspas simples à esquerda da consulta modificada. Em um banco de dados em que os comentários não podem ser usados dessa maneira, o ataque ainda pode ser eficaz usando um truque semelhante ao mostrado no Exemplo 1. Se um invasor digitar a string “name”); DELETE FROM items; SELECT * FROM itens WHERE ‘a’ = ‘a “, as três instruções válidas a seguir serão criadas:
Alguns pensam que, no mundo móvel, as vulnerabilidades clássicas de aplicativos da Web, como SQL Injection, não fazem sentido – por que o usuário se atacaria? No entanto, lembre-se de que a essência das plataformas móveis é: aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de executar um malware próximo a um aplicativo bancário é alta, o que exige a expansão da superfície de ataque dos aplicativos móveis para incluir a comunicação entre processos.
Exemplo 3
O código a seguir adapta o Exemplo 1 à plataforma Android.
Uma abordagem tradicional para impedir ataques de SQL Injection é tratá-los como um problema de validação de entrada e aceitar apenas caracteres de uma whitelist, contendo valores seguros ou identificar e escapar valores de uma blacklist, contendo caracteres potencialmente maliciosos. A whitelist pode ser um meio muito eficaz de impor regras rígidas de validação de entrada, mas instruções SQL parametrizadas requerem menos manutenção e podem oferecer mais garantias com relação à segurança. Como é quase sempre o caso, a blacklist está cheia de brechas que a tornam ineficaz na prevenção de ataques de SQL Injection. Por exemplo, os atacantes podem:
- Campos de destino que não estão entre aspas
- Encontre maneiras de contornar a necessidade de certos meta-caracteres escapados
- Use procedimentos armazenados para ocultar os meta-caracteres injetados
O escape manual de caracteres na entrada para consultas SQL pode ajudar, mas não protegerá seu aplicativo contra ataques de SQL Injection.
Outra solução comumente proposta para lidar com ataques de SQL Injection é usar stored procedures. Embora as stored procedures impeçam alguns tipos de ataques de SQL Injection, elas falham na proteção contra muitos outros. As stored procedures geralmente ajudam a impedir ataques de SQL Injection, limitando os tipos de instruções que podem ser passadas para seus parâmetros. No entanto, existem muitas maneiras de contornar as limitações e muitas declarações interessantes que ainda podem ser passadas para as stored procedures. Novamente, as stored procedures podem impedir algumas explorações, mas elas não tornarão seu aplicativo seguro contra ataques de SQL Injection.
Recomendações
A causa raiz de uma vulnerabilidade de SQL Injection é a capacidade de um invasor alterar o contexto na consulta SQL, fazendo com que um valor que o programador pretenda ser interpretado como dados seja interpretado como um comando. Quando uma consulta SQL é construída, o programador sabe o que deve ser interpretado como parte do comando e o que deve ser interpretado como dados. Instruções SQL parametrizadas podem impor esse comportamento, impedindo alterações de contexto direcionadas por dados e impedindo quase todos os ataques de SQL Injection. Instruções SQL parametrizadas são construídas usando cadeias de caracteres SQL regulares, mas onde os dados fornecidos pelo usuário precisam ser incluídos, eles incluem parâmetros de ligação, que são espaços reservados para os dados que são inseridos posteriormente. Em outras palavras, os parâmetros de ligação permitem que o programador especifique explicitamente no banco de dados o que deve ser tratado como um comando e o que deve ser tratado como dados. Quando o programa está pronto para executar uma instrução, ele específica no banco de dados os valores de tempo de execução a serem usados para cada um dos parâmetros de ligação, sem o risco de que os dados sejam interpretados como uma modificação no comando.
O Exemplo 1 pode ser reescrito para usar instruções SQL parametrizadas (em vez de concatenar cadeias de caracteres fornecidas pelo usuário) da seguinte maneira:
E aqui o equivalente em Android:
Cenários mais complicados, geralmente encontrados no código de geração de relatórios, exigem que a entrada do usuário afete a estrutura da instrução SQL, por exemplo, adicionando uma restrição dinâmica na cláusula WHERE. Não use esse requisito para justificar a concatenação da entrada do usuário para criar uma sequência de consultas. Previna ataques de SQL Injection em que a entrada do usuário deve afetar a estrutura de comandos com um nível de indireção: crie um conjunto de cadeias legítimas que correspondam a diferentes elementos que você pode incluir em uma instrução SQL. Ao construir uma instrução, use a entrada do usuário para selecionar nesse conjunto de valores controlados por aplicativo.
Implicações
- Um erro comum é usar instruções SQL parametrizadas que são construídas concatenando sequências de caracteres controladas pelo usuário. Obviamente, isso anula o propósito de usar instruções SQL parametrizadas. Se você não tiver certeza de que as sequências usadas para formar instruções parametrizadas são constantes controladas pelo aplicativo, não presuma que elas são seguras porque não estão sendo executadas diretamente como sequências SQL. Investigue minuciosamente todos os usos de cadeias de caracteres controladas pelo usuário nas instruções SQL e verifique se nenhuma pode ser usada para modificar o significado da consulta.
- Vários frameworks modernos fornecem mecanismos para executar a validação da entrada do usuário. Struts e Spring MVC são dois exemplos. Para destacar as fontes de entrada não validadas, os Rulepacks da Fortify Secure Coding redefinem dinamicamente os problemas relatados pelo Fortify Static Code Analyzer, diminuindo a probabilidade de exploração e fornecendo indicadores para as evidências de suporte sempre que o mecanismo de validação da estrutura estiver em uso. Nós nos referimos a esse recurso como Classificação Sensível ao Contexto. Para auxiliar ainda mais o usuário Fortify no processo de auditoria, o grupo Fortify Software Security Research disponibiliza o modelo de projeto Validação de Dados que agrupa os problemas em pastas com base no mecanismo de validação aplicado à sua fonte de entrada.
- Fortify RTA adiciona proteção contra essa categoria.
Em breve publicaremos novos materiais como este, em que explicarei sobre outros tipos de vulnerabilidades, os ataques que elas viabilizam e claro, como corrigi-los e minimizar riscos à suas informações. Até lá, confira mais posts em nosso blog e fique por dentro de tudo o que está acontecendo por aqui.
[wp-review id=”16972″]
Referências
[1] S. J. Friedl, SQL Injection Attacks by Example, http://www.unixwiz.net/techtips/sql-injection.html
[2] P. Litwin, Stop SQL Injection Attacks Before They Stop You, MSDN Magazine, 2004
[3] P. Finnigan, SQL Injection and Oracle, Part One, Security Focus, 2002, http://www.securityfocus.com/infocus/1644
[4] M. Howard, D. LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, 2003
[5] IDS00-J. Prevent SQL Injection, CERT, https://www.securecoding.cert.org/confluence/display/java/IDS00-J.+Prevent+SQL+Injection
[6] INJECT-2: Avoid dynamic SQL, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#3
[7] INPUT-1: Validate inputs, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#5
[8] Standards Mapping – Common Weakness Enumeration, CWE ID 89
[9] Standards Mapping – DISA Control Correlation Identifier Version 2, CCI-001310, CCI-002754
[10] Standards Mapping – FIPS200, SI
[11] Standards Mapping – General Data Protection Regulation, Indirect Access to Sensitive Data
[12] Standards Mapping – MISRA C 2012, Rule 1.3
[13] Standards Mapping – MISRA C++ 2008, Rule 0-3-1
[14] Standards Mapping – NIST Special Publication 800-53 Revision 4, SI-10 Information Input Validation (P1)
[15] Standards Mapping – OWASP Mobile Top 10 Risks 2014, M7 Client Side Injection
[16] Standards Mapping – OWASP Top 10 2004, A6 Injection Flaws
[17] Standards Mapping – OWASP Top 10 2007, A2 Injection Flaws
[18] Standards Mapping – OWASP Top 10 2010, A1 Injection
[19] Standards Mapping – OWASP Top 10 2013, A1 Injection
[20] Standards Mapping – OWASP Top 10 2017, A1 Injection
[21] Standards Mapping – Payment Card Industry Data Security Standard Version 1.1, Requirement 6.5.6
[22] Standards Mapping – Payment Card Industry Data Security Standard Version 1.2, Requirement 6.3.1.1, Requirement 6.5.2
[23] Standards Mapping – Payment Card Industry Data Security Standard Version 2.0, Requirement 6.5.1
[24] Standards Mapping – Payment Card Industry Data Security Standard Version 3.0, Requirement 6.5.1
[25] Standards Mapping – Payment Card Industry Data Security Standard Version 3.1, Requirement 6.5.1
[26] Standards Mapping – Payment Card Industry Data Security Standard Version 3.2, Requirement 6.5.1
[27] Standards Mapping – Payment Card Industry Data Security Standard Version 3.2.1, Requirement 6.5.1
[28] Standards Mapping – Payment Card Industry Software Security Framework 1.0, Control Objective 4.2 – Critical Asset Protection
[29] Standards Mapping – SANS Top 25 2009, Insecure Interaction – CWE ID 089
[30] Standards Mapping – SANS Top 25 2010, Insecure Interaction – CWE ID 089
[31] Standards Mapping – SANS Top 25 2011, Insecure Interaction – CWE ID 089
[32] Standards Mapping – Security Technical Implementation Guide Version 3.1, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[33] Standards Mapping – Security Technical Implementation Guide Version 3.10, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[34] Standards Mapping – Security Technical Implementation Guide Version 3.4, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[35] Standards Mapping – Security Technical Implementation Guide Version 3.5, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[36] Standards Mapping – Security Technical Implementation Guide Version 3.6, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[37] Standards Mapping – Security Technical Implementation Guide Version 3.7, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[38] Standards Mapping – Security Technical Implementation Guide Version 3.9, APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[39] Standards Mapping – Security Technical Implementation Guide Version 4.1, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[40] Standards Mapping – Security Technical Implementation Guide Version 4.2, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[41] Standards Mapping – Security Technical Implementation Guide Version 4.3, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[42] Standards Mapping – Security Technical Implementation Guide Version 4.4, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[43] Standards Mapping – Security Technical Implementation Guide Version 4.5, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[44] Standards Mapping – Security Technical Implementation Guide Version 4.6, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping – Security Technical Implementation Guide Version 4.7, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping – Security Technical Implementation Guide Version 4.8, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping – Security Technical Implementation Guide Version 4.9, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping – Web Application Security Consortium 24 + 2, SQL Injection
[49] Standards Mapping – Web Application Security Consortium Version 2.00, SQL Injection (WASC-19)
