FACULDADE DO LITORAL SUL PAULISTA - FALS
LEONARDO ALMEIDA DOS SANTOS
TRABALHO DE CONCLUSÃO DE CURSO
TÉCNICAS DE PROGRAMAÇÃO SEGURA
PRAIA GRANDE
2010
2
LEONARDO ALMEIDA DOS SANTOS
TRABALHO DE CONCLUSÃO DE CURSO
TÉCNICAS DE PROGRAMAÇÃO SEGURA
Trabalho apresentado como exigência de conclusão de curso
Objetivo atender meu conhecimento sobre o assunto e ou
até mesmo proporcionar dentro de uma empresa formas
segura dentro do ciclo de informações onde serão aplicadas
algumas técnicas de programação segura. Faculdade Litoral
Sul Paulista, sobre orientação do educador Caio Sales.
PRAIA GRANDE
2010
3
LEONARDO ALMEIDA DOS SANTOS
TRABALHO DE CONCLUSÃO DE CURSO
TÉCNICAS DE PROGRAMAÇÃO SEGURA
Trabalho apresentado como exigência de conclusão de curso
Objetivo atender meu conhecimento sobre o assunto e ou
até mesmo proporcionar dentro de uma empresa formas
segura dentro do ciclo de informações onde serão aplicadas
algumas técnicas de programação segura. Faculdade Litoral
Sul Paulista, sobre orientação do educador Caio Sales.
AVALIAÇÃO:________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
NOTA: ____(________)
_____________,de_________________de_.
local
data
4
DEDICATÓRIA
Dedico este trabalho primeiramente a Deus, pois sem Ele, nada seria possível e não
estaríamos aqui reunidos, desfrutando, juntos, destes momentos que nos são tão
importantes.
Aos meus pais Gilson e Marli; pelo esforço, dedicação e compreensão, em todos os
momentos desta e de outras caminhadas.
Em especial, à minha grande companheira, esposa Edivania Vasconcelos por me
focar nos estudos me apoiando nos momentos difíceis agradeço por tudo e pelo
mútuo aprendizado de vida, durante nossa convivência, no campo no aprendizado
nos estudos e na vida particular.
Amor , gratidão eterna!!!
Leonardo A.Santos
5
AGRADECIMENTO
À Edivania, Marli, Gilson , por todo o apoio e carinho recebido durante minha vida e
ao extra destes últimos quatros anos. A todos os meus irmãos, Luiz, Carlos, pela
alegria e inspiração que despertam. À minha grande família, pela confiança que
sempre depositou em mim.
Às minhas inseparáveis companheiras Fábio, Alessandro pelas longas
conversas, idéias e desabafos, que ajudaram a me tornar uma pessoa melhor.
Guardarei estas lembranças pelo resto da vida, por mais longe que estivermos.
Ao professor Caio Sales, que abriram as portas do mundo da informação e me e
aceitou me orientar neste trabalho.
A Faculdade Fals , a todos os professores que fizeram parte da minha
formação e aos pacientes com os quais aprendi de alguma forma, por contribuírem
para o melhor entendimento.
Grato á todos.
6
RESUMO
A programação defensiva é algumas vezes referida como programação segura pelos
cientistas de computação os quais localizam este enfoque minimizando bugs.
Os erros de software (bugs) podem ser potencialmente usados por um cracker para
uma injeção de códigos e ataques indesejáveis.
Uma diferença entre programação defensiva e práticas normais é que poucas
hipóteses são feitas pelo programador, o qual tenta manejar todos os possíveis
estados de erro. Em resumem, o programador nunca assume que um telefonema a
uma função particular ou livraria trabalhará baixo as entradas previstas.
A segurança da Informação e o mundo globalizado e informatizado,fez com que a
visão que tinham sobre segurança da informação teve que se adequar as novas
tecnologias e antigamente a segurança de sistemas de informação era sinônimo
exclusivamente de proteção, assumindo sempre uma posição puramente defensiva
e o em dia número de vulnerabilidades encontradas em softwares é um problema
em expansão. Esta expansão é decorrente tanto do aumento no número de
sistemas no mercado.
O uso de técnicas e ferramentas para a proteção dos dados de qualquer ameaça
que venha a ocorrer, pois devemos proteger os ativos contra qualquer ameaça de
todos os tipos.
A programação defensiva é um enfoque que procura melhorar o software e o código
fonte, em termos de:
Qualidade Geral - reduzindo o número de falhas de software e problemas.
Fazendo o código fonte comprensilvel - o código fonte deve ser legivel e
entendido, a prova de uma auditoría de código.
7
ABSTRACT
Defensive programming is Sometimes Referred to the secure computer programming
by
Scientists
who
located
this
approach
Minimizes
bugs.
Software errors (bugs) can Potentially Be used by an attacker to a code injection
attacks
and
undesirable.
One Difference Between normal practice and defensive programming Is That few
Assumptions are made by the programmer, Which Attempts to handle all Possible
error states. In sum, the programmer who never takes a phone call to a particular
function
or
bookstore
Will
work
down
the
entries.
The security of information and computerized and globalized world, led to the view
That information security HAD HAD to Adapt to new technology and once the
security of information systems was synonymous only protection, always assuming
the Purely defensive position and in number of day vulnerabilities found in software is
an expanding problem. This expansion is due to BOTH Increased the number of
systems
on
the
market.
The use of techniques and tools for Protecting data from any threat That May Occur
because
we
must
protect
the
assets
from
any
threat
of
all
kinds.
Defensive programming is an approach That Seeks to Improve the software and
source
code,
in
terms
of:
• Overall Quality - by reducing the number of software flaws and problems.
• Making comprensilvel source - the source code should be readable and
understood, evidence of a code audit.
8
SUMÁRIO
INTRODUÇÃO.......................................................................................................09
1. TÉCNICAS PARA SEGURANÇA DA INFORMAÇÃO......................................12
1 1.1 FIREWALL.....................................................................................................13
1.2 IDS....................................................................................................................14
2. VULNERABILIDADE DE PROGRAMAÇÃO.....................................................18
2.1 - EXPLORANDO VULNERABILIDADES..........................................................18
2.2 - ARQUITETURA DE SISTEMAS.....................................................................19
2.3 - GERENCIAMENTO DE MEMÓRIA................................................................20
2.4 - PROCESSAMENTO DE ENTRADAS.............................................................20
2.5 - BUFFER OVERFLOW....................................................................................21
2.5.1 -STACK OVERFLOW....................................................................................21
2.5.2 - HEAP OVERFLOW......................................................................................25
3. A VULNERABILIDADE NA WEB.......................................................................26
3.1 WEB APPLICATION FIREWALL.......................................................................27
3.2 - IMPLEMENTAÇÕES DE UM WAF.................................................................27
3.3 - TÉCNICAS DE DETECÇÃO DE ATAQUES DE UM WAF.............................28
3.4 - TÉCNICAS DE NORMALIZAÇÃO..................................................................28
3.5 - MODELO DE SEGURANÇA NEGATIVO.......................................................27
3.6 - MODELO DE SEGURANÇA POSITIVO........................................................29
3. 7 - ATAQUES A APLICAÇÕES WEB.................................................................29
3.8 - VULNERABILIDADE DOS SERVIÇOS WEB.................................................30
3.8.1 - TIPOS DE VULNERABILIDADES...............................................................31
3.9 - VERIFICAÇÃO DOS DADOS DE ENTRADA................................................31
3.10 - IMPACTO DOS ATAQUES WEB.................................................................32
3.11 - INTRODUÇÃO ÀS URL...............................................................................32
3.11.1 - MANIPULAÇÃO DE URL..........................................................................33
3.12 - TENTATIVAS ÀS CEGAS............................................................................34
3.13 - CRUZAMENTO DE DIRECTÓRIOS............................................................35
3.13.1 – DESFILES................................................................................................36
3.13.2 - ATAQUES POR FALSIFICAÇÃO DE DADOS..........................................37
3.13.3 - PARÂMETROS DAS APLICAÇÕES WEB................................................37
CONCLUSÃO.........................................................................................................38
REFERÊNCIAS BIBLIOGRÁFICAS......................................................................39
9
INTRODUÇÃO
A segurança da Informação é um dos temas mais discutidos em nossa
sociedade, o mundo globalizado e informatizado, especialmente para o mundo
corporativo. O uso da informática tem sido freqüente em todos os setores produtivos
e até mesmo de lazer. Deste modo faz-se necessário criar uma infra-estrutura de
comunicação que suporte todas as transações executadas e que sejam
armazenadas e utilizadas de modo seguro.
Porém, o valor da informação em muitos casos não é passiveis de
mensurar devido a crescente quantidade de dados que uma organização possui, por
conta disso, se torna imprescindível identificar todos os elementos que compõem a
comunicação de dados.
Existem normas e metodologias de desenvolvimento de software que
permitem produzir programas visando diminuir a ocorrência de vulnerabilidades.
Algumas são práticas gerais, independentes de linguagem, enquanto outras são
específicas a uma dada linguagem.
Há bem pouco tempo, segurança de sistemas de informação era sinônimo
exclusivamente de proteção, assumindo sempre uma posição puramente defensiva.
O número de pessoas tentando violar a segurança de sistemas, passando
dias e noites em busca de vulnerabilidades nos sistemas com intuito de desenvolver
ferramentas que permitam o acesso ao sistema alvo, é muito grande.
Além disso, se para cada organização existem alguns
poucos
profissionais dedicados a estudar e manter os sistemas seguros, por outro lado,
existem inúmeras pessoas tentando encontrar uma maneira de penetrar e
comprometer os mesmos.
Atualmente, o número de vulnerabilidades encontradas em softwares é
um problema em expansão. Esta expansão é decorrente tanto do aumento no
número de sistemas no mercado, da forma como estes softwares são concebidos e
da maneira como são mantidos, configurados e utilizados.
A má codificação do software é a causa imediata das vulnerabilidades do
mesmo. Muitas empresas desenvolvem sistemas com códigos inseguros mesmo
sem intenção. Existe um grande número de razões para isto.
10
Na maior parte das vezes, empresas que desenvolvem software são
contratadas para especificar, projetar, desenvolver, testar e documentar em um
tempo pré-determinado. Esta pressão induz, muitas vezes, a erros graves, como, por
exemplo, a não preocupação com a escolha de funções seguras para exercer
determinadas tarefas, ou a utilização incorreta das interfaces de programação que a
linguagem utilizada disponibiliza.
Além do que, muitas das vezes a segurança não faz parte do projeto. Um
outro aspecto que deve ser levado em consideração é a má formação dos
desenvolvedores de sistemas.
São poucas as universidades que ensinam seus alunos a programarem
de maneira correta, aplicando técnicas de programação segura. E são em menor
número ainda as que fornecem a disciplina de programação segura em suas grades
curriculares.
Algumas ferramentas de auxilio a auditoria de códigos estão disponíveis
hoje e servem como apoio aos analistas de sistemas. Entender como estas
ferramentas funcionam, o que podem induzir e o que de fato são capazes é muito
importante para qualquer profissional ligado direta ou indiretamente com segurança
e programação de sistemas.
A Política de Segurança é a formalização de todos os aspectos considerados
relevantes por uma organização para proteção, controle e monitoramento de seus
recursos computacionais. Também deve ser vista como um canal de comunicação
entre usuários e o comitê Corporativo de Segurança da Informação. A
documentação gerada precisa explicar a importância da segurança para motivar as
pessoas envolvidas a praticá-la.
A divulgação da política de segurança é uma das ferramentas responsáveis
pelo sucesso da sua implantação. Seu objetivo é disseminar a política de segurança
da informação na empresa, conscientizando os colaboradores e prestadores de
serviço para a política de segurança que está sendo implantada.
A
política
de
segurança
não
define
procedimentos
específicos
de
manipulação e proteção da informação, mas atribui direitos e responsabilidades às
pessoas (usuários, administradores de redes e sistemas, funcionários, gerentes,
etc.) que lidam com essa informação. Desta forma, elas sabem quais as
expectativas que podem ter e quais são as suas atribuições em relação à segurança
dos recursos computacionais com os quais trabalham.
11
Além disso, a política de segurança também estipula as penalidades às quais
estão sujeitos àqueles que a descumprem.
Antes que a política de segurança seja escrita, é necessário definir a
informação a ser protegida. Usualmente, isso é feito através de uma análise de
riscos, que identifica:

Recursos protegidos pela política;

Ameaças às quais estes recursos estão sujeitos;

Vulnerabilidades
que
podem
viabilizar
a
concretização
ameaças, analisando-as individualmente.
Uma política de segurança deve cobrir os seguintes aspectos:

Política de senhas;

Direitos e responsabilidades dos usuários;

Direitos e responsabilidades do provedor dos recursos;

Ações previstas em caso de violação da política.
destas
12
1. TÉCNICAS PARA SEGURANÇA DA INFORMAÇÃO:
CONCEITO E FUNÇÃO
Diante deste contexto torna-se imperativo o uso de técnicas e ferramentas
para a proteção dos dados de qualquer ameaça que venha a ocorrer, pois devemos
proteger os ativos contra qualquer ameaça de todos os tipos. Porém os princípios
básicos da segurança da informação são: confidencial idade; integridade e
disponibilidade.

Confidencialidade – as informações são conhecidas somente pelas
pessoas que possuem as permissões de acesso, prevenindo deste
modo, o vazamento de informações e evitando a espionagem
industrial;

Integridade – normalmente as informações precisam ser mantidas em
seu estado original, sem nenhuma alteração, garantindo a quem as
recebe a certeza de que não são ou foram falsificadas, corrompidas ou
modificadas;

Disponibilidade – garantir a todos os dados no momento que for
necessário para utilização.
Entretanto, os ativos estão continuamente expostos às ameaças
existentes, que podem colocar em risco a confidencial idade, integridade e
disponibilidade.
Dentro desse contexto, a confidencialidade oferece suporte à prevenção
de revelação não autorizada de informações, além de manter dados e recursos
ocultos a usuários sem privilégio de acesso. Já a integridade previne a modificação
não autorizada de informações.
Por outro lado, a disponibilidade prover suporte a um acesso confiável e
prontamente disponível a informações. Isto implica em dados e sistemas
prontamente disponíveis e confiáveis. Adicionalmente, o não repúdio e autenticidade
compreendem o que poderia ser denominado de responsabilidade final e, dessa
13
forma, busca-se fazer a verificação da identidade e autenticidade de uma pessoa ou
agente externo de um sistema a fim de assegurar a integridade de origem.
Neste sentido a ferramenta para segurança da informação tem como
definição o conjunto de software, hardware e técnicas que possuem o escopo
principal em prevenir e combater os ataques, segundo Cheswick (2005, p. 134-334),
normalmente são encontradas para diversas plataformas de sistemas operacionais
como Microsoft Windows, Linux, normalmente muitas dessas técnicas são
empregadas em conjunto para que possam suprir as necessidades de segurança de
seus usuários.
A seguir serão alocads as técnicas de segurança que podem ser utilizadas e
implantadas nas empresas ou para usuários, são elas:
1.1 FIREWALL
a) Firewall é um tipo de software que pode ser dividido em várias
categorias, mas que tem sempre a mesma finalidade como o de não
permitir a entrada de pacotes IP, impedindo as possíveis ameaças, os
tipos disponíveis são:

Filtro de pacotes faz uso de regras estáticas para filtrar pacotes
que tem origem em servidores externos, é muito comum e
considerado simples de ser configurado (CHESWICK, 2005, p.
175-226), um exemplo de filtro de pacote é o Iptables, originário
do Linux;

Proxy é um tipo de firewall que tem a finalidade de filtrar os
pacotes que são gerados na rede interna da empresa (LAN)
impedindo a conexão com servidores externos que podem ser
prejudiciais ao sistema de informação, normalmente estão nas
redes de compartilhamento de arquivos que contém diversas
ameaças denominadas como trojans, worms e vírus, estas
ameaças geralmente utilizam nomes e extensões de arquivos
como MP3, JPEG entre outros, podemos exemplificar essa
14
ocorrência com o conhecido Squid, que é um pacote que vem
na maioria das distribuições Linux;

Firewall pessoal é um software que intercepta as conexões de
entrada e saída em um computador, está baseado em regras
padrões ou definidas pelo usuário e decide quais conexões
podem ser aceitas e quais devem serem recusadas, um
exemplo é o sygate e o zone alarm como softwares pessoais;

Firewall reativo possui funções que permitem reconhecer
ataques e emitir alarmes quando encontrar seqüências de
pacotes IP chamadas de assinaturas e bloqueia o acesso
indevido automaticamente.
1.2 IDS
Outra técnica utilizada para a segurança da informação é o sistema de
detecção de intrusos – IDS, que são software cuja finalidade é de funcionar em
conjunto com um sistema de firewall a fim de dar maior segurança na comunicação
envolvendo tráfego IP (ROESCH, 2006, p. 131), tendo como exemplo o snort e o
airsnort, sendo este para redes wirelles.
Estes sistemas (IDS) permite a verificação do conteúdo de um pacote por
intermédio de um sistema de assinaturas, após a verificação, o sistema pode emitir
um alerta caso as assinaturas dos IDS não sejam compatíveis com o conteúdo do
pacote que chega, permitindo desta forma, aprimorar as configurações do firewall.
Os sistemas de IDS, igualmente os firewall possuem diversos tipos de configuração,
os mais conhecidos são: host-based detection (HIDS) e network-based intrusion
detection (NIDS).

Host-Based Intrusion Detection – HIDS, faz o monitoramento de um
sistema com base nos eventos registrados nos arquivos de log, os
eventos mais freqüentes monitorados são a utilização do
processados do computador, a modificação de privilégios em
15
arquivos e usuários além de processos do sistema operacional e
software que estão em execução;

Network-Based Intrusion Detection (NIDS), monitora o trafego por
intermédio da captura dos pacotes IP e da análise dos seus
cabeçalhos e conteúdo.
As possibilidades de aplicação de um IDS são as mais variadas, podendo
serem exploradas outras configurações, em função das necessidades de cada
empresa.
Outra técnica utilizada para a segurança da informação é a criptografia
que cifra uma informação, tornando-a incompreensível, exceto para os destinatários
e o transmissor, que sabem como decifra-la (KUROSE, 2003, p. 610).
A criptografia se faz necessária normalmente para uso em operações
bancárias e em compras on-line, operações estas que vem crescendo cada vez mais
nos dias de hoje.
Segundo Fitzgerald (2005), existe dois tipos diferentes de criptografia, a
simétrica e a assimétrica.
A criptografia simétrica é um algoritmo que utiliza a mesma chave para
criptografar e descriptografar uma mensagem.
Um algoritmo bastante difundido de criptografia simétrica é o DES – Data
Encryption Standard, de 56 bits desenvolvido pela International Bussiness Machines
– IBM e mantido pelo Nacional Institute of Standars and Tecnology – NIST. Outro
algoritmo também conhecido é o RC4, que possui uma chave de 256 bits
desenvolvido pela RSA Data Security.
Já a criptografia assimétrica também denominada como criptografia de
chave pública e possui um conjunto de duas chaves, uma que serve para
criptografar a mensagem e outra para descriptografá-la (KUROSE, 2003, p. 623).
Essa criptografia, o responsável por criptografar não transmite a chave para a
descriptografia e, deste modo, se a mensagem for capturada na transmissão, a
mesma não poderá ser entendida.
Um dos algoritmos assimétrico mais conhecido é o RSA que é mantido
pelo Massachusetts Institute of Technology – MIT, esta técnica forma a base para o
16
Public Key Infrastructure – PKI, que permite a utilização de chaves de até 1024 bits,
segundo Fitzgerald (2005, p. 263).
Segundo Stallings (1999), outra técnica bastante utilizada é Hash que é
uma função matemática aplicada em algoritmos que fazem uso de mensagens de
texto para criação de um código conhecido como menssage digest ou resumo de
mensagens.
Aplicação em um arquivo a função hash representa a execução de um
algoritmo de cálculo sobre o arquivo para geração de um número como resultado,
toda alteração pode produzir mudança do resultado calculado, possibilitando saber
se o arquivo foi alterado, este método pode ser aplicado para se ter a ciência se um
arquivo foi contaminado por um vírus ou se está corrompido.
As funções mais conhecidas deste sistema são: MD4 que permite valor
hash de 128 bits – RFC-1320; MD5 sendo um aprimoramento do MD4, utilizado pelo
pretty Good Privacy – PGP, RFC -1321; SHA-1, permite valor hash de 160 bits.
Estas funções hash são empregadas nos mecanismo de assinaturas
digitais, que podem ser definidas como um código utilizado para verificar a
integridade de uma informação ou mensagem. Neste caso a assinatura digitai pode
ser utilizada para a verificação de uma mensagem, ou seja, se o remetente de uma
mensagem é realmente quem diz ser, sendo feito por meio de criptosistemas
assimétricos, segundo relata Fitzgerald (2005, p. 250). Normalmente os algoritmos
mais conhecidos para este processo são o RSA e o DSS (TANENBAUM, 2003).
Entretanto
uma
das
técnicas
fundamentais
com
propriedades
criptográficas da segurança da informação é a autenticação que está relacionada a
proteção contra modificação acidental ou não de uma mensagem; atraso ou re-envio
de mensagens e; repúdio da autoria de uma mensagem. A autenticação pode ser
dividida em três grandes grupos: autenticação baseada no eu o usuário sabe;
autenticação com base no que o usuário possui e autenticação com base nas
características do usuário.

Autenticação baseada no que o usuário sabe – método baseado
em algum conhecimento do usuário, como as senhas, sendo
consideradas as chaves criptográficas nesta categoria, no entanto,
todas as técnicas relacionadas ao que o usuário sabe, são
passíveis de ataques originados por monitoramento de software
17
espiões como o CAIN, que vasculham o conteúdo das informações
recebidas e transmitidas pelo usuário, senha podem serem
descobertas caso o usuário não tome os devidos cuidados;

Autenticação com base no que o usuário possui – neste grupo
podemos incluir itens como crachás e cartões magnéticos, este
método é muito usual, mas está sujeito a ação do homem para a
sua execução;

Autenticação com base nas características do usuário – pode-se
incluir neste grupo as digitais do usuário, controle por íris, retina,
voz, padrões de escrita entre outros, este grupo encontram-se uma
variedades de dispositivos para implantar a segurança dentro das
empresas, que em alguns casos estão se tornando muito comum,
como a identificação por voz ou digitais.
Entretanto para este tipo de sistema as empresas devem escolher as
opções que mais de adaptem as necessidades das mesmas e que se amoldem as
necessidades estratégicas e financeiras, já que o mercado esta sempre em
evolução.
Considerando
o
cenário
apresentado
acima,
encontramos
uma
necessidade em proporcionar um suporte a segurança da informação às múltiplas
organizações e comunidades que muitas vezes têm interesses sobrepostos. Em tal
situação, o controle de acesso às informações é condição essencial nos sistemas
atuais.
Vale observar que, atualmente, a grande maioria das informações
disponíveis nas organizações encontra-se armazenadas e são trocadas entre os
mais variados sistemas automatizados. Neste sentido, inúmeras vezes decisões e
ações tomadas são procedentes das informações manipuladas por esses sistemas.
Dentro deste contexto, toda e qualquer informação deve ser fidedigna,
precisa e estar disponível, a fim de ser armazenada, recuperada, manipulada ou
processada, além de poder ser trocada de forma segura e confiável. É adequado
destacar que, nos dias atuais, a informação constitui uma mercadoria, ou até mesmo
uma commodity, de extrema importância para as organizações dos diversos
18
segmentos. Por esta razão, segurança da informação tem sido uma questão de
elevada prioridade nas organizações.
2. VULNERABILIDADE DE PROGRAMAÇÃO
Em concordância com Staa (2006), pode-se dizer que uma falta em um
programa é um defeito concentrado que, quando exercitado, tem o potencial de
gerar um erro.
Erros são caracterizados pelo acontecimento de uma ação, cálculo ou
resultado incorreto produzido pelo programa, e podem ser classificados segundo a
causa da incorretude, por exemplo: erros de produção são causados ao designar ou
alterar elementos de um sistema; erros de processamento ocorrem quando há um
estado ou resultado indesejado; erros de uso são gerados a partir da operação do
software e podem ser esperados ou excepcionais.
Os erros esperados são aqueles conjeturados na codificação; por exemplo,
alguns erros humanos, erros de transmissão de dados, esgotamento de memória,
dentre outros. Os erros excepcionais são aqueles que violam as assertivas
implementadas.
Um erro, quando observado por um observador de erros, se torna uma falha;
em outras palavras, falhos são erros compreendidos por mecanismos capazes de
compreender a ocorrência de um comportamento deficiente do programa sejam
estes observadores pessoas ou quaisquer instrumentos de verificação. Aqui dizemos
que existem uma falta de segurança quando é possível obter informações ou
permissões privilegiadas do sistema, ou simplesmente torná-lo indisponível, por
meio da exploração do defeito.
De forma mais genérica, pode-se dizer que uma vulnerabilidade é qualquer
aspecto da informação, ou sistema, que permita a violação da sua segurança. As
vulnerabilidades de software são, na maioria das vezes, ou faltas de segurança, ou
problemas intrínsecos à sua arquitetura.
O que caracteriza um software seguro de acordo com os conceitos de
fidedignidade (STAA, 2006).
19
2.1 - EXPLORANDO VULNERABILIDADES
A melhor forma de entender a criticidade dos erros de programação é ver na
prática como são explorados.
2.2 - ARQUITETURA DE SISTEMAS
A compilação do código fonte explana sua linguagem para opcodes, e
armazena em disco no formato do binário ELF (Executable and Linkable Format).
Para ser executado o código é lido do binário (disco) para a memória
principal. Em seguida, o processador transporta e executa seqüencialmente os
opcodes. Na arquitetura x86 64-bits, o conteúdo dos segmentos é passado para o
processador por meio do ponteiro (registrador) de instrução %rip. Este registrador é
extraordinariamente importante porque, como referência a próxima instrução a ser
executada, pode ser usado para violar a segurança do sistema desde que possamos
apontá-lo para uma área de memória arbitrária.
Cabe, deste modo, encontrar uma forma de transgredir a segurança.
Imaginemos que um servidor de e-mails tem uma vulnerabilidade que permita
sobrescrever seu frame pointer (%eip). Ao enviarmos no corpo da mensagem uma
seqüencia de opcodes que, quando executada, é capaz de abrir um shell em uma
porta TCP, pode-se ter acesso total ao sistema com os direitos de acesso do
processo explorado.
Assumindo que a máquina é vulnerável, basta marcar o %rip para o início da
seqüência no corpo da mensagem. O sistema operacional, inicialmente, não pode
compreender que este segmento da memória não deve ser executado; e com isso
sua segurança é fatalmente corrompida.
O conhecimento da arquitetura do computador atacado é, quase sempre,
muito útil para quem quer desenvolver o exploit.
20
2.3 - GERENCIAMENTO DE MEMÓRIA
No início da primeira década as principais vulnerabilidades encontradas em
softwares empreendiam erros de gerenciamento de memória (os buffer overflows).
Os overflows são estouros de espaços reservados para alocar informação.
Alguma detonação ocorre por causa do tamanho do segmento e podem alcançar
áreas críticas do processo que podem ser utilizadas para execução de código
arbitrário.
Outros tipos de overflows ultrapassam os limites de representação numérica,
e podem permitir que a segurança seja comprometida, ainda que em casos bastante
especiais.
Geralmente estes problemas ocorrem em códigos que não têm a
preocupação com o tamanho do buffer na escrita dos dados. Por exemplo, se um
vetor guarda espaço para doze bytes e vinte bytes são copiados sobre ele, existe
um estouro de oito bytes escritos em um espaço (teoricamente) não permitido. Este
espaço pode ser usado em algum momento para manipular o registrador de
instrução.
Quando não há a averiguação do tamanho do buffer destino, dizemos que
não há bound checking. Esse espaço alcançado pelo estouro pode, eventualmente,
ser o return address de uma chamada de função; ou um ponteiro para função, etc.
As próximas seções discutem técnicas de exploração de buffer overflows em mais
detalhes.
2.4 - PROCESSAMENTO DE ENTRADAS
Outro tipo de erro muito cometido por programadores é deixar lacunas para acessos
indevidos ao processar entradas. Um exemplo muito comum encontrado em
centenas de aplicações hoje em dia são os sql injections.
O que significa SQL injeção, consideramos que o campo Telefone de um
formulário web insira os dados digitados pelo usuário através da variável “$PHONE”,
no comando de SQL “select * from table1 where phone=$PHONE”. Se o usuário, de
forma maliciosa, digita “2233-2222”; select passwd from table2 where user=Guest”
no campo, e os sistemas são vulneráveis, ele consegue também o resultado da
segunda query. Na prática este tipo de falta quase sempre consente o acesso
21
irrestrito ao banco de dados. Muitas outras vulnerabilidades decorrem do mal
processamento de inputs.
2.5 - BUFFER OVERFLOW
O buffer overflow, ou buffer overrun, incide quando um processo tenta
armazenar dados além dos limites permitidos. O resultado é que essa informação
extra sobrescreve áreas adjacentes de memória. A área sobrescrita pode
compreender buffers ou variáveis que influenciem no fluxo do código.
2.5.1 -STACK OVERFLOW
Pode-se dizer que há um stack overflow quando qualquer espaço do
segmento pilha é sobrescrito. Em algumas situações é possível tirar serventia de um
stack overflow para executar códigos arbitrários no sistema. Por exemplo, no
programa abaixo a variável buff recebe o primeiro argumento passado pela linha de
comando.
void foobar (char * s ) {
char buf [ 2 5 6 ] ;
strcpy (buf , s) ;
}
int main (int argc , char **argv) {
foobar ( argv [ 1 ] ) ;
return 0 ;
}
O espaço reservado para variável é de 256 bytes. O que acontece quando
passamos um argumento muito maior? A função strcpy (dst; src) lê o conteúdo do
src até encontrar um zero (final de string) copiando o conteúdo para dst. No entanto
não é garantido que o destino possa comportar todos os bytes de src.
Top = 0xFF
22
argv[1]
retaddr
%rbp
buf[255]
...
buf[0]
Bottom = 0x00
Conforme o código acima demonstra o estado da stack no momento antes da
chamada de strcpy( ). A cópia dos dados é feita escrevendo o primeiro byte de src
(s) na primeira posição de dst (buf), sucessivamente até o que strcpy encontre um
caractere null em src. A descrição da cópia já sugere que ocorre overflow quando o
tamanho da origem dos dados é maior que o destino.
Quando a função foobar( ) for chamada, a instrução call insere na pilha o
endereço de retorno (retaddr ). Ao término da função a instrução ret restaura o valor
do retaddr para o registrador %rip (ou %eip na arquitetura IA-32), que indica qual a
próxima instrução a ser executada.
Podem-se sobrescrever o valor do retaddr é possível conseguir o controle do
fluxo das instruções. Um argumento de tamanho 272 bytes (+padding) seria grande
o suficiente para sobrescrever o retaddr com seus últimos oito bytes. Bastando então
apontá-lo para um buffer que contenha as instruções que desejamos executar _ eg.,
os shellcodes.
Koziol et al. (2004) mostra como fazer shellcodes para este fim. Para
simplificar, a função lostfunc faz o papel do código arbitrário. Nosso objetivo é
executá-la através da manipulação do return address. O código abaixo é o arquivo
1i:c completo. Veja que a função lostfunc não é referenciada em nenhum momento e
não deve ser executada exceto se o fluxo do programa for desviado.
i.c
#include <s t d i o . h>
#include <s t r i n g . h>
#include <s t d l i b . h>
23
void foobar ( char _ s ) {
char buf [ 2 5 6 ] ;
s t r cpy ( buf , s ) ;
}
int main ( int argc , char __ argv ) {
foobar ( argv [ 1 ] ) ;
11 return 0 ;
12 }
13
14 void l o s t f u n c ( ) {
15 p r i n t f ( " E x p l o i t e d . \ n" ) ;
16 e x i t ( 0 ) ;
17 }
O padding das variáveis locais não é fixo entre arquiteturas e compiladores,
por isso o primeiro passo é traduzir o código da função foobar() para assembly de
forma a saber como o gcc trata a alocação das variáveis.
i.s
foobar :
.LFB5 :
pushq %rbp
. LCFI0 :
movq %rsp , %rbp
. LCFI1 :
subq $272 , %r sp
. LCFI2 :
movq %rdi , �8(%rbp )
movq �8(%rbp ) , %r s i
l e aq �272(%rbp ) , %r d i
c a l l s t r cpy
leave
ret
24
O código acima foi gerado pelo GCC com a flag “ –S”, que o instrui a parar o
processo de geração do binário antes da etapa de compilação. Veja que 7 salva o
valor do registrador %rbp da main, e corresponde a alocação da variável buf de
foobar segundo a representação acima. Nos 64-bits seguintes à %rbp está o retaddr.
Se passamos um argumento de 288 bytes conseguimos atingir a área de memória
que será copiada sobre %rip na saída de foobar. Basta que o conteúdo da última
posição do input seja o endereço de lostfunc. A ferramenta objdump nos ajuda a
localizar lostfunc no binário 1i.
savio@halcyon:src% objdump -d 1i | grep lostfunc
000000000040053f <lostfunc>:
savio@halcyon:src%
Sabendo que o primeiro opcode de lostfunc está no endereço 0x40053f, basta
fazer com que os últimos oito bytes do input malicioso contenham este valor.
Como passar o endereço da função requer o input de caracteres nãoimprimíveis usamos o interpretador da linguagem Perl para fazê-lo. E por fim:
savio@halcyon:tmp% ./1i `perl -e 'print "A"x280,"\x3f\x05\x40","\x00"x5'`
Exploited.
Portanto, usamos um input grande o suficiente para cobrir todo o buffer
alocado para a variável buf e suas vizinhanças. Este input contém o endereço da
função lostfunc em uma posição específica para sobrescrever o return address de
foobar. Este por sua vez é copiado para o registrador %rip quando a função retorna,
i.e., quando a instrução ret é processada.
Como seria então a versão segura deste programa?
s.c
#include <s t d i o . h>
#include <s t r i n g . h>
#include <s t d l i b . h>
void foobar ( char _ s ) {
char buf [ 2 5 6 ] ;
s t rncpy ( buf , s , s izeof ( buf )�1);
buf [ s izeof ( buf )�1] = 0 ;
}
int main ( int argc , char __ argv ) {
25
foobar ( argv [ 1 ] ) ;
return 0 ;
}
A função strncpy(dst; src; n) é como a strcpy porém faz o bound checking
necessário para não permitir um overflow. A diferença é que no máximo n bytes de
src são copiados para dst, como especificado no terceiro argumento.
A linha 7 copia 255 bytes de s para buf guardando a última posição para o
delimitador de final de string (o caractere null ou zero) atribuído em 8. O resultado é
uma função um tanto mais confiável para o software. Por fim, a mesma tentativa de
sobrescrever o return address falha com a nova versão do programa.
savio@halcyon:src% ./1s `perl -e 'print "A"x288'`
savio@halcyon:src% echo $?
0
Existem patches para alguns sistemas operacionais que impedem ou
dificultam a execução dos dados da stack. Desta forma, mesmo que o registrador
%rip aponte para um shellcode na parte da memória referente à pilha, este não
poderá ser executado.
O kernel do sistema operacional Solaris 2.6, por exemplo, oferece a opção
protect_stack. O StackGuard, desenvolvido por Crispin Cowan, também se aplica ao
mesmo _m. O StackGhost é uma proteção baseada em características da
arquitetura SPARC, que dificulta a exploração de buffer overruns. Este último foi
otimizado e integrado ao OpenBSD. Outros tantos softwares foram desenvolvidos
para proteger a stack.
2.5.2 - HEAP OVERFLOW
O senso comum indica que qualquer memória dinamicamente alocada pela
aplica ção é chamada heap. Pela aplicação porque a requisição deste espaço é feita
pelo usuário (user land) ao kernel através de system calls. Uma das implementações
da função malloc() da GNU C Library, por exemplo, faz chamadas à brk() e mmap()
de acordo com o tamanho requisitado.
A seção do formato ELF que contém variáveis não inicializadas do programa
é chamada bss (Block Started by Symbol); o mesmo que o data segment para os
26
compiladores. Como estas variáveis são inicializadas em run-time é comum
utilizarmos os valores deste segmento na exploração dessas vulnerabilidades. Por
isso alguns autores muitas vezes usam o termo heap/bss-based overflow para se
referir a estas falhas.
Na maioria dos sistemas a heap cresce no sentido positivo (ao contrário da
stack).
Top = 0xFF
Bottom = 0x00
Stack
Heap
Stack+Heap
Existem muitas técnicas que exploram buffer overflows. Para cada técnica
teremos abordagens de exploração da heap completamente diferentes.
3. A VULNERABILIDADE NA WEB
A proteção de servidores de aplicações web, permitindo acesso às aplicações
unicamente por pessoas autorizadas, é uma necessidade global. A razão dessa
necessidade é o acréscimo considerável da demanda pelo desenvolvimento de
aplicações web, pois programadores, empresas e corporações têm observado que a
Internet é atualmente um dos meios mais importantes para o comércio e isso
ocasionou o desaparecimento das antigas fronteiras para realização de negócios.
Um dos maiores problemas que empresas que disponibilizam sistemas web
vêm
encarando
é
o
aumento
exponencial
dos
ataques
que
exploram
vulnerabilidades presentes em aplicações web.
Essas vulnerabilidades em questão são oriundas do processo de engenharia
de software, o qual não é conduzido, desde a fase de planejamento, considerando
aspectos relativos à segurança das aplicações para web, e colocam as aplicações e
conseqüentemente as empresas em risco, podendo levar ao vazamento de
informações privilegiadas, o que pode acarretar no comprometimento do modelo de
negócio (McGRAW, 2006).
Apesar das dificuldades no tratamento de falhas de aplicações, devido
aparecimento de novas vulnerabilidades e da diversificação das técnicas de ataques
27
a camada de aplicação (CERT.BR, 2009), algumas empresas têm empregado
possíveis soluções para esse problema como: a utilização de um processo de
software ágeis e confiáveis e baseados em testes de segurança e a utilização de
IDS (Intrusion Detection Systems) (BACE AND MELL, 2001). Entretanto, nenhuma
dessas medidas ataca o problema de forma eficaz ou pelo menos dá ao
desenvolvedor a garantia de proteção da sua aplicação.
As questões apresentada neste trabalho, é implementada pelo meio de um
firewall de aplicações que trabalha absolutamente na camada de aplicação, como
um agente detector de padrões de ataques que encaminha o tráfego suspeito para
honeypots, além de funcionar como ponto único de verificação através de um proxy
reverso e filtrar os possíveis pacotes que possam apresentar ameaças à aplicação,
criando uma camada de filtragem de forma segura e confiável.
3.1 WEB APPLICATION FIREWALL
Segundo WAFEC (2006), Web Application Firewall (WAF) é uma nova
tecnologia de segurança que tem a função de proteger aplicações web de ataques.
As soluções de um WAF são capazes de precaver ou até mesmo neutralizar um
ataque a uma aplicação, conseguindo filtrar de forma eficiente o que um IDS
(Intrusion Detection Systems) e firewalls de rede não conseguem. Isso se deve ao
fato de um WAF agir diretamente na camada de aplicação, filtrando os dados e
principalmente parâmetros utilizados em uma transação HTTP (JONES, BEJTLICH
AND ROSE, 2006).
3.2 - IMPLEMENTAÇÕES DE UM WAF
Os WAFs podem ser implementados de três formas distintas, cada uma
possuindo vantagens e desvantagens. Segundo WAFEC (2006), as formas de
implementação de um WAF são:

No nível da camada de rede.

Através de um proxy reverso.
28

Diretamente no servidor web.
3.3 - TÉCNICAS DE DETECÇÃO DE ATAQUES DE UM WAF
De acordo com WAFEC (2006), os firewalls de aplicações Web podem ser
configurados para detectar ataques de três diferentes formas:

Técnicas de normalização.

Modelo de segurança negativo.

Modelo de segurança positivo.
3.4 - TÉCNICAS DE NORMALIZAÇÃO
Um dos grandes problemas que os desenvolvedores de WAF perceberam,
são as inúmeras maneiras que atacantes fazem uso para burlar o filtro de regras e
assinaturas de ataques do firewall de aplicações (técnicas de evasão). As técnicas
de normalização consistem em reconstruir a assinatura do ataque interpretando as
tentativas de evasão que foram utilizadas para burlar o filtro do WAF.
3.5 - MODELO DE SEGURANÇA NEGATIVO
O modelo de segurança negativo é simples de ser configurado e tem por
alicerce permitir o tráfego de todos os pacotes de solicitação, filtrando simplesmente
aqueles que obedecem a alguma assinatura ou regra do WAF (black list). O sucesso
dessa implementação é determinado pela eficiência com que o firewall de aplicação
Web consegue detectar solicitações nocivas, de acordo com sua base de regras e
assinaturas.
O problema em implementar o modelo de segurança negativo, reside no risco
do banco de dados de regras filtrar um grande número de falso-positivos (quando a
regra filtra pacotes autênticos da aplicação) e por esse modelo ser mais suscetível a
técnicas de evasão.
A vantagem de se usar o modelo de segurança negativo é decorrente da
facilidade de configuração que o mesmo proporciona, pois serão criadas regras e
assinaturas de ataques que serão aplicadas a todas as requisições.
29
3.6 - MODELO DE SEGURANÇA POSITIVO
O modelo de segurança positivo é complexo analisando sua configuração e
implementação. Por padrão ele impede todo e qualquer tráfego e permite somente
os pacotes de solicitação que respeitem a algumas regras que garantem que a
solicitação é segura para a aplicação (white list). Essa forma de configuração é mais
segura e eficiente, pois necessita de menos regras de segurança para filtragem.
O problema em configurar um firewall de aplicação com esse modelo se deve
a enorme necessidade de conhecimento sobre a aplicação e, a partir desse
conhecimento, avaliar o que é nocivo ou não e assim, criar uma regra totalmente
personalizada para proteger a aplicação de ataques.
3. 7 - ATAQUES A APLICAÇÕES WEB
De acordo com Ceron et al. (2008), os ataques contra aplicações web
representam uma parcela estimável dos incidentes de segurança ocorridos nos
últimos anos. Isso vem ocorrendo pela falta da devida preocupação com requisitos
de segurança nessas aplicações. Esse é um dos fundamentais motivos que
explicam o fato da Internet ter se tornado um ambiente repleto de vulnerabilidades e
alvo de freqüentes ataques. O problema se agrava mais ainda com a utilização dos
mecanismos de busca como uma poderosa ferramenta para localizar sites e
sistemas vulneráveis.
Segundo o instituto de pesquisa OWASP (2007) as 10 (dez) vulnerabilidades
mais críticas em aplicações web em ordem são:

Cross Site Scripting (XSS);

Falhas de Injeção (SQL Injection, PHP Injection, etc);

Execução maliciosa de arquivos (RFI, LFI);

Referência Insegura Direta a Objetos;

Cross Site Request Forgery (CSRF);

Vazamento de Informações e Tratamento de Erros Inapropriado;

Autenticação falha e Gerenciamento de Sessão;

Armazenamento Criptográfico Inseguro;

Comunicações inseguras;

Falha de Restrição de Acesso à URL.
30
A maioria das vulnerabilidades citadas acima é ocasionada por erros na etapa
de desenvolvimento da aplicação, sendo raras delas ocasionadas por problemas de
má configuração de serviços em um servidor.
Atualmente uma das soluções adotadas para defesa contra esses ataques,
são a revisão de código e a adoção de metodologias e práticas de desenvolvimento
de código seguro como, por exemplo, a centralização da verificação dos dados de
entrada.
O problema dessa solução se encontra no alto custo de manutenção e
treinamento para capacitar a equipe em desenvolvimento de códigos seguros, além
da necessidade do gerenciamento constante da segurança da aplicação. A
ferramenta apresentada neste artigo poderá realizar uma grande variedade de testes
automatizados para detectar falhas na utilização de mecanismos de segurança e,
inclusive, vulnerabilidades presentes no código das aplicações.
3.8 - VULNERABILIDADE DOS SERVIÇOS WEB
Os primeiros ataques rede exploravam vulnerabilidades ligadas à aplicação dos
protocolos
da
sequência
TCP/IP.
Com
a
correcção
progressiva
dessas
vulnerabilidades, os ataques deslocaram-se para as camadas aplicativas e em
especial a web, na medida em que a maior parte das empresas abre o seu sistema
firewall para o tráfego destinado à web.
O protocolo HTTP (ou HTTPS) é o standard que permite veicular as páginas web
através de um mecanismo de pedidos e de respostas. Utilizado essencialmente para
transportar páginas web informativas (páginas web estáticas), o web tornou-se
rapidamente um apoio interactivo que permite fornecer serviços em linha. O termo “
aplicação web” designa, assim, qualquer aplicação cujo interface está acessível
através da web com a ajuda de um simples navegador. Transformado no apoio de
um certo número de tecnologias (SOAP, Javascript, XML RPC, etc.), o protocolo
HTTP possui doravante seguramente um papel estratégico na segurança dos
sistemas de informação.
31
Dado que os servidores web estão cada vez mais protegidos, os ataques
deslocaram-se progressivamente para a exploração das falhas das aplicações web.
Assim, a segurança dos serviços web deve ser um elemento a ter em conta desde a
sua concepção e o seu desenvolvimento.
3.8.1 - TIPOS DE VULNERABILIDADES
As vulnerabilidades das aplicações web podem catalogadas da seguinte forma :
Vulnerabilidades do servidor web. Este tipo de caso é cada vez mais raro
porque progressivamente os principais programadores de servidores web
reforçaram a sua segurança;
Manipulação dos URL, consistindo em alterar manualmente os parâmetros
dos URL a fim de alterar o comportamento esperado do servidor web;
Exploração das fraquezas dos identificadores de sessão e os mecanismos de
autenticação;
Injecção de código HTML e Cross-Site Scripting;
Injecção de comandos SQL.
3.9 - VERIFICAÇÃO DOS DADOS DE ENTRADA
O protocolo HTTP tem como rotina receber dados de entrada e saída . Os dados são
enviados nas seguintes situações: EX:URL, RUBRICAS HTTP e também através de
coockie.
O princípio básico a reter geralmente, quando de qualquer desenvolvimento
informático, é que não deve confiar nos dados enviados pelo cliente.
Assim, a quase totalidade das vulnerabilidades dos serviços web está ligada às
negligências dos criadores, que não fazem verificações sobre o formato dos dados
apreendidos pelos utilizadores.
32
3.10 - IMPACTO DOS ATAQUES WEB
Os ataques contra as aplicações web são sempre prejudiciais porque dão uma má
imagem da empresa. As consequências de um ataque bem sucedido podem
nomeadamente ser uma das seguintes:
Apagamento do web site;
Roubo de informações;
Modificação de dados, nomeadamente modificação de dados pessoais de
utilizadores;
Intrusão no servidor web.
3.11 - INTRODUÇÃO ÀS URL
A URL (Uniforme Recurso Localizador) de uma aplicação web é o vector que permite
indicar o recurso pedido. Tratam-se de caracteres ASCII que se podem imprimir e
que se decompõe em cinco partes:
O nome do protocolo: quer dizer, em certa medida, a linguagem utilizada
para comunicar na rede. O protocolo mais utilizado é o protocolo HTTP
(HyperText Transfer Protocol), o protocolo que permite trocar páginas Web no
formato HTML. Numerosos outros protocolos são contudo utilizáveis (FTP,
News, Mailto, etc.)
Identificador e palavra-passe: permite especificar os parâmetros de acesso
a um servidor protegido. Esta opção é desaconselhada porque a palavrapasse circula de forma clara no URL
O nome do servidor: Trata-se do nome de domínio do computador que aloja
o recurso pedido. Note que é possível utilizar o endereço IP do servidor.
O número de porta: trata-se de um número associado a um serviço que
permite ao servidor saber que tipo de recurso é pedido. A porta associada por
defeito ao protocolo é a porta número 80. Assim, quando o serviço Web do
33
servidor é associado ao número de porta 80, a especificação do número de
porta é facultativa.
O caminho de acesso ao recurso: Esta última parte permite ao servidor
conhecer o lugar onde está situado o recurso, quer dizer, geralmente o lugar
(directório) e o nome do ficheiro pedido.
A URL pode permitir a transmissão de parâmetros ao servidor, fazendo seguir o
nome de ficheiro por um ponto de interrogação, e depois dados em formato ASCII.
Uma URL é assim uma cadeia de caracteres com o seguinte formato:
http://pt.kioskea.net/forum/index.php3?cat=1&page=2</code>
3.11.1 - MANIPULAÇÃO DE URL
Manipulando certas partes de uma URL, um pirata pode levar um servidor web a
emitir páginas web às quais não é suposto ter acesso.
Com efeito, nos sites web dinâmicos os parâmetros são, na sua maioria, passados
através da URL como segue:
http://cible/forum/index.php3?cat=2</code>
Os dados presentes na URL são criados automaticamente pelo site e, aquando de
uma navegação normal, um utilizador apenas clica nas ligações propostas pelo site
web. Assim, se um utilizador alterar manualmente o parâmetro, pode tentar
diferentes valores, como por exemplo:
http://cible/forum/index.php3?cat=6</code>
Se o criador não antecipou esta eventualidade, o pirata pode, eventualmente, ter
acesso a um espaço normalmente protegido.
34
Além disso, o pirata pode levar o site a tratar um caso inesperado, como por
exemplo:
http://cible/forum/index.php3?cat=***********
No caso acima, se o criador do site não tiver previsto a possibilidade de o dado não
ser um número, o site pode entrar num estado não previsto e revelar informações
numa mensagem de erro.
3.12 - TENTATIVAS ÀS CEGAS
Um pirata pode eventualmente testar directórios e extensões de ficheiro às cegas,
para encontrar informações importantes. Eis alguns exemplos clássicos:
Procura de directórios que permitem administrar o site:
http://cible/admin/
http://cible/admin.cgi</code>
Procura de script que permita revelar informações sobre o sistema distante:
http://cible/phpinfo.php3</code>
Procura de cópias de salvaguardas. A extensão .bak é utilizada geralmente
e não é interpretada por defeito pelos servidores, o que pode conduzir à
afixação de um certificado:
http://cible/index.php3.bak</code>
Procura de ficheiros do sistema distante escondidos.
Sob os sistemas
UNIX, quando o directório raiz do site corresponde ao directório de um
utilizador, é possível que ficheiros criados pelo
através da web:
sistema sejam acessíveis
35
http://cible/.bash_history
http://cible/.htaccess</code>
3.13 - CRUZAMENTO DE DIRECTÓRIOS
Os ataques chamados “Cruzamento de directórios” (em inglês directory traversal ou
path traversal) consistem em alterar o caminho da arborescência na URL para forçar
o servidor a aceder a secções não autorizadas do site.
Num caso clássico, o utilizador pode ser levado a subir progressivamente na
arborescência, nomeadamente se o recurso não é acessível, por exemplo:
http://cible/base/test/ascii.php3
http://cible/base/test/
http://cible/base/</code>
Nos servidores vulneráveis, basta subir o caminho com várias cadeias do tipo« ../ » :
http://cible/../../../../repertoire/fichier</code>
Ataques mais evoluídos consistem em codificar certos caracteres:
ou sob a forma de codificação de URL:
http://cible/..%2F..%2F..%2Frepertoire/fichier</code>
ou com uma notação Unicode:
http://cible/..%u2216..%u2216repertoire/fichier</code>
36
Numerosos sites dinâmicos passam o nome das páginas a afixar em parâmetro
sob uma forma próxima da seguinte:
http://cible/cgi-bin/script.cgi?url=index.htm</code>
Por muito pouco que um controlo não seja realizado, é possível que um pirata altere
a URL manualmente a fim de pedir o acesso a um recurso do site ao qual não tem
acesso directamente, por exemplo:
http://cible/cgi-bin/script.cgi?url=script.cgi</code>
3.13.1 - DESFILES
Para proteger um servidor web contra os ataques por manipulação de URL, é
necessário efectuar uma vigilância sobre as vulnerabilidades e aplicar regularmente
as correcções fornecidas pelo editor do servidor web.
Além disso, uma configuração meticulosa do servidor web permite evitar que um
utilizador navegue em páginas às quais não é suposto ter acesso. Assim, o servidor
web deve ser configurado seguindo as instruções seguintes:
Impedir o percurso das páginas situadas debaixo da raiz do site web
(mecanismo de chroot);
Desactivar a afixação dos ficheiros presentes num directório não contendo
ficheiro de índices (“Directory Browsing”);
Suprimir os directórios e ficheiros inúteis (entre os quais os ficheiros
escondidos);
37
Assegurar-se que o servidor protege o acesso aos directórios que contêm
dados sensíveis;
Suprimir as opções de configuração supérfluas;
Assegurar-se que o servidor interpreta correctamente as páginas
dinâmicas, incluindo os ficheiros de salvaguarda (.bak);
Suprimir os intérpretes de scripts supérfluos;
Impedir a consulta em modo HTTP das páginas acessíveis em HTTPS
3.13.2 - ATAQUES POR FALSIFICAÇÃO DE DADOS
A maior parte dos ataques de aplicações web consiste em solicitar o site com dados
introduzidos manualmente a fim de provocar um contexto não previsto.
3.13.3 - PARÂMETROS DAS APLICAÇÕES WEB
O protocolo HTTP, apoio da comunicação na web, permite veicular parâmetros sob
formas de pedidos de várias maneiras:
Cookies ;
Campos de formulários;
URL ;
Rubricas HTTP.
É essencial compreender que todos os meios de transmissão de dados podem ser
manipulados sem problema por um utilizador e que, por conseguinte, os dados
utilizadores não devem ser considerados como fiáveis. Desta maneira, é
impossível basear a segurança em controlos realizado por parte do cliente (valores
propostos por um formulário HTML ou códigos Javascript que verificam a exactidão
dos dados).
Além disso, o estabelecimento de uma conexão SSL não protege em nada contra a
manipulação dos dados transmitidos, apenas certifica a confidencialidade do
transporte da informação entre o utilizador final e o site web.
Assim, qualquer projectista de aplicação web deve necessariamente efectuar um
controlo dos dados, tanto sobre o seu valor (mínimo e máximo para um dado
numérico, controlo dos caracteres), como sobre o seu tipo e o seu comprimento.
38
CONCLUSÃO
Foi abordado ao longo do texto que segurança da informação compreende um
conjunto de medidas que visam proteger e preservar informações e sistemas de
informações,
assegurando-lhes
integridade,
disponibilidade,
não
repúdio,
autenticidade e confidencialidade. Esses elementos constituem pilares da segurança
da informação e, portanto, são essenciais para assegurar a integridade e
confiabilidade em sistemas de informações. Nesse sentido, esses pilares,
juntamente com mecanismos de proteção têm por objetivo prover suporte a
restauração de sistemas informações, adicionando-lhes capacidades detecção,
reação e proteção.
Os
componentes
criptográficos
da
segurança
da
informação
tratam
da
confidencialidade, integridade, não repúdio e autenticidade. Vale, no entanto,
ressaltar que o uso dos pilares é feito em conformidade com as necessidades
específicas de cada organização. Assim, o uso desses pilares pode ser determinado
pela suscetibilidade das informações ou sistemas de informações, pelo nível de
ameaças ou por quaisquer outras decisões de gestão de riscos. Perceba que esses
pilares são essenciais no mundo atual, onde se tem ambientes de natureza pública e
privada conectados a nível global.
39
REFERÊNCIAS BIBLIOGRÁFICAS
CERT.BR Estatísticas dos Incidentes Reportados ao CERT.br. Disponível em:
http://www.cert.br/stats/incidentes/index.html, Acesso em ago. de 2010.
CHESWICK, W et al. Firewalls e segurança na internet. 2.ed. Porto Alegre:
Bookman, 2005.
FITZGERALD, J. Comunicação de dados empresarias e redes. Rio de Janeiro:
LTC, 2005.
JONES, K. J., BEJTLICH, R., ROSE, C. W. Real Digital Forensics – Computer
Security and Incident Response. São Paulo: Addison-Wesley, 2006.
KUROSE, J F; ROSS, K W. Redes de computadores e a internet. São Paulo:
Addison Wesley, 2003.
McGRAW, G. Software Security – Building Security In. São Paulo: Addison-Wesley,
2006.
STALLINGS, W. Cryptografhy and network security: principles and pratice.
3.ed. New York: Prentice-Hall, 2003.
TANENBAUM, A S. Redes de computadores. 4.ed. Rio de Janeiro: Campus, 2003.
OWASP (2007). The ten most critical web application security vulnerabilities. Open
Web
Application
Security
ProjectOWASP.
Disponível
em:
http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf. Acesso em ago. de
2010
WAFEC (2006). Web Application Firewall Evaluation Criteria. Web Application
Security
Consortium.
Disponível
em:
http://www.webappsec.org/projects/wafec/v1/wasc-wafec- v1.0.pdf. Acesso em ago.
de 2010.
pt.kioskea(2010)http://pt.kioskea.net/contents/attaques/falsification-donnees.php3.
Acesso em 10 nov. de 2010 ás 13:00 hs.
MENDES, Romeu - Administrador de Empresas, com especialização em Gestão
da Tecnologia da Informação. – Disponível em: www.administradores.com.br/artigos
DOBKOWSKI, Gustavo - Diretor de Suporte e Hardware da empresa Firewalls,
sendo conhecedor de Linux há dois anos e especialista em cabeamento estruturado,
sendo integrador oficial dos produtos 3M (VIP – Volition Integrator Professional).