Injecc¸ ˜ao de SQL

Umainjecc¸ ˜ao de SQL[18] ´e uma vulnerabilidade do tipo de injecc¸ ˜ao de c ´odigo (A1) [7] onde o atacante usainputsespecialmente criados de forma a enganar a base de dados para consequentemente poder executar instruc¸ ˜oes n ˜ao pretendidas pela aplicac¸ ˜ao.

Assim, um ataque de injecc¸ ˜ao de SQL ocorre quando um atacante altera a sintaxe e/ou sem ˆantica de umaquery inserindo operadores ou palavras chave SQL. Uma vulnerabilidade deste tipo tira partido da falta de validac¸ ˜ao, sanitizac¸ ˜ao ou codificac¸ ˜ao doinputdo utilizador. Os ataques sobre este tipo de vulnerabilidade que t ˆem efeito imediato sobre o comportamento do alvo s ˜ao designados de primeira ordem. Nos ataques de segunda ordem, primeiro o atacante fornece `a aplicac¸ ˜ao um input que ´e armazenado na base de dados e posteriormente, o atacante fornece um segundoinput que cria uma query para extrair aquele que estava armazenado, criando uma segundaquery modificada.

Um exemplo de um ataque de injecc¸ ˜ao de SQL de primeira ordem ´e o seguinte: uma aplicac¸ ˜ao webfaz um acesso a base de dados de forma a aceitar as credenciais (utilizador, pin) fornecidas pelo utilizador sendo o pedido `a base de dados o seguinte:

SELECT info FROM users WHERE login=’$utilizador’ AND pin=$pin

Um caso normal de funcionamento ´e o utilizador definir, por exemplo, o utilizador=Miguel e pin=1234sendo a interpretac¸ ˜ao feita pela base de dados a seguinte:

SELECT info FROM users WHERE login=’Miguel’ AND pin=1234

Pelo contr ´ario, caso o atacante fornec¸a oinput: utilizador= ’ OR 1=1 - - e qualquerpin, a instruc¸ ˜ao que vai ser interpretada na base de dados ´e:

SELECT info FROM users WHERE login=’’ OR 1=1 -- AND pin=1234

Isto vai fazer com que a base de dados interprete tudo ap ´os otokenWHEREcomo uma condic¸ ˜ao e com a inclus ˜ao deOR 1=1na cl ´ausula vai tornar esta condic¸ ˜ao uma tautologia. Como a parte posterior

est ´a comentada atrav ´es dos caracteres- - , faz com que a base de dados devolva toda a informac¸ ˜ao correspondente a tabelausers.

Apesar dos ataques de injecc¸ ˜ao de SQL serem populares h ´a quase uma d ´ecada, recentementeRay e Ligatti argumentaram que a definic¸ ˜ao de ataques de injecc¸ ˜ao de c ´odigo como os de injecc¸ ˜ao de SQL ´e problem ´atica, introduzindo o conceito de CIAO (Code-Injection Attacks on Outputs) [6].

Normalmente, uma injecc¸ ˜ao de SQL ocorre sempre que uminputde um utilizador modifica a estrutura sint ´actica dooutput de determinada aplicac¸ ˜ao. No entanto, os autores referem que esta definic¸ ˜ao tem alguns problemas, pois existem casos que este tipo de ataques n ˜ao alteram a estrutura, enquanto que h ´a casos de n ˜ao-ataques que alteram essa estrutura.

De forma a resolver esta situac¸ ˜ao,Ray e Ligatti definiram a noc¸ ˜ao de injecc¸ ˜ao de c ´odigo atrav ´es de 11 exemplos de injecc¸ ˜oes definindo quais delas s ˜ao consideradas como c ´odigo e quais n ˜ao. De seguida s ˜ao apresentados os exemplos (elementos que foram injectados naquery a sublinhado) que permitiram definir a noc¸ ˜ao de injecc¸ ˜ao de c ´odigo. Tamb ´em se pode observar na Tabela 2.1 quais dos exemplos cont ˆem injecc¸ ˜oes de c ´odigo.

1. SELECT balance FROM acct WHERE password=’’ OR 1=1 --2. SELECT balance FROM acct WHERE pin = exit();

3. ...WHERE pin = 1000>GLOBAL;

4. SELECT * FROM properties WHERE filename=’f.e’

5. ...WHERE pin = exit();

6. ...WHERE pin = aaaa();

7. SELECT * FROM t WHERE flag= TRUE;

8. SELECT * FROM t WHERE flag= aaaa;

9. SELECT * FROM t WHERE password= password;

10. CREATE TABLE t (name CHAR(40)) 11. SELECT * FROM t WHERE name=’x’

1 2 3 4 5 6 7 8 9 10 11

Ray e Ligatti Sim Sim Sim N ˜ao Sim Sim N ˜ao Sim Sim Sim N ˜ao

Tabela 2.1: Definic¸ ˜ao de injecc¸ ˜ao de c ´odigo segundo Ray e Ligatti atrav ´es de 11 exemplos explicitando em quais destes o conte ´udo injectado ´e c ´odigo (casos com Sim) ou n ˜ao (casos com N ˜ao).

Para a detecc¸ ˜ao deste tipo de vulnerabilidade existem duas formas gen ´ericas de a efectuar que s ˜ao as seguintes [18, 19, 20, 21, 22, 23]:

1. Verificac¸ ˜ao se s ˜ao utilizados operadores ou caracteres especiais da linguagem devido a falta de validac¸ ˜ao doinput [22];

2. Verificac¸ ˜ao se existe uma alterac¸ ˜ao da estrutura l ´ogica da instruc¸ ˜ao de SQL da estrutura pretendida pelo programador com o uso deinput correcto [18, 19, 20, 21, 23].

Em relac¸ ˜ao ao primeiro ponto, em [22] utilizam-se express ˜oes regulares de forma a detectar este tipo de vulnerabilidade atrav ´es da t ´ecnica detaintingpositivo. Esta t ´ecnica consiste na identificac¸ ˜ao e marcac¸ ˜ao de caracteres definidos como seguros, ao inv ´es de outras soluc¸ ˜oes que marcam os caracteres perigosos e que devem ser rejeitados. A soluc¸ ˜ao faz uma avaliac¸ ˜ao da sintaxe dasqueriesantes de serem processadas pela base de dados e bloqueia todas as que contenham pelo menos um caracter sem estar marcado. Nesta soluc¸ ˜ao utilizou-se um sistema de detecc¸ ˜ao de intrus ˜oes baseado na rede (NIDS) de forma a escutar os pacotes enviados e verificar a exist ˆencia das express ˜oes regulares no conte ´udo destes.

A soluc¸ ˜ao proposta em [22] n ˜ao ´e eficiente dado que esta soluc¸ ˜ao utiliza um NIDS de forma a escutar os pacotes observados e detectar se estes podem causar uma injecc¸ ˜ao de SQL. A soluc¸ ˜ao proposta n ˜ao garante que a aplicac¸ ˜ao n ˜ao possui mecanismos de validac¸ ˜ao e sanitizac¸ ˜ao no momento em que processa os pedidos de forma a evitar que um ataque destes ocorra e como tal n ˜ao seria vulner ´avel.

Assim, esta soluc¸ ˜ao poderia identificar que determinado pedido ´e pass´ıvel de um ataque de injecc¸ ˜ao de SQL quando na verdade seria sanitizado pela aplicac¸ ˜ao j ´a n ˜ao sendo perigoso para esta.

Em relac¸ ˜ao ao segundo ponto, existem v ´arias alternativas de detecc¸ ˜ao. A soluc¸ ˜ao apresentada por Halfond e Orso [18, 19], o sistemaAMNESIA, pretende detectar estes ataques atrav ´es de an ´alise est ´atica de c ´odigo e da monitorizac¸ ˜ao da aplicac¸ ˜ao em tempo de execuc¸ ˜ao. Esta an ´alise est ´atica consiste na identificac¸ ˜ao de pontos no c ´odigo onde se efectuamqueriesSQL de uma forma autom ´atica. De seguida para cada ponto referido anteriormente constr ´oi-se um modelo que representa todas asqueriesSQL que podem ser geradas naquele ponto atrav ´es de um aut ´omato finito n ˜ao-determinista cujas transic¸ ˜oes s ˜aotokensSQL: operadores ou caracteres da linguagem. Em tempo de execuc¸ ˜ao, a t ´ecnica monitoriza asqueriesgeradas dinamicamente e verifica se est ˜ao de acordo com o modelo est ´atico. Caso sejam diferentes, indica que o modelo gerado foi violado e como tal, classifica o pedido como um ataque.

Esta soluc¸ ˜ao, n ˜ao pode ser utilizada neste trabalho dado que efectua a detecc¸ ˜ao recorrendo a estrutura interna da aplicac¸ ˜ao, atrav ´es da an ´alise do c ´odigo, inserindo-se na categoria de teste white-box.

A soluc¸ ˜ao apresentada em [23], difere apenas da anterior em relac¸ ˜ao a estrutura de dados escolhida para fazer a comparac¸ ˜ao que ao inv ´es de utilizar um aut ´omato, efectua uma comparac¸ ˜ao entre ´arvores que representam a estrutura dasqueries.

A soluc¸ ˜ao proposta por Huang, Huang e Lin [20], pretende detectar vulnerabilidades sem aceder `a estrutura interna da aplicac¸ ˜ao alvo de teste, utilizando apenas engenharia reversa para a identificac¸ ˜ao dos pontos de entrada deinputpara a base de dados. Esta soluc¸ ˜ao baseia-se na an ´alise das respostas da aplicac¸ ˜aowebtendo em conta os seguintes aspectos:

• Exist ˆencia de erros provenientes da base de dados;

• Comparac¸ ˜ao da resposta proveniente da aplicac¸ ˜ao com outras duas: resposta proveniente de um pedido inv ´alido; resposta proveniente de um pedido ”v ´alido”, isto ´e, um pedido que contorne

todos os mecanismos de validac¸ ˜ao por parte da aplicac¸ ˜ao atrav ´es doInjection Knowlegde Manager (IKM).

O IKM ´e uma estrutura que cont ´em informac¸ ˜ao relativa aos pontos de entrada deinput para a base de dados, as vari ´aveis alvo doinput do utilizador como as suas restric¸ ˜oes, por exemplo, n ´umero de caracteres que uma determinada vari ´avel pode conter. Dado que o IKM cont ´em essas informac¸ ˜oes, consegue gerar pedidos que contornem essas restric¸ ˜oes.

Esta soluc¸ ˜ao n ˜ao ´e eficiente, dado que existem casos que a comparac¸ ˜ao das respostas pode ser inconclusiva em termos da exist ˆencia ou n ˜ao de vulnerabilidades, situac¸ ˜ao que se pretende evitar como soluc¸ ˜ao deste trabalho.

Por fim, o mecanismo de detecc¸ ˜ao proposto em [21] tamb ´em baseia-se no princ´ıpio de que uma injecc¸ ˜ao de SQL altera as estrutura dasqueriessolicitadas, como nos sistemas propostos em [18, 19, 23].

Esta t ´ecnica implementada pelo sistemaCANDIDpretende comparar a estrutura dasqueriesatrav ´es de inputscandidatos. Estesinputscandidatos s ˜ao benignos e pretendem deduzir de forma din ˆamica qual ´e a estrutura pretendida dasqueriespelo programador da aplicac¸ ˜ao num determinado ponto que recebe input proveniente do utilizador. Esta an ´alise da estrutura dasqueries ´e feita a partir da instrumentac¸ ˜ao da aplicac¸ ˜aowebpara que intercepte o processamento destes pedidos SQL.

De forma a poder-se inferir a exist ˆencia de um ataque ´e necess ´ario comparar a estrutura obtida atrav ´es doinput candidato e oinput enviado que pretende testar a aplicac¸ ˜ao. Caso a estrutura seja igual, pode-se concluir que oinput ´e v ´alido e seguro para a base de dados. Caso contr ´ario, pode indicar a possibilidade daqueleinput despoletar um ataque `a aplicac¸ ˜ao.

O sistema CANDID proposto em [21] parece ser uma soluc¸ ˜ao apropriada para o trabalho em quest ˜ao dado que efectua uma comparac¸ ˜ao dasqueriesbenignas e as que se pretendem testar e porque utiliza um mecanismo de instrumentac¸ ˜ao para analisar a estrutura queries de SQL a serem processadas na aplicac¸ ˜ao. No entanto, esta abordagem necessita que se altere a aplicac¸ ˜ao alvo e al ´em disso, a extracc¸ ˜ao das estruturas dasqueries ´e efectuada por uma ferramenta deparsingexterna ao sistema de gest ˜ao de base de dados podendo assim falhar na extracc¸ ˜ao da estrutura.