SQL Injection TCC Wanderson

Unisal

Wanderson Geraldo Ferreira de Paulo

Um estudo de segurança da informação:

Injeção de SQL

Lorena 2009

Unisal

Wanderson Geraldo Ferreira de Paulo

Um estudo de segurança da informação:

Injeção de SQL

Lorena 2009

Trabalho de Conclusão de Curso apresentado como exigência parcial para obtenção do grau de Bacharel em 2009 no Centro Universitário Salesiano sob a orientação do Prof. Ms. José Walmir G. Duque.

Dedico à minha mãe pelo apoio e incentivo me ajudando a alcançar esse

objetivo em minha vida, superando os momentos mais difíceis.

Aos professores que nesses anos sempre me instruíram.

A todos os amigos conquistados que de alguma forma contribuíram para a

conclusão de mais esta etapa.

AGRADECIMENTOS

Agradeço, primeiramente, a Deus que me permitiu realizar este trabalho.

Aos familiares por sempre estarem presentes em minha vida e fizeram parte

desse importante passo.

Ao meu orientador Prof. Ms. José Walmir G. Duque que decisivamente

contribuiu com seu conhecimento e experiência na evolução e conclusão desse

trabalho.

A todos os professores que nesses anos me ensinaram e contribuíram muito

para o meu crescimento.

Aos amigos que me possibilitaram grandes momentos em minha vida que

serão inesquecíveis.

Enfim, a todos que, direta ou indiretamente, me ajudaram a concluir o curso.

RESUMO

A informação é o ativo mais valioso em qualquer segmento. O grande aumento

no uso de aplicações web, um enorme volume de dados se disponibilizou na

rede mundial, não tardando para que vários riscos contra a segurança da

informação atingissem a integridade, confidencialidade e disponibilidade das

informações. Este trabalho apresenta uma técnica chamada Injeção de SQL

(SQL Injection), que dentre as várias ameaças se destaca pela facilidade de

uso e poder de domínio, usada cada vez mais por crackers que procuram

vulnerabilidades para atacar bancos de dados de sistemas que não adotaram

uma metodologia de desenvolvimento segura. A pesquisa apresenta um estudo

de caso em um sistema comercial demonstrando as suas principais falhas e

como criar barreiras para impedir o sucesso desses ataques. Concluiu-se,

primeiro, que existem muitos sistemas vulneráveis, com falhas que qualquer

usuário com conhecimento em SQL poderá invadir, pois realizando algumas

consultas foi possível descobrir informações importantes que permitiu ter

acesso privilegiado e, em segundo, entendendo como funciona o ataque pode-

se criar meios de prevenção, tanto na aplicação como no banco de dados, que

anulam o ataque dificultando a invasão e preservando a informação.

Palavras Chaves:

Injeção SQL. Segurança da Informação. Banco de Dados. Internet. Aplicação

Web.

ABSTRACT

Information is the most valuable asset in any segment. The increasing use of

web applications, a huge amount of data is available on the World, and soon so

many risks to the security of information reaching the integrity, confidentiality

and availability of information. This paper presents a technique called SQL

Injection (SQL Injection), which among the various threats stands out for ease

of use and power of domination, increasingly used by criminals who seek to

attack vulnerabilities database systems that have not adopted a safe

development methodology. The research presents a case study in a

commercial system showing major faults and how to create barriers to prevent

the success of these attacks. It is concluded, first, that exists many systems

vulnerable, with flaws that any User with knowledge of SQL can invade,

because doing some queries could find important information that allowed

privileged access, and second, understanding how works the attack can to

create means of prevention, both in the application as the database, which

suppress the attack difficulting to invasion and preserving information.

Key-words:

SQL Injection. Information Security. Database. Internet. Web Application.

LISTA DE FIGURAS

Figura 1.1 – Diagrama de sistema de armazenamento de dados.....................21 Figura 2.1 – Tela de Autenticação ....................................................................30 Figura 2.2 – Script em PHP para verificação do usuário ..................................30 Figura 2.3 – Exemplo URL................................................................................31 Figura 2.4 – Script em PHP para consulta de produto......................................31 Figura 2.5 – Tentativa de ataque pela URL ......................................................32 Figura 2.6 – Script em PHP concatenado com UNION.....................................32 Figura 2.7 – Script em PHP concatenado com DROP......................................32 Figura 2.8 – Script PHP concatenado com aspas simples ...............................33 Figura 2.9 – Código SQL para consulta de produto..........................................34 Figura 2.10 – Erro causado com uso da aspas simples ...................................34 Figura 2.11 – Versão do banco de dados .........................................................34 Figura 2.12 – Union com a tabela information_schema....................................35 Figura 2.13 – Gráfico de exploração da vulnerabilidade de Injeção de SQL ....36 Figura 3.1 – Utilizando parâmetro pela URL em PHP.......................................37 Figura 3.2 – Erro mostrando que há vulnerabilidade ........................................38 Figura 3.3 – Erro mostrando que não existe coluna 25 ....................................38 Figura 3.4 – Versão do banco de dados ...........................................................39 Figura 3.5 – Descobrindo as tabelas e colunas ................................................40 Figura 3.6 – Campo Id da tabela de Usuários ..................................................40 Figura 3.7 – Campo Nome da tabela de Usuários ............................................41 Figura 3.8 – Campo Senha da tabela de Usuários ...........................................41 Figura 3.9 – Usuário e senha válida .................................................................41 Figura 3.10 – Tela de Login do sistema............................................................42 Figura 3.11 – Tela principal com usuário Identificado.......................................43 Figura 3.12 – Tela de Login com Código SQL..................................................44 Figura 3.13 – Código PHP com a função addslashes.......................................46 Figura 3.14 – Código PHP com a função strtr...................................................47 Figura 3.15 – Código PHP com a função mysql_real_escape_string ...............48 Figura 3.16 – Verificação do tipo da variável em PHP......................................48 Figura 3.17 – Função em PHP para validar String............................................49

LISTA DE TABELAS

Tabela 1.1 – Surgimento e evolução da SQL................................................... 15

Tabela 1.2 – Evolução dos Bancos de Dados.................................................. 19

Tabela 2.1 – Alguns caracteres utilizados no ataque....................................... 28

SUMÁRIO

INTRODUÇÃO..................................................................................................12

1 FUNDAMENTOS DE BANCO DE DADOS E LINGUAGEM DE CONS ULTA..........................................................................................................................14

1.1 – HISTÓRIA DO SQL ..................................................................................14 1.2 – APLICABILIDADES DA LINGUAGEM SQL..............................................15 1.2.1 – DIVISÕES DO SQL ...............................................................................16 1.2.1.1 – DDL – LINGUAGEM DE DEFINIÇÃO DE DADOS ............................16 1.2.1.2 – DML – LINGUAGEM DE MANIPULAÇÃO DE DADOS .....................16 1.2.1.3 – DCL – LINGUAGEM DE CONTROLE DE DADOS............................17 1.3 – SGBD E BANCO DE DADOS ...................................................................18 1.3.1 - HISTÓRIA DO BANCO DE DADOS .......................................................18 1.3.2 - O QUE É BANCO DE DADOS................................................................20 1.3.3 - O QUE É SGBD......................................................................................20 1.3.4 – POR QUE USAR BANCO DE DADOS...................................................21 1.3.5 – SGBD NOS DIAS ATUAIS.....................................................................21 1.4 – SEGURANÇAS DOS DADOS ..................................................................22 1.4.1 – POSSÍVEIS DANOS..............................................................................23 1.4.2 – ATITUDES A SEREM TOMADAS..........................................................23

2 APLICAÇÕES WEB E INJEÇÃO DE SQL.................................. ..................25

2.1 – APLICAÇÕES WEB..................................................................................25 2.1.1 – DESENVOLVIMENTO WEB..................................................................26 2.1.2 – CONEXÃO COM BANCO DE DADOS...................................................26 2.1.3 – DESENVOLVIMENTO SEGURO ..........................................................26 2.2 – SQL INJECTION ......................................................................................27 2.2.1 – CARACTERES ESPECIAIS ..................................................................28 2.2.2 – O ATAQUE............................................................................................29 2.2.3 – ADVANCED SQL INJECTION...............................................................33 2.2.4 – OBTENDO INFORMAÇÕES .................................................................33 2.2.5 – ESTATÍSTICA .......................................................................................35

3 UM ESTUDO DE CASO DE SEGURANÇA DA INFORMAÇÃO ..... .............37

3.1 – ATAQUE PELA URL.................................................................................37 3.2 – ATAQUE PELO FORMULÁRIO DE LOGIN ..............................................43 3.3 – DEFESA DO SISTEMA ............................................................................44 3.3.1 – ENTENDENDO O ATAQUE ..................................................................45 3.3.2 – TÉCNICAS DE DEFESA NA APLICAÇÃO ............................................45 3.3.2.1 – TRATANDO OS DADOS DE ENTRADA ...........................................45 3.3.2.2 – TRATANDO OS DADOS DE SAÍDA..................................................50 3.3.3 – TÉCNICA DE DEFESA NO BANCO DE DADOS...................................51

4 CONSIDERAÇÕES FINAIS............................. ..............................................54

GLOSSÁRIO .......................................... ..........................................................56

REFERÊNCIAS ................................................................................................57

12

INTRODUÇÃO

Essa pesquisa tem como tema a Prevenção à Injeção de Código SQL e

se insere na área de segurança da informação, destinado para sistemas que

utilizam conexão com banco de dados.

Este trabalho tem por objetivo realizar um estudo de caso de Injeção de

SQL, um ataque que cada vez mais se destaca principalmente pela sua

facilidade de execução e pelo alto poder de domínio, apresentando algumas

estratégias de defesa em uma aplicação web.

A informação de qualquer empresa é o bem mais precioso que ela

possui, podendo ser levada à falência caso perca tais informações. Assim um

usuário mal intencionado pode, através das técnicas desse ataque, invadir os

sistemas desprotegidos e roubar, alterar, inserir ou excluir qualquer informação.

Para a execução do ataque é necessário apenas um navegador e

conhecimento da linguagem SQL, sendo através da URL (Uniform Resource

Locator) ou de algum campo login ou senha, que é inserido o código

inesperado pelo desenvolvedor.

Ao final desse trabalho será possível compreender melhor essa técnica

e incluir junto ao desenvolvimento de novos sistemas uma metodologia mais

segura dificultando as tentativas de invasões. Para elaboração do presente

foram pesquisados vários autores como Oliveira, Date, Albuquerque entre

outros.

Pretende-se, para tal objetivo, primeiramente realizar um estudo sobre

banco de dados e a Linguagem SQL (Structured Query Language) do ponto de

vista de segurança. Logo em seguida, serão estudadas as técnicas mais

usadas em ataques a bancos de dados bem como sua demonstração. Para

isso serão feitos testes em aplicativos com códigos desprotegidos que

possibilitarão ter controle do sistema ou, mesmo sem ter acesso com

permissão de administrador, poder executar ações diretamente no banco de

dados. Pretende-se também, por implementação, demonstrar as técnicas para

anular os ataques.

O trabalho está divido em três capítulos. O primeiro descreve um pouco

do histórico dos Bancos de Dados e da linguagem SQL, como surgiu, a

evolução e os motivos que os fizeram ter a importância de hoje, assim como

13

são relatados alguns conceitos de segurança. O segundo capítulo é dividido

em duas partes, onde a primeira aborda desenvolvimento web como as

tecnologias, práticas de desenvolvimento e a conexão com o banco de dados e

na segunda parte o SQL Injection como suas características, funcionamento e

alguns exemplos. E por fim, no terceiro e último capítulo, é abordado

especificamente o ataque, é demonstrada a técnica em funcionamento

explorando o que é possível fazer na base de dados e logo em seguida as

atitudes que deverão ser tomadas, via programação, para anular o ataque.

14

1 FUNDAMENTOS DE BANCO DE DADOS E LINGUAGEM DE CONSULTA

Neste primeiro capítulo será abordada a história dos bancos de dados e

da linguagem utilizada por eles, o SQL. O objetivo é demonstrar alguns

aspectos históricos, desde o surgimento até os dias atuais, sua utilização,

importância e principalmente a ligação existente entre ambos que os fazem

serem tão poderosos e indispensáveis no dias atuais.

1.1 – HISTÓRIA DO SQL

A origem da linguagem que hoje é denominada SQL (Structured Query

Language ou Linguagem de Consulta Estruturada), se deu com um estudo

sobre banco de dados relacionais, onde o objetivo era permitir que usuários

armazenassem e recuperassem grande quantidade de informações. Sendo

publicado em um artigo intitulado “A Relational Model of Data for Large Shared

Data Banks” (Um Modelo Relacional de Dados para Grandes Bancos de Dados

Compartilhados), no jornal Association of Computer Machinery, por Edgar

Frank Codd em 1970, membro do Laboratório de Pesquisa da IBM, em San

Jose, Califórnia.

A primeira versão da linguagem foi criada pela IBM e muitas de suas

características usam os conceitos da álgebra relacional de Codd, durante o

desenvolvimento do sistema R, surgindo assim o SEQUEL (Structured English

Query Language). Com a evolução da SEQUEL veio o surgimento do SQL. Em

1979, a Relational Software Inc., hoje Oracle Corporation, lançou a primeira

versão comercial da linguagem.

Hoje a SQL é largamente usada para a manipulação dos dados em um

banco de dados, desta maneira, as organizações ANSI (American National

Standards Institute) e ISO (International Standards Organization), especificou a

linguagem como padrão dos bancos de dados relacional (Date, 2004), onde o

primeiro padrão foi definido em 1986, o SQL-86, baseado no SQL da IBM. Em

1989 uma nova padronização foi publicada pela ISO incluindo recursos como

integridade de referência e os valores NULL e DEFAULT. A linguagem passou

15

por aperfeiçoamentos e, em 1992 foi publicada a terceira versão do padrão

SQL, o SQL-92 ou SQL2. Um novo padrão, chamado de SQL-99, conhecido

também como SQL3, foi lançado em 1999 com novas características, sendo a

mais importante a adição de orientação a objetos. E a mais nova versão do

padrão da linguagem SQL é a SQL2003, sendo adicionado o tratamento de

XML (Costa, 2006).

A Tabela 1.1 abaixo mostra o surgimento e a evolução da SQL.

SEQUEL (1970) Publicação do artigo de Codd pela IBM

SQL (1979) 1ª Versão comercial – ORACLE

SQL-86 (1986) 1º Padrão especificado pela ANSI e ISO

SQL-89 (1989) 2ª Versão com novos recursos especificados pela

IBM, ANSI e ISO.

SQL-92 ou SQL-2 (1992) Publicada a 3ª versão especificada pela ANSI e

ISO

SQL-99 ou SQL-3 (1999) Novo padrão com orientação a objetos

SQL:2003 (2003) 4º Versão com tratamento de XML

Tabela 1.1 – Surgimento e evolução da SQL

Fonte: Próprio Autor

1.2 – APLICABILIDADES DA LINGUAGEM SQL

A SQL é a linguagem padrão de sistemas de banco de dados que serve

tanto para manipulação quanto para a definição de dados, sendo bem diferente

das linguagens de programação, principalmente por não ser possível criar

programas executáveis, mas sua simplicidade, facilidade e suficiência no trato

com banco de dados, fez com que as melhores e mais recentes linguagens de

programação suportassem esses recursos em todas suas funções. Em SQL

não se especifica como ou em que ordem serão executadas os comandos que

irão fornecer os resultados esperados, e sim, informamos o que se quer e o

sistema de banco de dados é o responsável por escolher adequadamente os

procedimentos a serem executados, de forma que os resultados sejam obtidos

com a maior eficiência possível.

16

1.2.1 – DIVISÕES DO SQL

SQL é dividido em grupos, ou sub-linguagens, para melhor definir a

linguagem. Cada grupo tem sua função específica responsável por partes

distintas na linguagem.

1.2.1.1 – DDL – LINGUAGEM DE DEFINIÇÃO DE DADOS

O grupo DDL (Data Definition Language ou Linguagem de Definição de

Dados) possibilita ao usuário criar, alterar ou excluir componentes. A maioria

dos sistemas de banco de dados aceita os comandos DDL.

• CREATE – cria um objeto na base de dados.

Sintaxe: CREATE [objeto] [nome_objeto];

Exemplo: CRETAE table aluno;

• ALTER – altera um objeto na base de dados.

Sintaxe: ALTER TABLE (ação) [nome_tabela] (parâmetros);

Exemplo: ALTER TABLE add column aluno varchar(50);

• DROP – exclui um objeto na base de dados.

Sintaxe: DROP [objeto] [nome_objeto];

Exemplo: DROP TABLE aluno;

1.2.1.2 – DML – LINGUAGEM DE MANIPULAÇÃO DE DADOS

O grupo DML (Data Manipulation Language ou Linguagem de

Manipulação de Dados), como o próprio nome diz, possibilita a manipulação, o

que compreende as operações de selecionar, inserir, apagar ou atualizar os

dados nos bancos de dados.

“A SQL DML abrange uma linguagem de consulta baseada tanto na

álgebra relacional quanto no cálculo relacional de tuplas.” (Silberschatz, Korth,

Sudarshan, 1999, p.110).

• SELECT – seleciona uma ou várias linhas de registros, formando as

conhecidas query (consultas) de resultado. Este é o comando mais

utilizado em conjunto com as cláusulas de condições.

17

Sintaxe: SELECT [campos] FROM [tabela] WHERE [condição]

[parâmetros]

Exemplo: SELECT id_aluno, nome FROM aluno

WHERE idade_aluno > 16 ORDER BY nome ASC

• INSERT – insere novos registros nas tabelas do banco de dados,

permitindo inserir vários dados em uma única execução do comando.

Sintaxe: INSERT INTO [tabela] [campos] VALUES [valores]

Exemplo:

INSERT INTO aluno (id_aluno, nome, idade_aluno)

VALUES (‘01’, ‘aluno A’, ‘17’);

• UPDATE – atualiza os registros existentes nas bases de dados.

Combinado com as cláusulas de condições, permite fazer alterações em

vários registros com uma única execução.

Sintaxe: UPDATE [table] SET [campo] = [valor] WHERE [condição]

Exemplo: UPDATE aluno SET idade_aluno = ‘aluno B’

WHERE id_aluno = ‘01’

• DELETE – remove linhas de registros de uma tabela do banco de dados,

usando as cláusulas de condições para definir quais as linhas serão

afetadas ou não.

Sintaxe: DELETE FROM [tabela] WHERE [condição]

Exemplo: DELETE FROM aluno WHERE id_aluno = ‘01’

1.2.1.3 – DCL – LINGUAGEM DE CONTROLE DE DADOS

O grupo DCL (Data Control Language ou Linguagem de Controle de

Dados) controla a segurança interna da base de dados, sendo as permissões

destinadas aos usuários para controlar quem tem acesso para visualizar ou

manipular os dados.

• GRANT – permite ao usuário executar operações.

Sintaxe: GRANT [parâmetro] [tabela] [parâmetro] [grupo/usuário]

Exemplo: GRANT SELECT ON aluno TO GROUP professores

• REVOKE – anula privilégios do usuário, é o contrário ao GRANT.

18

Sintaxe: REVOKE [parâmetro] [tabela] [parâmetro] [grupo/usuário]

Exemplo: REVOKE ALL ON aluno TO usuário

1.3 – SGBD E BANCO DE DADOS

Algumas pessoas fazem confusão na distinção entre banco de dados e

SGBD. Na verdade ambos trabalham juntos, mas, a seguir apresentam-se o

detalhamento e a função de cada um.

1.3.1 - HISTÓRIA DO BANCO DE DADOS

Entre as décadas de 50 e 60, o armazenamento e acesso aos dados

eram feitos através de arquivos de texto, de maneira bem simples com os

campos de tamanho fixo e o acesso era apenas através de leitura de arquivos.

Enquanto isso, iniciativas de projetos mais avançados estavam em andamento

por grupos restritos de pessoas em busca de melhorar essa situação,

percebendo que o modo usado até então não era eficiente e nem, tampouco,

seguro.

Em 1963 os Estados Unidos da América formaram a conferência

"Development and Management of a Computer-Centered Data Base"

("Desenvolvimento e Gerenciamento de um Banco de Dados para

Computadores") onde o termo base de dados foi definido como “Um conjunto

de arquivos (tabelas), onde um arquivo é uma coleção ordenada de registros

(linhas), e um registro consiste em uma ou mais chaves e dados”.

Segundo Date (2004) um banco de dados “é um conjunto de dados

constantes utilizados por aplicações”.

O grupo formado nos EUA no ano de 1971 descreveu o Modelo de

Dados em Rede, onde o banco de dados é uma coleção de registros

conectados uns ao outros por meio de links, modelo que definiu muitos

conceitos importantes para a definição de outros bancos de dados, inclusive o

Modelo Relacional, muito utilizado nos dias atuais.

19

No mesmo período, as empresas IBM, North American Rockwell e a

Caterpillar Tractor se uniram para o desenvolvimento do ICS – Information

Control System (Sistema de Controle de Informações) que seria o banco de

dados responsável pelo armazenamento e recuperação dos dados, e da DL/I –

Data Language/I (Linguagem de Dados/I) que era a linguagem de consulta

necessária para acessar os dados. Ambos, o ICS e a DL/I, iriam auxiliar em um

projeto de construção de uma espaçonave que estava acontecendo.

O Modelo de Dados em Rede e o DL/I da IBM foram um marco

fundamental, definindo um modo pelo qual, separavam os dados e o código da

aplicação esboçando o banco de dados.

No ano de 1976, pelo Dr. Peter Chen, foi criado o Modelo de Entidade-

Relacionamento (MER) com a finalidade de representar as estruturas de dados

de uma forma mais natural e mais próxima do mundo real dos negócios.

Na década de 80 o System R (Sistema R), foi o primeiro banco de dados

relacional da IBM, que depois deu lugar ao chamado SQL/DS que foi

disponibilizado comercialmente e de acordo com Silberschatz, Korth e

Sudarshan (1999) este foi o primeiro modelo de dados incorporado para

aplicações comerciais. Nos anos seguintes a evolução continuou surgindo

novas alternativas reconhecidas até hoje, por exemplo, o Microsoft SQL Server,

MySQL, PostgreSQL e Oracle.

A Tabela 1.2 a seguir mostra a evolução dos Bancos de Dados.

Década de 50 e 60 Armazenamento de dados em arquivo texto.

Conferência nos EUA

(1963)

Definido o termo Base de Dados.

Modelo de Dados em

Rede, ICS e DL/I (1971)

EUA e IBM tiveram um marco fundamental no

esboço do banco de dados.

MER (1976) Peter Chen cria o Modelo de Entidade-

Relacionamento.

Sistema R (1980) Primeiro banco de dados da IBM.

SQL Server (1988) Primeira versão do SQL Server da Microsoft.

MySQL (1995) Primeira versão do MySQL.

Tabela 1.2 – Evolução dos Bancos de Dados


20

1.3.2 - O QUE É BANCO DE DADOS

“Banco de dados é o conjunto de dados integrados que tem por objetivo

atender a uma comunidade de usuários.” (Heuser, 2001, p. 3).

Primeiramente, deve-se compreender a noção de dado.

Um dado é uma parte da informação que, sem estar em conjunto com

outros dados, não tem utilidade. Assim, um conjunto de dados forma uma

informação que, se estiver bem estruturada, possibilita ao usuário tomar

decisões importantes.

Basicamente, um dado é um conjunto alfanumérico, ou de imagem, que não está agregado a nenhum conhecimento específico, tornando-o inutilizável para quem não souber em qual contexto está contido e o que exatamente representa, não podendo interpretá-lo. (Milani, 2008, p.312).

1.3.3 - O QUE É SGBD

Os SGBD, acrônimo de Sistemas Gerenciadores de Banco de Dados

são basicamente sistemas computadorizados de manutenção de registros, com

finalidade de armazenar informações e permitir que os usuários busquem e

atualizem essas informações quando for necessário, ou seja, o principal

objetivo de um SGBD é prover um ambiente que seja adequado e eficiente

para recuperar e armazenar informações do banco de dados.

SGBD foram projetados para gerenciar grandes grupos de informações,

armazenando de forma lógica e organizada os dados juntamente com a

linguagem SQL, o SGBD se tornou uma ferramenta muito poderosa capaz de

arquivar enormes quantidades de dados, permitindo com facilidade e agilidade

consultar a informação que for necessária ao usuário, sendo assim, gerir os

mais variados tipos de dados e tamanhos.

Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado de banco de dados, contém informações sobre uma empresa em particular (Silberschatz, Korth, Sudarshan, 1999, p.1).

21

A Figura 1.1 a seguir é um diagrama de um sistema completo para

armazenamento de dados com a base de dados, SGBD e aplicativo para uso

do usuário.

Figura 1.1 – Diagrama de sistema de armazenamento d e dados

Fonte: http://acdtecnologia.files.wordpress.com/200 8/04/banco-de-dados.jpg

1.3.4 – POR QUE USAR BANCO DE DADOS

Os bancos de dados foram desenvolvidos para guardar dados de forma

lógica e organizada e facilitar o acesso aos mesmos a qualquer momento que

seja requisitado pelos usuários.

Um SGBD pode possibilitar para as pessoas, muitas vezes com pouco

conhecimento na linguagem SQL, usufruir dos dados fazendo as consultas,

alterações, inclusões ou exclusões.

1.3.5 – SGBD NOS DIAS ATUAIS

Houve muita evolução dos Sistemas Gerenciadores de Banco de Dados

desde o seu surgimento até os dias atuais, passando por várias modificações

22

que agregaram mais valor aos sistemas, novos recursos e melhorias que os

tornaram nos dias de hoje uma ferramenta indispensável para o uso nas

organizações, pois a preservação e organização dos dados são fundamentais

para o funcionamento de qualquer empresa.

Há empresas que utilizam apenas um sistema de banco de dados, mas

há também aquelas que preferem vários sistemas independentes, por exemplo,

um sistema para cada setor.

Existem vários meios de se utilizar os bancos de dados, o mais usado é

o modo cliente/servidor, onde o banco é instalado no servidor da empresa e as

máquinas clientes fazem o acesso, podendo executar as operações de acordo

com as permissões definidas pelas regras de segurança.

1.4 – SEGURANÇAS DOS DADOS

Uma das maiores preocupações na área da informática e em toda a

empresa, inclusive da alta administração, é a questão de segurança. As

medidas adotadas nas organizações tendem a evitar catástrofes físicas como

incêndios ou desabamentos, isto porque o prejuízo em equipamentos é

altíssimo, mas tanto quanto ou mais importante que os equipamentos são as

informações. Portanto, não são somente os desastres físicos que colocam em

risco a vida da empresa, é preciso prevenir também outros agentes não físicos,

internos e externos, que são tão perigosos como os demais.

O risco de crimes virtuais através de computadores está cada vez mais

constante ameaçando o “tesouro das empresas”.

O único sistema totalmente seguro é aquele que não possui nenhuma forma de acesso externo, está trancado em uma sala totalmente lacrada da qual uma única pessoa possui a chave. E esta pessoa morreu ano passado (Oliveira, 2001, p.11).

Com o avanço da internet, cresceu muito o uso de sistemas web,

tornando esses sistemas, de modo geral públicos, ao qual qualquer pessoa no

mundo consegue ter acesso, o que, conseqüentemente, também os deixa

vulneráveis a ataques mal intencionados.

23

A segurança em banco de dados diz respeito à proteção do banco de

dados, protegendo as informações nele contidas contra ataques intencionais ou

não, utilizando-se de meios computacionais e não computacionais para

preservá-los.

Partindo do princípio definido pelo autor Edson Luiz Riccio (1981) em

sua dissertação de mestrado “Segurança e Processamento de Dados” ao dizer:

“Qualquer que seja o controle adotado, as chances de serem ineficazes são

bastante grandes e, portanto o risco estará sempre presente”.

1.4.1 – POSSÍVEIS DANOS

Muitos são os resultados negativos após ter o sistema invadido por

pessoas maliciosas. Dados podem ser apagados ou alterados levando

empresas a desordem total, ficando perdidas no meio de informações

inconsistentes, sem saber o que de fato é real. Vários podem ser os efeitos

dessas invasões, que podem ultrapassar os limites da empresa e afetar seus

clientes, fornecedores e parceiros.

Imaginar um acesso malicioso aos dados pessoais dos clientes que são

sigilosos, como todos os dados da empresa, é desastroso pois, são dados que

não são somente relacionados a organização, mas principalmente dizem

respeito a vida particular desses clientes.

Ou seja, isso pode sair muito caro fazendo as empresas gastarem muito

dinheiro para tentar reverter essa situação ou mesmo a levar para a falência

forçando seu fechamento como já ocorreu com várias organizações, provando

que por falta de atitudes dos responsáveis toda essa queda poderia ter sido

evitada. (Oliveira, 2001).

1.4.2 – ATITUDES A SEREM TOMADAS

Todos os administradores de sistemas realizam, ou deveriam realizar,

cópias de segurança de todo o sistema. Fazer a cópia da base de dados em

meios que estejam fora do prédio da empresa é uma maneira de se poder

24

recuperar os dados caso alguma tragédia aconteça. Essa tarefa é algo que

deve entrar para a rotina do setor responsável, normalmente o departamento

de Teconologia da Informação, pois se for perdida a base de dados por

qualquer motivo que seja, para a empresa voltar aos trâmites normais com

certeza vai ser necessário restaurar os dados, e mesmo assim é bem possível

que seja perdida alguma informação por causa do intervalo de tempo que há

entre uma execução da cópias de segurança e outra.

Criar um programa de segurança é uma tarefa dinâmica que envolve diversas etapas. O seu ponto de partida é formular uma situação de conectividade à internet na qual os objetivos dessa conexão são claramente articulados. (Bernstein; et al, 1997, 59p).

Existem inúmeras maneiras de ajudar na prevenção. Métodos como

antivírus, proxy e firewall também são muito importantes para manter a

consistência do sistema, mas, para dificultar mais ainda o sucesso de crackers

na tentativa de invasão, os administradores de banco de dados têm a total

liberdade de limitar o acesso dos usuários aos dados, permitindo somente o

direito de leitura para os que necessitam apenas consultar as informações, e a

permissão de modificar dados somente para os que realmente necessitam.

Essas formas computacionais, nas quais através de meios informatizados é

aumentada a barreira de proteção da base de dados, que além de dificultar o

acesso indevido a pessoas não autorizadas, também ajuda a prevenir

acidentes involuntários, causados, por exemplo, por pessoas leigas no assunto

que, mesmo sem a intenção de prejudicar, acaba excluindo ou alterando algum

registro.

Em síntese, durante o passar do tempo, nos últimos anos, a área de

tecnologia da informação vem evoluindo muito e, como na informática o leque

de opções é imenso, não haveria como todos os seus segmentos não terem se

expandido, como pôde ser visto na linguagem SQL e Banco de Dados, bem

como histórico, uso e segurança de dados.

25

2 APLICAÇÕES WEB E INJEÇÃO DE SQL

O ataque pode ser utilizado em diversos sistemas independente de

plataforma, mas os atacantes preferem a plataforma web por ser possível ter o

acesso de qualquer lugar do mundo que haja uma conexão com a internet, com

esse propósito este capítulo trata dois itens de grande relevância no trabalho,

as aplicações web e a injeção de SQL.

2.1 – APLICAÇÕES WEB

As aplicações podem ser web ou arquitetura cliente-servidor. Nas

aplicações com a arquitetura cliente-servidor, a instalação da aplicação é feita

em todas as máquinas clientes (interface para o usuário), acarretando uma

perda de tempo cada vez que havia uma atualização, pois, para manter os

clientes atualizados era necessária que em todas as máquinas fosse atualizada

a versão do sistema. Após o surgimento da internet, uma rede constituída de

várias redes de proporção mundial, as aplicações web ficaram mais acessíveis

dispensando a instalação micro a micro, com essa nova arquitetura, se pode

acessar uma aplicação web através de algum navegador e, quando há

atualizações, as alterações são apenas no servidor, sem a percepção dos

usuários, pois a aplicação não fica instalada em sua máquina.

Com o passar do tempo, surgiu a necessidade da construção de aplicações com a função de reconhecer novos tipos de informações vindas dos usuários, comunicar-se com outros sistemas, como um banco de dados, além de manter inúmeras páginas da Web site rapidamente atualizadas. (Aquino, 2006, p.31)

O mundo da internet evoluiu muito desde o seu surgimento, passando

por várias etapas, da web estática à web dinâmica onde começou a ter funções

interessantes que interagem com o usuário tendo maiores atrativos. Entre

essas funções está a comunicação com banco de dados, guardando

informações para todos os fins como cadastro básico até dados corporativos de

empresas que possuem todos os seus registros na web.

26

2.1.1 – DESENVOLVIMENTO WEB

As aplicações web tiveram uma crescente evolução devido à

portabilidade que é oferecida aos usuários, pois a preferência é bem maior em

poder acessar um sistema web site de qualquer computador ou até mesmo de

dispositivos portáteis como celulares do que acessar um sistema desktop que

está instalado em um computador específico.

Existem várias maneiras de se criar páginas web, várias linguagens de

programação podem ser usadas; dentre as mais conhecidas estão JSP, PHP e

ASP. Essas são todas linguagens de alto nível usadas por muitos

desenvolvedores, praticamente cada uma faz tudo que outra faz, cada qual

com sua particularidade dependendo muito de qual o desenvolvedor se adapta

melhor.

2.1.2 – CONEXÃO COM BANCO DE DADOS

Todas as linguagens fornecem meios para criar uma conexão com

banco de dados, com essa conexão pode-se criar uma ponte de comunicação

direta com a base de dados tendo através dela a possibilidade de executar

qualquer ação no banco.

A conexão exige uma autenticação com nome de usuário e senha, para

garantir maior segurança do sistema é muito importante que essa autenticação

tenha o mínimo de permissão, ou seja, deverá ser liberada somente a ação que

realmente necessita para o bom funcionamento do sistema. A permissão

máxima que permite realizar qualquer ação na base de dados deve ficar

somente com os administradores do banco de dados, isso impossibilita que

seja realizada qualquer alteração na estrutura da base pelo sistema.

2.1.3 – DESENVOLVIMENTO SEGURO

O desenvolvimento web encontra problemas na engenharia de seus

projetos; alguns são a falta experiência dos desenvolvedores, inexistência da

27

documentação do projeto, layout inadequado para portadores de deficiência

visual, falta de tratamento na entrada das informações e principalmente a não

utilização de uma metodologia que inclui o espaço de segurança necessário

para garantir proteção aos dados (Conallen, 2003).

Ao se falar em aplicações web aparece a grande preocupação em

relação à integridade dos dados, a dúvida se os dados realmente estão

seguros permanece. Mesmo investindo grande capital em equipamentos de

prevenção de ataques e softwares para monitoramento de rede não é o

suficiente para tornar um projeto completamente seguro, pois muitas vezes não

existe no momento do desenvolvimento dos projetos um tratamento específico

para aumentar a segurança.

O desenvolvimento de sistemas é um dos pontos mais críticos para garantia de segurança da informação de uma empresa. Procedimentos, treinamento, política de segurança, dentre outros são aspectos importantes a serem considerados. (Albuquerque; Ribeiro, 2002, p.106).

É muito importante dar atenção para a criação do código seguro e

também a segurança do código, evitar o roubo, alteração ou perda do código

fonte. É impossível desenvolver uma aplicação com alguma segurança em um

ambiente inseguro (Albuquerque; Ribeiro, 2002).

2.2 – SQL INJECTION

SQL Injection ou, português, Injeção de SQL é a inserção de código

SQL concatenando o script com o que já existe nas aplicações buscando ter

um resultado que possibilite ao usuário mal intencionado realizar uma ação

indevida.

Mesmo aparentando ser simples implementar meios de proteção contra

esse ataque, há uma grande quantidade de sistemas ativos conectados na

internet com total desproteção ainda sendo totalmente vulneráveis correndo o

risco de serem invadidos (Scambray; Shema, 2003).

O princípio básico dessa técnica é obter vantagem em cima de código

inseguro de algum sistema conectado na internet explorando vulnerabilidades

28

nas aplicações causando mensagens de erros até que o atacante consiga

interpretar a estrutura do sistema e assim adaptar a consulta SQL e executar a

injeção. Ao injetar código SQL, pode-se conseguir informações sigilosas ou

invadir o sistema sem ser autenticado. Com a entrada permitida, o usuário com

direitos de administrador tem acesso total ao sistema, podendo realizar

qualquer operação causando danos indesejáveis a qualquer desenvolvedor.

2.2.1 – CARACTERES ESPECIAIS

Para execução do ataque são muito utilizados caracteres especiais que

fazem parte da gramática da linguagem SQL. Esses caracteres são

compreendidos pelo banco de dados como parte da query (consulta) enviada

pela aplicação e assim o executam normalmente.

Importante conhecer esses caracteres especiais para poder utilizá-los da

melhor forma possível, pois possuem funções úteis e de grande siginificado

para a linguagem.

Encontrar os caracteres maliciosos diminui os riscos dificultando o

sucesso do ataque pela Injeção SQL (Torres, 2003).

A seguir segue a Tabela 2.1 com alguns dos caracteres mais usados

nos ataques.

CARACTER FUNÇÃO

‘ ou “ Caractere indicador de textos (encerra string de texto)

-- ou # Comenta uma linha

/* ... */ Comenta várias linhas

+ Adiciona ou concatena

% Insere um atributo (caractere coringa)

@@variável Variável global

Tabela 2.1 – Alguns caracteres utilizados no ataque


29

2.2.2 – O ATAQUE

O ataque de Injeção de código SQL é um dos mais usados pelos

crackers. A quantidade de sistemas web desprotegidos é imensa e qualquer

sistema que receba parâmetros para algum banco de dados pode estar

vulnerável. Portanto, em um cenário onde existe informação armazenada em

banco de dados e que possam ser acessadas via web, tem-se a possibilidade

desse ataque, e, para isso, é necessário apenas um navegador web,

conhecimento em linguagem SQL e imaginação para montar a nova query de

consulta ao banco de dados.

O SQL Injection é um tipo de ataque muito simples, porém muito

perigoso. Fundado em cima de comandos SQL, tanto DML (Data Manipulation

Language) que são os comandos de manipulação SELECT, INSERT, UPDATE

e DELETE, como DDL (Data Definition Language) que são os comandos de

definição de dados CREATE, DROP e ALTER.

O modo mais comum de utilizar o ataque é através da manipulação de

comandos SQL já existentes na aplicação, explorando a vulnerabilidade

através dos formulários para identificação do usuário, ou seja, os campos

destinados para o usuário digitar seu login e senha. Esta manipulação ocorre

pela alteração que sofre a cláusula WHERE ou acrescentando ao comando

SQL o operador UNION mudando o sentido da consulta que por falha da

aplicação acaba resultando em acesso indevido ao banco de dados ou na

própria aplicação.

As linguagens dinâmicas, como PHP, ASP ou JSP, fornecem a

possibilidade de conexão com banco de dados, que são normalmente

utilizadas nas aplicações. Como exemplo, em um sistema para verificar se um

usuário está devidamente cadastro é apresentada uma tela de autenticação.

Para o cracker que pretende invadir esse sistema, essa tela é uma porta de

entrada pois nela serão inseridos valores que serão concatenados no código

SQL existente, como mostra a Figura 2.1.

30

Figura 2.1 – Tela de Autenticação


Por trás dessa tela, na programação, quando o usuário clicar no botão

Entrar será executada a ação interna que verificará a autenticidade do usuário.

Para isso, no PHP, é usado um script que monta uma consulta com os

parâmetros passados pelo usuário, como mostrado na Figura 2.2 a seguir.

Figura 2.2 – Script em PHP para verificação do usuá rio


Esse script recebe os parâmetros usuário e senha que serão guardados

nas variáveis $usuario e $senha, respectivamente, é montado na variável

$query_string a consulta que verificará o usuário. Normalmente seriam

informados os dados de um usuário, mas foi passada parte de código SQL no

campo reservado para a senha, como mostrado na Figura 2.1, seguindo o

procedimento normal da aplicação a string ficará deste modo:

SELECT * FROM usuarios WHERE codigo = '123' AND sen ha = ' ' OR '1' = '1 '

Após essa linha de consulta ser processada pelo banco, o retorno será

verdadeiro, pois o comando passado no campo senha (‘ OR ‘1’ = ‘1) sempre

retornará algum registro.

31

Outra maneira de tentativa de invasão sem usar os formulários de

autenticação é usando os recursos da URL, por ser uma forma rápida e de fácil

utilização, pois as aplicações utilizam muito a estratégia de passar dados pela

URL para outras páginas como mostra a Figura 2.3 a seguir.

Figura 2.3 – Exemplo URL

Fonte: Próprio autor

Por essa URL o desenvolvedor está passando informações entre

páginas, onde a página remetente invoca a página destinatária, nesse caso

produtos.php, junto com essa informação também é passado o identificador

(ID) do item.

A Figura 2.4 a seguir mostra como a página destinatária receberá a

informação.

Figura 2.4 – Script em PHP para consulta de produto


Nesse script o código do produto é recebido via GET e guardado na

variável $idProduto, logo em seguida é criada a variável $sql_query que

realizará a consulta no banco de dados.

Para colocar esse ataque em funcionamento o usuário mal intencionado

adiciona junto com a condição já existente na URL a condição que lhe permitirá

ter favorecimento no sistema. A Figura 2.5 a seguir mostra a tentativa de

ataque pela URL.

32

Figura 2.5 – Tentativa de ataque pela URL


Nessa tentativa o atacante injeta junto com o parâmetro da página uma

parte de código SQL com a condição “OR 1 = 1”. Essa condição fará com que

a consulta sempre seja verdadeira retornando todos os registros cadastrados.

O usuário mal intencionado usando esse princípio de concatenar código

SQL na URL da página, usando a imaginação e o conhecimento em

programação, pode alterar o sentido da expressão para consultar outras

informações, como mostra a Figura 2.6 a seguir:

Figura 2.6 – Script em PHP concatenado com UNION


Dessa forma foi incluído o operador UNION que tem por finalidade,

como o próprio nome diz, unir duas consultas. Como no exemplo serão

retornados os campos usuario e senha deste modo, com esses dados

apropriados pelo atacante, se torna muito mais fácil a realização do acesso.

A Figura 2.7 a seguir apresenta outro tipo de ataque usando o DROP:

Figura 2.7 – Script em PHP concatenado com DROP


A Figura 2.7 mostra um ataque ainda pior para a aplicação, pois nesse

exemplo foi passado junto com o parâmetro da página o caractere ponto-e-

vírgula (;) que na sintaxe da linguagem SQL tem a função de finalizar uma

query para início de outra, o comando “DROP TABLE usuarios ” para executar

33

a deleção da tabela usuarios e os caracteres – informa ao banco que o que vier

na mesma linha após eles são comentários.

2.2.3 – ADVANCED SQL INJECTION

Essa variação da Injeção de SQL explora erros da aplicação,

especificamente, provocando o aplicativo a gerar erros para assim o invasor

levantar as informações necessárias que até o momento são desconhecidas.

Com essas informações é possível conhecer a estrutura da base de dados

para assim formatar uma melhor combinação de código SQL e receber os

resultados esperados.

2.2.4 – OBTENDO INFORMAÇÕES

O ataque avançado de injeção de código SQL procura sites vulneráveis

que permitam o acesso. Uma maneira muito simples de saber se o site é

vulnerável é acrescentando ao final da URL a aspas simples (‘), ao tentar

realizar a consulta ao banco de dados será retornada uma mensagem de erro,

pois a sintaxe da linguagem SQL está incorreta. A Figura 2.8 a seguir mostra o

uso da aspas.

Figura 2.8 – Script PHP concatenado com aspas simpl es


Após ser processado esse trecho do script, internamente é montada

uma query em SQL executando uma consulta na base de dados, a Figura 2.9 a

seguir mostra como esse código ficará.

34

Figura 2.9 – Código SQL para consulta de produto


O SGBD encontrará a aspas simples, ferindo a sintaxe do SQL,

retornando um erro para a aplicação que, por não haver nenhum tratamento

aos erros, será exibido na tela para o usuário como mostra a Figura 2.10 a

seguir.

Figura 2.10 – Erro causado com uso da aspas simples


Com esse erro sendo mostrado na tela para o usuário demonstra que o

sistema possui alguma vulnerabilidade onde o atacante pode explorar e

conseguir as informações necessárias, além de também mostrar qual banco de

dados está sendo usado, nesse caso o MySQL. Usando mais um pouco da

técnica, o atacante também consegue descobrir qual a versão usada como

mostra a Figura 2.11.

Figura 2.11 – Versão do banco de dados


Sabendo qual banco e versão está sendo usado é mais fácil de saber

aonde buscar as informações, pois há diferença entre as versões. Nessa

versão do MySql, a versão 5.0, existe a tabela information_schema que guarda

várias informações importantes como dados das tabelas e colunas. Usando a

criatividade, o atacante desenvolve uma linha lógica em cima do que foi criado

35

pelo desenvolvedor do sistema e com paciência pode conseguir a estrutura de

toda a base de dados.

Usar o operador union nesse momento é a melhor maneira para

encontrar as tabelas estratégicas, junto com o limit é possível descobrir, por

exemplo, a tabela de cadastro dos usuários como mostra a Figura 2.12.

Figura 2.12 – Union com a tabela information_schema


Alterando o parâmetro da condição LIMIT, o banco vai alterando a

resposta, assim é só substituir por outros valores e ir receber todas as

informações. Sabendo qual o campo e tabela quer consultar o atacante altera a

sequência do operador union colocando a tabela e campo descobertos, como

os campos login e senha da tabela usuário, desse modo o banco retornará os

dados cadastrados.

2.2.5 – ESTATÍSTICA

O site National Vulnerability Database (NVD) é um repositório de dados

sobre vulnerabilidades do governo norte americano, contém informações de

várias ameaças que colocam em risco a integridade de sistemas. A Figura 2.13

a seguir, extraída do NVD, mostra um gráfico de ataque da técnica de Injeção

de SQL nos últimos anos.

36

Figura 2.13 – Gráfico de exploração da vulnerabilid ade de Injeção de SQL

Fonte: http://nvd.nist.gov (acesso em 10/10/2009)

A Figura 2.13 representa a porcentagem da exploração da técnica

ocorrido nos últimos anos, pode-se perceber que em 2008 teve um alto

crescimento comparado com os outros anos e em 2009, até o momento da

geração desse gráfico, a exploração está pouco abaixo do ano anterior com

possibilidade de ultrapassar até o término do ano. O gráfico comprova que a

técnica está em constante utilização onde muitos sistemas estão

desprotegidos.

Em síntese, os sistemas ainda permanecem muito vulneráveis. Os da

plataforma web podem ser acessados de qualquer lugar do mundo, sendo

alvos propícios para o ataque. Estes ataques demonstrados nesse capítulo são

apenas exemplos de como a injeção SQL funciona, existe ainda uma lista de

comandos que possibilitam explorar as deficiências existentes nas aplicações.

Muitas vezes o potencial desse ataque é possível pelo desconhecimento da

programação segura que os programadores possuem.

37

3 UM ESTUDO DE CASO DE SEGURANÇA DA INFORMAÇÃO

Nos capítulos anteriores foram apresentados os aspectos teóricos que

fundamentam a Linguagem de Consulta SQL, Bancos de Dados e, em

especial, o ataque por Injeção de SQL, mostrando alguns exemplos de seu

funcionamento. Neste capítulo, pretende-se aplicar as técnicas de Injeção de

SQL apresentadas em um sistema existente, explorando as vulnerabilidades

deste sistema bem como meios de evitá-las.

Para que permaneça anônima a identidade do site objeto de estudo

deste trabalho, optou-se por deixar em branco seu endereço, por razões óbvias

do ponto de vista ético e de segurança da informação.

3.1 – ATAQUE PELA URL

Para atingir o objetivo de entrar no sistema sem ter um cadastro válido,

será necessário descobrir um registro válido – isso é possível através de

técnicas de Injeção de SQL. Primeiramente, será utilizada a técnica de

visualização da URL com a linguagem PHP (como exemplo), mas essa técnica

pode ser utilizada em qualquer linguagem de programação.

Para encontrar uma aplicação vulnerável é simples, basta procurar

alguma página de um site que tenha na URL o símbolo de interrogação (?), no

caso do PHP, seguido de alguma palavra recebendo algum valor, como mostra

em destaque na Figura 3.1 a seguir:

Figura 3.1 – Utilizando parâmetro pela URL em PHP


A Figura 3.1 anterior demonstra que a página atual está enviando uma

requisição para a página detalhes.php, ou seja, existe um valor sendo enviado

como parâmetro de uma página para outra. Após encontrar a página, para

descobrir se é vulnerável, utiliza-se uma aspas simples (‘) no final da URL.

38

Com essa prática, um sistema mal protegido retornará uma mensagem de erro

como mostra a Figura 3.2 a seguir:

Figura 3.2 – Erro mostrando que há vulnerabilidade


O erro apresentado na Figura 3.2 anterior mostra que a sintaxe de

consulta SQL está incorreta e pede para verificar o manual correspondente da

versão do MySQL. Isso confirma que o sistema é vulnerável, pois não fez

nenhum tratamento antes de executar a consulta no banco de dados.

Além de ter descoberto um sistema propício para invasão, também foi

possível descobrir qual SGBD está sendo usado. Desta maneira, um passo

seguinte interessante na técnica é descobrir qual a versão do SGBD para

assim saber quais suas particularidades e a melhor forma de construir as

consultas. Para isso é preciso utilizar o comando UNION para concatenar uma

nova consulta na consulta existente, no entanto, primeiro é preciso saber

quantas colunas a consulta original está retornando. A Figura 3.3 a seguir

mostra como fazer isso.

Figura 3.3 – Erro mostrando que não existe coluna 2 5


Neste momento começa a fase de tentativa e erro, pois não é conhecida

a estrutura do banco de dados, então, a única opção, é tentar e verificar os

erros, como mostra na Figura 3.3. Foi utilizado o ORDER BY para ordenar

primeiramente o resultado da coluna 21, depois pela coluna 22, 23, 24 e por fim

a coluna 25, mas como a tabela possui menos de 25 colunas o banco retorna a

39

mensagem de erro dizendo que o argumento não é um resultado válido do

MySQL. Dependendo da versão do SGBD, pode ocorrer outras mensagens

como a coluna 25 é inválida. Então é alterado no final da URL ficando dessa

maneira:

http://www.exemplo.com.br/detalhes.php?id=3 ORDER B Y 21,22,23,24

Após a alteração na URL o sistema não retorna mais o erro, significando

que existem vinte e quatro colunas na tabela da consulta principal; agora é

possível descobrir a versão usando a variável global @@version como

mostrado na Figura 3.4 a seguir:

Figura 3.4 – Versão do banco de dados


A versão do banco de dados MySQL é 5.0.81. Facilitando o ataque, a

partir da versão 5 do MySQL existe a tabela information_schema que guarda

informações de todas as tabelas e colunas do banco, assim através da tabela

tables é possível saber as tabelas e através da tabela columns saber as

colunas.

A próxima etapa do ataque é descobrir qual tabela atacar, portanto

continuando na tática de tentativa e erro trocando a variável global @@version

por concat(table_name, char(58), column_name), a função concat concatena

dois ou mais dados, como nesse caso a coluna table_name, o char(58) na

tabela ASCII representa o caractere dois pontos (:) e a coluna column_name.

No final da URL, continua com “FROM INFORMATION_SCHEMA.COLUMNS

LIMIT 1,1”.

A Figura 3.5 a seguir mostra a aplicação da técnica e o seu resultado:

40

Figura 3.5 – Descobrindo as tabelas e colunas


O comando LIMIT é o responsável por conseguir navegar entre os

registros e recebe dois parâmetros: um número inicial e um final, onde o

primeiro é o registro que se deseja e o segundo é quantos serão exibidos. Os

registros referentes a esse intervalo, dentre os registros resultantes do

SELECT executado, tem sua primeira posição numerada como 0, a segunda

como 1 e assim por diante. Conforme for desejado, basta indicar qual a posição

inicial e quantos registros a partir dela. Por exemplo, se usar LIMIT 3,7 retorna

do 4º registro mais 7 posições, ou seja, do 4º registro ao 10º registro.

Na Figura 3.5 foi retornada a tabela CHARACTER_SETS e a coluna

DEFAULT_COLLATE_NAME que, para o objetivo do trabalho, não tem

utilidade. Portanto, será alterado o primeiro parâmetro do comando LIMIT até

ser encontrada a tabela que guarde informações dos usuários. A Figura 3.6 a

seguir mostra a expressão com um parâmetro importante:

Figura 3.6 – Campo Id da tabela de Usuários


A Figura 3.6 mostra que existe a tabela que guarda informações dos

usuários como o campo ID. É nesta tabela que estão armazenados os registros

dos usuários cadastrados, portanto a exploração dessa tabela é fundamental

para descobrir algum nome de usuário e senha válidos. Continuando com o

processo, alterando o primeiro parâmetro do LIMIT com números sequenciais

serão descobertos os outros campos da tabela usuários.

As Figuras 3.7 e 3.8 mostram os campos necessários para continuação

do objetivo.

41

Figura 3.7 – Campo Nome da tabela de Usuários


Figura 3.8 – Campo Senha da tabela de Usuários


Com o LIMIT na posição 407,1 foi retornado o campo nome e na posição

408,1 foi retornado o campo senha, portanto foi atingida a primeira parte do

objetivo: o nome da tabela e os nomes dos dois campos mais importantes!

Agora será descoberta a segunda parte que é algum registro válido e,

para isso, será alterada a URL da consulta, direcionando para a tabela e os

nomes dos campos descobertos. A Figura 3.9 a seguir mostra a aplicação da

técnica e o seu resultado:

Figura 3.9 – Usuário e senha válida


Após ter conseguido descobrir um usuário e senha válidos, resta usá-los

para acessar ao site e assim ter acesso liberado, como é mostrado nas Figuras

3.10 e 3.11 a seguir:

42

Figura 3.10 – Tela de Login do sistema


Informando nos campos Usuário e Senha os dados descobertos, o

sistema verifica a existência e comprova que são verdadeiros, aprovando desta

maneira o acesso ao painel de controle.

43

Figura 3.11 – Tela principal com usuário Identifica do


O sistema aceitou a entrada e o usuário mal intencionado obteve com

sucesso total acesso ao sistema, podendo executar qualquer ação como

administrador.

3.2 – ATAQUE PELO FORMULÁRIO DE LOGIN

Outra forma utilizada para a Injeção de SQL é pelos campos dos

formulários que existem nos sistemas web. Esses formulários representam

uma porta de entrada do sistema, pois a função deles é capturar as

informações digitadas pelo usuário e levá-las para o banco, dessa forma, o

código malicioso entrará por esses campos. A Figura 3.12 mostra como ficará

um simples formulário de login com um trecho código SQL.

44

Figura 3.12 – Tela de Login com Código SQL


Após informar ‘ or ‘1’ = ‘1 no campo Usuário e Senha o sistema envia

esses dados para a verificação do usuário, a consulta em SQL, concatenada

com o texto entrado nos campos, ficará dessa maneira:

SELECT id FROM usuarios

WHERE usuario = ‘ ’ or ‘1’ = ‘1 ’

AND senha = ‘ ’ or ‘1’ = ‘1 ’

Na sintaxe do SQL, essa consulta retornará algum valor se for

verdadeiro ou nulo se for falsa, ou seja, se existir algum registro com as

condições usadas será retornado o seu ID e se não existir será retornado o

valor nulo. Mas como o parâmetro usado ‘1’ = ‘1 utiliza a condição OR (OU)

sempre será retornado verdadeiro. Portanto, o sistema aceita o usuário e

permite o acesso à página restrita.

3.3 – DEFESA DO SISTEMA

Nas seções 3.1 e 3.2 anteriores foram apresentadas uma visão do

atacante de como encontrar um sistema vulnerável, descobrir qual banco de

dados utilizado e sua versão, a estrutura da base de dados e os dados

armazenados. Mas ao invés de realizar apenas consultas, poderiam ter sido

executadas modificações no banco de dados, ou até mesmo exclusões. Nessa

seção serão mostradas algumas técnicas para anular os ataques mencionados

anteriormente.

45

3.3.1 – ENTENDENDO O ATAQUE

Tanto no caso do ataque ser realizado pela URL e por um formulário, ou

seja, independente da forma de entrada do código SQL, o potencial do ataque

é o mesmo. Para explorar a injeção de código SQL é necessário que o

atacante execute inúmeras tentativas de acesso, para que, através de tentativa

e erro o sistema possibilite conhecer toda a estrutura do banco de dados.

Portanto, o sucesso do ataque somente foi possível por duas falhas básicas na

aplicação:

� Não ter sido feito o devido tratamento da entrada da informação, pois

chegou ao banco de dados sem nenhuma barreira.

� Não terem sido filtradas corretamente as informações vindas do banco

de dados para o cliente.

Dois motivos simples que geralmente passam despercebidos por muitos

desenvolvedores e acabam possibilitando a aplicação das referidas técnicas de

ataque.

3.3.2 – TÉCNICAS DE DEFESA NA APLICAÇÃO

Para realizar a defesa na aplicação, é necessário verificar toda

informação inserida no sistema através do usuário e toda informação retornada

ao usuário pelo sistema. Isso causa a criação de várias validações de

segurança que consequentemente deixará o código maior e fará com que ele

precise de mais tempo de processamento.

3.3.2.1 – TRATANDO OS DADOS DE ENTRADA

Cada linguagem de programação possui suas características e suas

técnicas de defesa, nesse trabalho foi definida a linguagem PHP para a

demonstração dos códigos por ser uma linguagem muito utilizada entre os

desenvolvedores web.

46

No início deste capítulo foi mostrado que o primeiro passo do usuário

mal intencionado foi encontrar uma vulnerabilidade no sistema e para isso

utilizou a aspas simples (‘), mostrado na Figura 3.2, no qual o sistema retornou

uma mensagem de erro. O erro foi originado por causa das aspas simples

interferirem na sintaxe do comando SQL, portanto, uma prática de

programação segura deve antes de executar a ação com o banco de dados

verificar o que está sendo executado.

A linguagem PHP possui várias funções que verificam a entrada de

informações e dentre elas destacam-se:

• addslashes

Sintaxe: string addslashes (string $str)

Descrição: Recebe uma string e a retorna com barras invertidas (\) antes

dos caracteres que precisam ser escapados¹ para serem enviados em query

em banco de dados. Alguns dos caracteres que devem ser “escapados” são

aspas simples (‘), aspas duplas (“) e barra invertida (\). A Figura 3.13 a

seguir apresenta como é o uso dessa função:

Figura 3.13 – Código PHP com a função addslashes


A Figura 3.13 mostra um trecho de código PHP utilizando a função

addslashes que recebe as variáveis “usuario” e “senha” e as retorna

“escapadas” para em seguida montar a query de consulta.

Ex: Utilizando a variável “’ or ‘1’ = ‘1” com a função addslashes será

retornado: “\’ or \‘1\’ = \‘1”, mas para o banco de dados será como “’ or ‘1’ = ‘1”.

¹ Caractere Escapado é um caractere precedido de uma barra invertida (\), anulando algum significado ou efeito especial.

47

• strtr

Sintaxe: string strtr (string $str, string $de, string $para)

Descrição: Recebe uma variável string, um parâmetro de entrada e um

parâmetro de saída. Se houver na variável string o parâmetro de entrada,

esse será substituído pelo parâmetro de saída e retorna a nova string. A

Figura 3.14 a seguir apresenta como é o uso dessa função:

Figura 3.14 – Código PHP com a função strtr


A Figura 3.14 mostra um trecho de código PHP utilizando a função strtr

que recebe as variáveis “usuario” e “senha” e as retorna após trocar a aspas

simples pela letra A para em seguida montar a query de consulta.

Ex: Se for utilizado a string “’ or ‘1’ = ‘1” a função ficará da seguinte

maneira: strtr(“’ or ‘1’ = ‘1”, “’”, “A”) será substituído a aspas simples pela letra A

retornado a nova string: A or A1A = A1 que para o banco é um texto simples.

• mysql_real_escape_string

Sintaxe: string mysql_real_escape_string (string $str)

Descrição: Recebe uma string e escapa os caracteres especiais para serem

usados em um comando SQL, sendo igual à função addslashes. Essa é

uma função para o banco de dados MySQL, mas existe a mesma função

para outros bancos. A Figura 3.15 a seguir apresenta como é o uso dessa

função:

48

Figura 3.15 – Código PHP com a função mysql_real_es cape_string


A Figura 3.15 mostra um trecho de código PHP utilizando a função

mysql_real_escape_string que recebe as variáveis “usuario” e “senha” e em

seguida monta a query de consulta.

Ex: Se for utilizado a string “’ or ‘1’ = ‘1” como parâmetros a função ficará

da seguinte maneira: mysql_real_escape_string(“’ or ‘1’ = ‘1”); percebe-se que

será adicionada a barra invertida antes dos caracteres especiais para, com

isso, ser retornada a nova string \’ or \‘1\’ = \‘1 que, para o banco de dados, é

um texto simples que não irá interferir na sintaxe da SQL.

Usando alguma dessas funções, ou outras semelhantes, poderão ser

evitadas as aspas simples que fazem parte da sintaxe de comandos da SQL.

Ao evitar aspas simples dos textos de entrada, as tentativas de provocar erro

pela URL ou por algum formulário de login com o texto ‘ or ‘1’ = ‘1 estarão

anuladas.

Outra maneira de restringir os dados inseridos pelo usuário, além das

funções de cada linguagem, é verificar se o dado recebido é do tipo esperado.

Como visto nas técnicas de ataque apresentadas, o sistema passa um ID para

outra página e essa página deve primeiro verificar se o parâmetro recebido é

um número. A Figura 3.16 a seguir verifica se o valor da variável é um int:

Figura 3.16 – Verificação do tipo da variável em PH P


49

A Figura 3.16 mostra como ficará um trecho de código após receber a

variável via método GET, responsável por receber parâmetros pela URL. É

usada a função is_int do PHP dentro do laço IF que verifica se o tipo da

variável é um inteiro, caso sim, monta a sentença SQL.

Esse caso permite interferir na tentativa de alguma injeção realizada

pelo usuário não permitindo que chegue à base de dados, pois, qualquer

entrada diferente de um número será barrada no IF e, no caso de ser uma

string, terá mais verificações como mostra a Figura 3.17 a seguir:

Figura 3.17 – Função em PHP para validar String


A Figura 3.17 mostra a função validar($string) que verifica se o

parâmetro possui alguma tentativa de injeção de código comparando tudo que

foi recebido pela URL com várias palavras reservadas da linguagem SQL. Para

iniciar a verificação, primeiro a variável é passada pela função do PHP

mysql_real_escape_string, mostrada na Figura 3.15 anterior e, após a primeira

verificação, é chamada a função validar($string) que executa os seguintes

procedimentos:

50

� Aplica-se strtoupper, que retorna uma string ($valor) com todos os

caracteres de uma variável convertidos em maiúscula;

� Aplica-se explode, que recebe uma variável e um delimitador, divide a

variável em várias strings sendo separada pelo delimitador e retorna um

array ($detalhe) com todas as substrings;

� É criado o array $reservadas com várias palavras reservadas da SQL;

� É criada a variável $invalido com valor 0 para ser o contador de quantas

palavras reservadas foi encontrada no array $detalhe;

� A função foreach percorre todos os itens do array $detalhe, retornando

um elemento por vez por meio da variável $det;

� Aplica-se a função in_array, que verifica se um valor está no array,

procurando no array $reservadas o valor de $det. Se encontrar o valor, é

incrementado o contador $invalido, caso contrário o valor de $det é

substituído e inicia uma nova procura. Com esse processo, todos os

valores da variável inicial $detalhe são comparados com os valores de

$reservadas;

� Para finalizar a função validar, é retornado o contador $invalido.

Tendo o valor do contador, foi realizado um novo laço IF para verificar se é

maior que zero; se sim, é porque o valor recebido possui alguma palavra que

possa tentar executar o ataque; se não, quer dizer que a variável recebida pela

página provavelmente possui apenas o valor esperado e a sentença SQL é

criada.

3.3.2.2 – TRATANDO OS DADOS DE SAÍDA

Como dito anteriormente, todo ataque por injeção de código SQL bem

sucedido é iniciado pelo processo de tentativa e erro. Isso é possível porque o

sistema retorna para o usuário o erro ocorrido e assim, por meio destas

mensagens informativas, podem ser obtidas informações valiosas como nomes

de tabelas e os tipos das colunas.

As mensagens de erros são importantes no ambiente de criação por

indicar aos desenvolvedores as informações do erro e assim poder efetuar as

51

correções, o que para o ambiente de produção não é interessante por motivo

de segurança e por também deixar a impressão de um sistema amador.

Uma maneira de evitar que apareçam as mensagens de erro seria

desabilitar a exibição ou direcionar para uma página personalizada. A

linguagem PHP possui o arquivo php.ini que possui diversas diretivas de

configuração, dentre as quais existe a display_errors que por padrão é

marcada como ON, para exibir as mensagens de erro na tela. Alterando essa

diretiva para OFF não mais se exibe mensagens de erro quando algo incorreto

acontecer, portanto, mesmo que o usuário insista em provocar algum erro a

mensagem não será exibida.

3.3.3 – TÉCNICA DE DEFESA NO BANCO DE DADOS

Para que o código injetado pelo usuário não tenha sucesso é

necessário, além de criar barreiras na aplicação, criar barreiras no banco de

dados. Fazer isso garante uma proteção maior, pois se o ataque conseguir

passar os bloqueios da aplicação irá se deparar com mais bloqueios na base

de dados.

Muitos desenvolvedores utilizam o banco de dados apenas para guardar

os dados, não aproveitando todos os recursos que essa incrível ferramenta

disponibiliza. Agora serão apresentadas algumas técnicas de defesa possíveis,

em termos de Sistemas Gerenciadores de Banco de Dados (SGBDs), embora

pouco adotadas como práticas de projeto:

• Permissões dos usuários do Banco de Dados

Existem vários problemas circulando em volta das permissões que possuem

os usuários do banco de dados. Se o usuário que a aplicação utiliza para

conectar no banco tem direitos de administrador, ele vai poder realizar

todas as operações como DROP, ALTER, SELECT, UPDATE, INSERT e

DELETE.

O único responsável que deve ter direito total na base de dados é a pessoa

que exerce a função de DBA (Database Administrator ou Administrador de

Banco de Dados), os demais deverão ter somente a permissão que

52

necessitem. Portando, quando se cria um novo usuário deve-se analisar o

que ele vai poder fazer para ser melhor configurada sua permissão e se

tratando do usuário usado pela aplicação para conectar no banco deve ter a

mínima permissão, ou seja, o suficiente para o funcionamento do sistema.

• Criptografia

Na técnica de ataque considerada nesse trabalho, foram descobertas as

senhas de usuários cadastrados no sistema. Isso só foi possível porque não

foi utilizada nenhuma criptografia para “camuflar” tais senhas. As próprias

linguagens de programação disponibilizam meios de criptografia, mas, se

caso a criptografia utilizada for fácil de ser descoberta, o desenvolvedor

pode criar uma função que criptografe. Portanto, o objetivo de utilizar a

criptografia é de esconder os dados para que não possam ser lidos nem

mesmo pelos desenvolvedores.

• Função

Um bom motivo de utilizar funções, além de ajudar no desenvolvimento do

sistema, é na consistência dos dados que é possível fazer antes de

executar alguma ação. Como a função pertence ao banco de dados, a

aplicação à chama passando os parâmetros necessários e a função se

encarrega da validação, faz todas as alterações necessárias e retorna se

realizou a operação com sucesso ou não.

• Visões

Quando não há a necessidade de disponibilizar todas as colunas para os

usuários podem-se criar visões das colunas selecionadas. Visão é uma

relação que não contem dados, ou seja, é uma tabela dinâmica resultante

de uma consulta. Com a utilização de visões permite-se que o usuário tenha

o acesso aos dados de uma maneira indireta.

Em síntese, as técnicas de ataque consideradas mostraram a facilidade

da utilização da técnica de injeção de SQL. Usando alguns comandos da

linguagem SQL, foi possível descobrir todas as informações existentes na base

de dados e entrar no sistema sem ter permissão, mas, em contra partida,

53

também foram mostradas algumas técnicas para prevenir o ataque com

medidas tomadas no desenvolvimento da aplicação e na própria administração

do Sistema Gerenciador de Banco de Dados.

54

4 CONSIDERAÇÕES FINAIS

O objetivo deste trabalho foi realizar um estudo sobre uma das ameaças

que mais coloca em risco os sistemas, principalmente os desenvolvidos para a

plataforma web, a Injeção de SQL.

O primeiro passo do trabalho foi mostrar como a técnica funciona.

Através de um sistema comercial, foram utilizadas duas maneiras para

conseguir o acesso com direitos administrativos. De uma forma mais complexa,

a primeira tentativa ocorreu através da URL que por diferentes maneiras, junto

com os parâmetros da página, foram inseridos trechos de código SQL com a

função de forçar o sistema a passar informações importantes que ajudasse a

compor novas consultas até que foram obtidos os dados de um usuário

devidamente cadastrado no sistema. A outra forma, de uma maneira mais

simples, foi utilizando o formulário de login para inserir o código SQL na

aplicação. Com a inserção foi possível fazer o sistema entender o ataque como

se fosse um usuário cadastrado, obtendo assim o acesso privilegiado podendo

realizar qualquer operação sem restrição.

Após os ataques, foi possível entender melhor o funcionamento da

técnica, e em defesa do sistema foram estudadas boas práticas para

impossibilitar a sua funcionalidade. No trabalho foi utilizada a linguagem PHP

para demonstração, e explorando as suas funções foram criadas algumas

rotinas que verificam os dados antes de serem enviados ao banco de dados.

Dessa forma o sistema é preparado para tratar a informação recebida e

somente será processada se for a esperada, caso contrário o sistema segue

outro caminho, não levando o código malicioso ao banco de dados. Outra

maneira demonstrada de impor barreiras para o ataque foi no banco de dados,

com a criação de visões, funções e a prática de armazenamento criptografado

de dados, aumenta o grau de dificuldade na tentativa de invasão, pois mesmo

que consiga passar pela aplicação, terá mais uma barreira no próprio banco de

dados.

Com a realização desse estudo e, principalmente, conseguindo alcançar

os dois objetivos que eram explorar as vulnerabilidades de um sistema para

conseguir o acesso privilegiado e criar barreiras para impedir que o ataque

55

tenha sucesso, a compreensão da necessidade de dar uma maior importância

na implementação de técnicas para fortalecer a segurança da aplicação, teve

um aumento significativo possibilitando enxergar com mais clareza as possíveis

brechas.

Portanto, esse trabalho mostrou que mesmo com o grande crescimento

na utilização de sistemas web, muitos ainda estão vulneráveis ao ataque,

colocando em risco a segurança e integridade dos dados. Isso prova que

muitos desenvolvedores ainda estão despreparados, não possuindo

características como a visão global do projeto para prever possíveis falhas, não

utilização de uma metodologia de desenvolvimento que abranja a segurança do

sistema ou mesmo a falta de conhecimento na área. Este estudo, também,

abre oportunidades de futuros trabalhos, tais como:

• Estudo de outras formas de ataques mais avançados como em nível de

sistema ou via cookie;

• Elaboração de conteúdo para capacitação de profissionais

(desenvolvedores, arquitetos e engenheiros de software) em segurança

da informação;

• O desenvolvimento de uma ferramenta de software que permita a

análise das possíveis falhas na aplicação ou o estudo de ferramentas

existentes para testes de segurança contra SQL Injection;

• Estudar o grau de vulnerabilidade em relação às linguagens de

programação: ASP, PHP, Java e outros.

Ao longo dos estudos, percebeu-se que é possível criar aplicações mais

seguras, uma vez que essa falha de segurança ocorre muitas vezes por

desatenção ou por falta da utilização de uma metodologia de desenvolvimento

alicerçada em conceitos de segurança da informação. Constatou-se então,

neste trabalho, que para conseguir um sistema seguro da injeção de SQL não

basta se apoiar somente em técnicas de programação, mas também em

administração de banco de dados bem como uma política de segurança mais

ampla.

56

GLOSSÁRIO

ANSI – American National Standards Instiute. Instituto norte-americano sem

fins lucrativos, formada por grupos de comunidade comercial e industrial

responsável pelo desenvolvimento de normas técnicas.

ASP – Active Server Pages.

CRACKER – Conhecedor de linguagens de programação e sistemas

operacionais, com fins criminosos modifica o comportamento de programas,

invade sistemas ou computadores sem autorização.

COOKIE – Pequeno arquivo de texto criado por sites no micro do usuário para

guardar informações do mesmo como login e páginas visitadas, para

posteriormente ser utilizado pelos sites.

DBA – Database Administrator (Administrador de banco de dados). Pessoa

responsável pela criação, manutenção, segurança e performance do banco de

dados.

GET – Esse método utiliza a URL para enviar informações para outra página

concatenando com o endereço do servidor os dados necessários.

HACKER – Conhecedor de linguagens de programação e sistemas

operacionais, sem fins criminosos invade sistemas para ampliar seus

conhecimentos ou pela satisfação de detectar suas possíveis falhas de

segurança.

ISO – International Standards Organization. Organização que cria padrões

industriais de aceitação mundial, composta por entidades como ANSI (norte-

americana) e ABNT (brasileira).

JSP – Java Server Pages.

PHP – Personal Home Page.

URL – Uniform Resource Locator (Localizador de Recurso Uniforme). Padrão

de endereçamento na internet formado por duas partes, a primeira antes da

barra dupla especifica o protocolo a ser utilizado (http, ftp, etc) e a direita o

endereço do servidor.

XML – Extensible Markup Language (Linguagem de marcação extensível).

Linguagem que permite a troca das informações contidas numa página,

possibilitando que os dados sejam transportados entre sistemas.

57

REFERÊNCIAS

Albuquerque, Ricardo; Ribeiro, Bruno. Segurança no Desenvolvimento de Software; Rio de Janeiro: Editora Campus, 2002, 320p. Aquino, Rodrigo S. Prudente de. Wpage: Padronizando o desenvolvimento de Web Sites; São Paulo: Editora Viena, 2006, 189p. Bernstein, Terry et al. Segurança na Internet; Rio de Janeiro: 1997, Editora Campus Ltda, 461p. Conallen, Jim. Desenvolvendo Aplicações Web com UML, São Paulo: Editora Campus, 2003, 504p. Costa, Rogério Luís de C. SQL – Guia Prático, 2 ed. Rio de Janeiro: Editora Brasport, 2006, 248p. Date, C. J. Introdução a Sistemas de Banco de Dados. 8 ed. Rio de Janeiro: Editora Elsevier, 2004. 865p. Heuser, Carlos Alberto. Projeto de Banco de Dados. 4 ed. Porto Alegre: Editora Sagra Luzzatto. 2001, 194p. Milani, André. PostgreSQL – Guia do Programador. São Paulo: Editora Novatec, 2008. 392p. National Vulnerability Database. Disponível em <http://nvd.nist.gov>. Acesso em 10/10/2009. Oliveira, Wilson José; Segurança da Informação, técnicas e soluções; Florianópolis: Visual Books, 2001. 182p. PHP Net. Disponível em <br.php.net>. Acesso em 10/2009 Riccio, Edson Luiz. Segurança em processamento de dados. 1981. 105f. Dissertação (Mestrado em Administração) – Faculdade de Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo, 1981. Scambray Joel; Shema Mike. Segurança Contra Hackers – Aplicações Web, Minas Gerais: Editora Futura, 2003. 394p. Silberschatz, Abraham; Korth, Henry F.; Sudarsha, S. Sistema de Banco de Dados, São Paulo, 1999, Makron Books, 806p. 3ºEd. Torres, Dennes. Segurança Máxima de Software, Rio de Janeiro, Editora Brasport, 2003, 204p.

Documents

SQL Injection TCC Wanderson