Unidade de Ensino - 5 - V25NOV2014

OSTENSIVO GUIA DE ESTUDO
Marinha do Brasil
Nesta unidade conheceremos:
• As principais definições em Segurança em Aplicações;

• O contexto de Segurança em Aplicações;e
• As principais técnicas de Defesa em Aplicações.
OSTENSIVO 5-1
OSTENSIVO 5-2
Conceitos
Na parte inicial desta matéria, vamos rever alguns conceitos

importantes sobre aplicações e os principais aspectos de segurança.
Todos os ícones do seu computador são aplicações que foram

desenvolvidas, seja por grandes corporações seja por uma equipe de
desenvolvimento interna da sua organização. Alguns sistemas são bastante
simples, outros extremamente complexos, mas todos são aplicações.
Vamos ver as principais etapas deste processo de desenvolvimento

de aplicações, visto que, neste processo estão os principais controles que nos
garantem a segurança da aplicação. Também vamos ver que o processo de
desenvolvimento inclui algumas vulnerabilidades potenciais que precisam ser
consideradas.
Vamos ver ainda os principais tipos e arquiteturas de aplicações.

Esse conhecimento será muito útil para identificarmos os modos de ataque e
mecanismos que precisamos para garantir a defesa desta aplicação.
Finalmente, vamos focar na arquitetura Web, visto ser amplamente

usada e um alvo central de ataques.
OSTENSIVO 5-3
O que é uma aplicação?
Tipicamente uma aplicação é uma ferramenta de auxilio a algum

tipo de atividade humana. Sistemas raramente tem objetivos em si mesmo.
Operadores, usuários, administradores, todas as aplicações tem uma forte
ligação com pessoas e servem também para objetivos humanos.
Uma aplicação geralmente vem automatizar um processo que já

existia antes. Poucos sistemas podem ser destacados como novidades reais.
Alguns processos anteriores eram muito diferentes, mas muitas
correspondências são claras. O objetivo, geralmente, é mantido.
Exemplos:
“Papel e caneta” x “Máquina de escrever” x “Word”
“Mural de recados” x “Orkut/Facebook”
“Telefone” x “SMS” x “Whatsapp”
Isso é importante para a segurança porque ao entender o processo

que a aplicação auxilia, podemos ver com clareza muito maior o nível de
segurança requerido, os dados que são críticos e as formas que um atacante
pode utilizar para sabotar o sistema.
OSTENSIVO 5-4
Toda aplicação é uma mudança
Um dos aspectos relevantes para a segurança é que a implementação

de um sistema ou de uma nova versão de um sistema sempre implica em algum tipo
de mudança. A forma atual de execução das tarefas, dos processos, é bem
conhecida de todos. A nova forma implica em mudança. Mesmo que o sistema seja
perfeito do ponto de vista de segurança, os usuários irão sentir a diferença e isso
pode levar a dificuldade de operação, falhas na operação do sistema, demora na
execução de tarefas e outros comprometimentos de segurança.
Nunca faça o deploy de um novo sistema as vésperas de um evento

crítico. A menos que exista um motivo muito forte, melhor um sistema imperfeito
cujos defeitos são conhecidos do que um novo sistema, por melhor que seja, cujos
usuários não sabem como tratar adequadamente.
OSTENSIVO 5-5
Toda aplicação é uma mudança
Muitas pessoas normalmente bastante cientes da necessidade de

privacidade de dados pessoais acabam divulgando inadevertidamente esses dados
quando utilizam facebook ou orkut.
Uma aplicação sempre terá muitas versões. Assim, numa organização

deve-se sempre planejar com muito cuidado a entrada em operação de novas
versões das aplicações.
Evite estrear novas tecnologias e novos sistemas, quando a segurança estiver

envolvida. Espere que a nova versão do Windows esteja bem estabelecida no
mercado, antes de planejar a troca de versão na organização.
OSTENSIVO 5-6
Como a criação de aplicações para auxílio nas mais diversas

atividades humanas traz grandes benefícios, este processo vem sendo
crescente na nossa sociedade.
A cada década mais processos são informatizados, gerando
benefícios como menores custos, maior comodidade, maior segurança e mais
praticidade.
Maior segurança? ... Sim, via de regra aplicações são mais
seguras que os processos físicos originais. Após o impacto inicial devido ao
desconhecimento da aplicação pelos usuários, os sistemas tem controles de
segurança muito melhores que os processos não informatizados. As eleições
brasileiras, por exemplo: não se pode garantir que não exista nenhuma fraude no
processo. Mas é inegavel que o número de controles de segurança sobre o
processo informatizado é maior que o que existia sobre a contagem de papel.
Primeiros foram os bancos. Depois indústria, comércio, a própria
população. Mesmo hoje vive-se o nascimento da era da justiça informatizada. E
isso não vai parar.
Mas como cada nova aplicação gera mudança, existem riscos,
problemas, demora na adaptação, falta de conhecimento dos usuários da
aplicação. Isso é continuamente explorado pelos atacantes.
OSTENSIVO 5-7
Custo da falha
A criação de aplicações para as mais diversas áreas leva, claro a

problemas de segurança. E esses problemas podem ter custos na casa dos
milhões de dólares.
Um caso clássico (mas não único) é a explosão do foguete Ariadne
5, em 1996. Todos os foguetes, desde as missões Appolo na década de 60
utilizam aplicativos para as mais diversas funções mas, principalmente para a
navegação.
A aplicação de navegação do Ariadne 5 apresentava um erro. Em
determinado trecho de código, ocorria uma falha conhecida como “overflow
numérico”. Essa falha se caracteriza por ocorrer apenas quando determinado
valor é muito grande. O valor, no caso do Ariadne 5, era a velocidade horizontal
do foguete. Note que a aplicação não foi desenvolvida para o Ariadne 5, foi
aproveitada do Ariadne 4. O Ariadne 4 fez dezenas de vôos sem qualquer
problema. Mas o Ariadne 5 era mais rápido...
http://www.youtube.com/watch?v=kYUrqdUyEpI
Outras falhas também custos enormes. Destaca-se a falha na

aplicação de cálculo de dose para radioterapia no Panamá em 2000, de onde
decorreram 8 mortes.
OSTENSIVO 5-8
Processo de Desenvolvimento
Porque existem erros e falhas de segurança em aplicações? Em

parte porque se tratam de mecanismos muito complexos, com muitas situações
e particularidades. Quanto mais complexo um sistema, maior a chance de
haverem falhas.
Com o intuito de diminuir a possibilidade de aplicações com erro e
falhas de segurança, a maior parte das equipes de desenvolvimento utiliza um
processo de desenvolvimento de aplicações. O processo de desenvolvimento
visa justamente garantir a qualidade e a segurança da aplicação gerada.
Assim, ao longo do processo de desenvolvimento, existem diversos
controles de garantia da segurança da aplicação. Esses controles serão vistos
em maior detalhe mais adiante. Por hora importante saber que o
desenvolvimento passa por etapas.
• Levantamento inicial, visando identificar o que a aplicação precisa conter, qual

processo irá automatizar.
• Análise e projeto, onde define-se o tipo e arquitetura de sistema, bem como
os detalhes gerais deste.
• A codificação, onde é produzido o código-fonte do sistema.
• O teste, onde este código é avaliado para verificar se está adequado.
OSTENSIVO 5-9
Tipos de Sistemas
Computadores são máquinas extremamente limitadas. De fato, só

entendem uma linguagem própria delas, conhecida como código de máquina.
Esse código de máquina é meramente uma sequencia de números que nós
humanos temos grande dificuldade em entender.
As aplicações são escritas em uma linguagem de programação,
que não é uma linguagem natural, mas é simples para entendermos. Exemplos
destas linguagens são: C, C++, Java, PHP, etc.
No momento de passar para a produção, ou seja, para os
computadores entenderem a aplicação, é necessário transformar ou traduzir o
código fonte que está na linguagem de programação no código de máquina, que
o processador irá entender.
Existem diversas formas de fazer isso, sendo as mais comuns a
compilação, a interpretação e o código intermediário.
Este último tipo tem sido cada vez mais utilizado nas linguagens
modernas porém traz alguns problemas de segurança para as aplicações.
OSTENSIVO 5-10
Tipos de Sistemas
Na compilação, após a criação do código fonte, ocorre uma fase de

compilação em que é gerado o código objeto. Após isso, é feita uma etapa de
ligação (link) em que esse código objeto se torna um executável que é um
programa ou aplicação em si. Geralmente os executáveis são arquivos com
terminação .EXE ou .COM.
Esse sempre foi o tipo mais comum de geração de aplicações, pois
o resultado final é o mais otimizado. Porém como cada plataforma de
computadores tem um código de máquina diferente, um programa compilado
para um processador específico não pode ser usado em outros.
OSTENSIVO 5-11
Interpretação
A interpretação consiste em um programa próprio que entende

diretamente a linguagem de programação e a traduz diretamente para o
processador no momento da execução. Este tipo de linguagem é geralmente
bem mais lento, porém de mais fácil manutenção. Um exemplo clássico de
linguagem interpretada é o JavaScript, que são aqueles trechos de código em
páginas Web. O próprio navegador interpreta os comandos e traduz os mesmos
para o processador. Tem a vantagem de ser independente da plataforma. Tendo
o mesmo efeito em Windows, Linux, iPhone, Android, etc.
A linguagem compilada é rápida e pouco flexível. A linguagem

interpretada é flexível mas lenta. Na década de 90 surgiu o Java que foi uma
revolução, dentre outros motivos, porque adotava um sistema misto: o código
intermediário. O Java é compilado apenas parcialmente, gerando um código
intermediário. Esse código já é muito mais próximo do código de máquina, mas
ainda não é o código de máquina. É necessário um outro sistema chamado JVM
(Java Virtual Machine) que irá interpretar o código intermediário e traduzir para o
processador no momento da execução.
OSTENSIVO 5-12
Segurança do executável
O código intermediário é muito mais próximo do código de máquina

do que do código fonte. Dessa forma é muito trabalhoso para um ser humano
entender esse código. Porém, devido a ser um código intermediário, sua
tradução do código fonte não é destrutiva, ou seja, é possível regerar o código
fonte a partir do código intermediário.
Um código fonte compilado gera um executável que, mesmo que o

atacante tenha acesso a este, não poderá entender nem recuperar o código
fonte original.
Um código intermediário pode ser traduzido de volta no código

fonte, que pode até ser alterado e compilado novamente, permitindo um grande
número de ataques se o atacante tem acesso ao código.
OSTENSIVO 5-13
Assinatura de executáveis
Uma forma de minimizar essa possibilidade é a assinatura de

executáveis que também pode ser utilizada para código intermediário. A
assinatura garante a origem e a integridade do código, mas não garante sua
confidencialidade. Ou seja, o eventual atacante consegue acesso ao código fonte
original, mas não tem como alterar a aplicação.
A assinatura de código é uma medida extremamente simples que
impede um grande número de ataques e deve ser usada sempre na geração de
aplicações.
Note porém que a assinatura do código pode ser contornada se a
máquina em que o sistema for executado estiver já comprometida. Isso se deve
ao fato que a assinatura precisa ser verificada por alguém, tarefa essa realizada
pelo próprio sistema operacional.
Note também que esse tipo de fragilidade do executável não ocorre
se o atacante não puder obter esse código executável. É o que acontece, por
exemplo, em sistemas Web, em que o código da aplicação fica no servidor Web,
ao qual o usuário normal não tem acesso.
OSTENSIVO 5-14
Arquitetura de Aplicações
Para entendermos melhor essa questão da fragilidade do código de

aplicações convém definirmos os principais tipos de arquitetura de aplicações.
Toda aplicação conta com três elementos principais:
• A camada de dados, onde estão armazenadas as informações do sistema,

geralmente composto por um banco de dados.
• A camada lógica, camada de aplicação ou camada de negócio, onde
encontram-se as diversas lógicas e condições para o processamento dos dados
mantidos pela aplicação.
• A camada de interface, ou de apresentação, onde as informações são
apresentadas ao usuário ou obtidas deste.
Geralmente o atacante tem pouco interesse na camada de interface.

É muito fácil chegar nela, basta ser um usuário. Existe já uma grande vantagem
em conseguir acesso a camada lógica, principalmente se pudermos alterá-la. Mas
o sonho de todo o atacante é contornar tudo isso e chegar direto na camada de
dados.
OSTENSIVO 5-15
Arquitetura de Sistemas
Toda aplicação conta com três elementos principais:
• A camada de dados, onde estão armazenadas as informações do sistema,

geralmente composto por um banco de dados.
• A camada lógica, camada de aplicação ou camada de negócio, onde
encontram-se as diversas lógicas e condições para o processamento dos
dados mantidos pela aplicação.
• A camada de interface, ou de apresentação, onde as informações são
apresentadas ao usuário ou obtidas deste.
A forma como esses elementos são agrupados é que define a

arquitetura da aplicação.
Uma das primeiras arquiteturas de aplicações foi o Mainframe ou
computador de grande porte. Neste tipo de aplicação, uma máquina muito
grande e cara mantinha tanto a camada de dados quanto a lógica e quase toda a
interface. Na máquina do usuário, apenas uma pequena fração da interface do
sistema, o terminal.
OSTENSIVO 5-16
Arquiteturas de Aplicações
Outro tipo clássico de arquitetura são as aplicações standalone ou

locais. Estas aplicações rodam exclusivamente na máquina do usuário. Todas as
camadas ou elementos estão na máquina do usuário. Exemplo: Word, Excel, etc.
Um tipo muito comum de sistemas, principalmente nos anos 90 e
início deste século, foram os sistemas cliente servidor. Estes sistemas, na maior
parte das vezes desenvolvidos em Delphi e Visual Basic, contém toda a interface
e quase toda a lógica da aplicação no micro do usuário. Apenas o banco de dados
(e, algumas vezes, uma pequena parte da lógica) ficam no servidor.
Esta arquitetura, embora bastante útil por centralizar as informações
de toda a equipe e rápida por não depender de grande poder de processamento
no servidor, contém falhas de segurança graves e devem ser evitadas sempre
que possível.
A falha de segurança desta arquitetura de aplicação consiste na
possibilidade de obter-se as credenciais de acesso ao banco de dados e acessar
o mesmo diretamente, contornando o controle de acesso e eventuais regras de
negócio.
OSTENSIVO 5-17
Arquiteturas multicamadas
As aplicações mais modernas são construídas em 3 ou mais

camadas. Por exemplo, a arquitetura Web é um caso clássico de arquitetura em 3
camadas. A camada de dados é mantida num banco de dados. A camada lógica é
tratada por um servidor de aplicação que também faz a maior parte da camada de
interface, ou seja, o servidor Web. Uma parte da camada de interface é mantida
no micro do usuário, na forma do código HTML e JavaScript.
As aplicações para celular, cada vez mais comuns hoje em dia,
dividem-se em dois grandes grupos:
Aplicações standalone, todas as camadas no celular, na sua maior
parte jogos.
Aplicações n-camadas, pois existe parte da interface e parte da
lógica no celular, que conversa, na maior parte das vezes via um web service,
com um servidor de aplicação que contém a maior parte da camada de lógica e
faz ainda o acesso à camada de dados no servidor.
OSTENSIVO 5-18
Segurança das Aplicações Web
Embora a arquitetura Web seja apenas uma das arquiteturas de

aplicação, ela tem um crescente relevância pois os sistemas mais modernos tem
sido montados nesta interface e é também nela que verificamos uma crescente
preocupação com a segurança.
Nos primeiros dias da Internet, a World Wide Web consistia apenas

de web sites – na forma de repositórios de informação e documentos estáticos. O
fluxo de interesse era de mão única: do servidor para o browser. Hoje a maioria
dos sites são aplicações de fato, e dependem de um fluxo de informações de mão
dupla entre o servidor e o navegador. Isto oferece suporte a processos de registro
e login, transações financeiras, busca e a criação de conteúdo por parte dos seus
usuários.
OSTENSIVO 5-19
O protocolo HTTP é extremamente simples em sua origem. Os
navegadores enviam comandos para um servidor que responde com o conteúdo.
Note que não há, na origem do protocolo, qualquer necessidade de autenticação
ou mesmo de identificação de quem pede informação. A ideia era meramente
fornecer um texto com hiperlinks.
A chamada poderia passar algumas informações, sendo que o

comando GET passa essas informações na própria URL enquanto o comando
POST passa as informações em um segundo conjunto de dados enviado logo
em seguida.
O comando GET é um comando HTTP, portanto roda sobre o protocolo TCP/IP. Assim,
sempre que um comando GET é enviado ao servidor de aplicação, o cliente estabelece o
handshake TCP, ao enviar os dados, envia um conjunto de informações texto conforme o
padrão acima.
A requisição do comando GET contém, na primeira linha, o nome do comando, a página

que está sendo solicitada e a versão do protocolo. A URL da página pode conter alguns
parâmetros. Neste caso, após a URL é colocado o caractere ? e, em seguida dados
podem ser enviados no formato nome1=valor1&nome2=valor2...
A partir daí, são enviados um ou mais pares header:valor, um por linha, indicando
informações adicionais. O protocolo em si não estabelece nenhum header, sendo a
definição destes própria da aplicação que está sendo acessada. Ocorre porém que
alguns headers passaram a ter um entendimento universal entre servidores web.
Note que, sendo estes headers campos livres não obrigatórios, um cliente pode alterar
esses valores livremente sendo estes um dos principais mecanismos de exploração de
aplicações, como veremos mais adiante no curso.
Alguns headers visam detalhar o tipo de arquivo que será servido, por exemplo o
formate e a linguagem esperada para o arquivo a ser recebido.
Outros identificam o navegador de origem da requisição. O exemplo acima mostra a

identificação do Internet Explorer.
Existem outros headers para controle de caches e otimização da mensagem e,

finalmente, os cookies.
O servidor web, após processar a informação no código Java ou C#, ainda dentro do
handshake, responde ao computador cliente um outro trecho de texto no formato
acima.
A primeira linha indica a versão do protocolo, um código de status, seguindo o padrão

HTTP e uma mensagem que nada mais é que a descrição do código em inglês.
Em seguida o servidor manda outros pares header: valor passando parâmetros

específicos da aplicação do servidor para o navegador no micro do usuário. Uma linha
em branco indica o final do header HTTP.
Ao final, a resposta contém também a página web em si ou seja a página que deve ser
apresentada ao usuário pelo navegador. Esta página é descrita na forma de um código
HTML.
Da mesma forma que os headers do navegador, também o header HTTP do servidor
mostra informações sobre o servidor que está respondendo a esta requisição. Informa o
tipo e linguagem da página que está sendo servida.
Finalmente o servidor define ou altera cookies e também fornece algumas informações

para cache e o tamanho do texto que se segue.
O comando POST é muito similar ao GET, apenas com o acréscimo de um conjunto de
valores já na requisição. Assim, o comando POST também inicia com uma linha inicial
que indica o comando em si, a página alvo e a versão do protocolo.
As linhas seguintes possuem pares header: valor de forma similar ao GET. O POST
tipicamente tem um header chamado content-length (tamanho do conteúdo) que indica
o tamanho em bytes dos dados que se seguem ao final da mensagem. Uma linha em
branco após os headers indica o fim do header HTTP e o início dos dados enviados.
Os dados podem ser enviados de diversos formatos, sendo o mais comum uma lista do
tipo nome1=valor1&nome2=valor2&nome3=valor3 ...
Note que, neste caso não há o caractere ? mo início pois não há necessidade de separar
a URL dos dados passados para esta.
Um header particularmente importante é o chamado Cookies. Esse header específico
funciona como um pequeno banco de dados no navegador do cliente. Note que a
aplicação mantém todos os dados desta no servidor do banco de dados, que fica dentro
do data center e, portanto, inacessível a principio para exploração.
O banco de dados dos cookies, por outro lado, fica armazenado na máquina cliente e
pode ser manipulado a vontade. Este banco de dados foi desenhado para manter
apenas um pequeno número de informações.
O banco de dados de cookies é organizado por URL, assim cada aplicação web tem seu
conjunto de cookies independentes (a princípio).
Embora o banco de dados fique no cliente, o mesmo é gerido pelo servidor de aplicação
da seguinte forma: sempre que o navegador vai fazer uma requisição a um servidor, ele
verifica se existe algum cookie daquela URL e já manda na requisição. O servidor web
pode, na resposta, pedir para incluir ou alterar cookies. Nas requisições seguintes os
cookies serão novamente enviados para o servidor web.
Para ver o banco de dados de cookies (windows xp ou 7):
C:\Users\<nome do usuário>\AppData\Roaming\Microsoft\Windows\Cookies
Uma breve pesquisa no google informa o diretório para outros navegadores ou outros
sistemas operacionais.
Ao ser retornado do navegador para o servidor web o cookie é sempre uma lista do tipo
nome1=valor1; nome2=valor2; nome3=valor3; ...
Mas ao ser definido pelo servidor web para a armazenagem no navegador, o cookie tem
uma definição mais complexa.
Primeiro tem o próprio par nome=valor que será retornado. Depois tem a definição do
domínio, ou seja, o servidor para o qual aquele cookie será retornado. O cookie pode ter
ainda uma data de expiração. Após este prazo, não será mais retornado.
Existem dois atributos importantes para segurança: HttpOnly indica que esse cookie só
deve ser retornado no header, mas não deve ser acessível ao código JavaScript da
página. Como veremos adiante, a principio, um código JavaScript pode ler e até alterar
um cookie, mas não um cookie marcado como HttpOnly.
O flag Secure indica que tal cookie só deve ser retornado ao servidor web se a conexão
for segura. Assim, se for feita uma conexão Http simples com o servidor, o navegador
não passará tal cookie.
Cookies podem ser usados para muitas coisas, sendo a principal utilidade o
estabelecimento de uma sessão web. Note que o protocolo HTTP não fornece um
mecanismo nativo de sessão, porém as aplicações web podem implementar tal
mecanismo, sendo a maneira mais usual através de um cookie que identifica a sessão
corrente do usuário.
O cookie pode ser usado para opções de personalização da página, tais como
informações sobre preferências do usuário. Eventualmente um cookie pode ser usado
até para armazenar informações da aplicação.
Finalmente o cookie também pode ser usado para registrar os acessos do usuário e
manter uma lista de páginas que o usuário visitou, por exemplo. Este uso foi inibido
entre sites, mas alguns sites que gerenciam propagandas costumam manter ainda tal
mecanismo com o apoio dos sites que apresentam as propagandas.
O protoclo HTTP (Hyper Text Transfer Protocol) não possui capacidades
nativas para proteger os dados de sua comunicação. Por seus dados circularem
pela WEB em claro, seria impraticável algumas das aplicações WEB mais
comuns nos dias atuais (Internet banking , por exemplo)
Para resolver este problema foi criado, pela Netscape, o protocolo Secure
Sockets Layer (SSL), o qual implementa uma camada de criptografia aos sites
WEB, permitindo garantir a confidencialidade fim-a-fim em uma comunicação.
O SSL se tornou o padrão de facto da criptografia Internet, pois permite

a defesa contra escuta eletrônica e pode oferecer garantias quanto a identidades.
Contudo, não previne ataques que visem diretamente o servidor ou o cliente. Ele
pode ajudar a garantir também a confidencialidade dos ataques, uma vez que um
site com SSL sendo atacado não poderá ser monitorado por um IDS de rede.
O primeiro protocolo SSL, criado na década de 90, utilizava o
algoritmo Diffie-Hellman para troca de chaves. Esse algoritmo não é um
algoritmo de criptografia assimétrica como alguns autores fazem crer. Trata-se
meramente de um protocolo para negociação de chaves. Embora seja um
mecanismo engenhoso que não requer a transmissão da chave de sessão, era
suscetível ao man-in-the-middle, pois um servidor no meio do caminho poderia
se fazer passar pelo servidor para o cliente e se fazer passar pelo cliente para o
servidor e assim estabelecer um túnel entre o cliente e o atacante e outro entre o
atacante e o servidor, interceptando todas as informações.
Note que o esquema mostrado acima é apenas uma

esquematização do protocolo, que é muito mais complexo e envolve várias
trocas de mensagens e verificação de erros antes de ser estabelecida a chave
de sessão.
A correção para este problema veio junto com o mecanismo para
evitar os sites “fake”, ou seja, o certificado digital do servidor. Neste protocolo a
chave de sessão é enviada criptografa pela chave pública de forma que só o
servidor pode ler esta chave e iniciar o túnel. Se houver o man-in-the-middle
neste caso o certificado dele vai ser inválido porque assume-se que o atacante
não tem um certificado digital válido para o site do servidor.
Embora esta proteção seja muito boa, ainda é suscetível a man-in-

the-middle, se o atacante possuir uma CA com raiz confiável para o navegador
do usuário. Esse atacante poderia gerar um certificado válido dizendo que ele é
o servidor. O resto é similar. Finge ser o servidor para o cliente e finge ser o
cliente para o servidor, interceptando a comunicação.
Importante notar também que a URL e todas a linha do comando

GET não são criptografadas! Por esse motivo, deve-se evitar o envio de dados
sensíveis neste comando, priorizando-se o POST. Veja ainda que as evoluções
a partir da versão 2 se concentraram em aspectos menores, não havendo
significativa mudança no protocolo.
Da mesma forma que no caso anterior, note que o esquema

mostrado acima é apenas uma esquematização do protocolo, que é muito mais
complexo e envolve várias trocas de mensagens e verificação de erros antes de
ser estabelecida a chave de sessão.
Principais ameaças
A OWASP (Open Web Application Security Project) é um projeto

que define diversas boas práticas para segurança nas aplicações web e publica
ferramentas para auxiliar na auditoria de segurança de web sites. Ela define
como as 10 principais ameaças contra aplicações web:
A1 – Injection;
A2 – Broken Authentication and Session Management;
A3 – Cross-Site Scripting (XSS);
A4 – Insecure Direct Object Rferences;
A5 – Security Misconfiguration;
A6 – Sensitive Data Exposure;
A7 - Missing Function Level Access Control
A8 – Cross-Site Request Forgey (CSRF)
A9 – Using Components with Known Vulnerabilities;e
A-10 – Unvalidated Redirects and Forwards.
Para maiores informações sobre a OWASP: https://www.owasp.org
OSTENSIVO 5-34
A1.Injection = Injeção
Injeção de comandos é um ataque muito comum em várias

situações. Um exemplo deste tipo de ataque é o SQL Injection, ou Injeção de
SQL, em que um parametro fornecido pelo usuário é utilizado para dar uma ação
não esperada em uma query SQL.
Mas comandos de Injection não requerem SQL nem ambiente

Web. Existem casos de injeção até em sistemas Mainframe. A injeção ocorrem
sempre que um parâmetro fornecido pelo usuário é utilizado por um sistema para
montar um comando que será passado para outro sistema. O SQL Injection em
sistemas Web, por exemplo, ocorre quando o código do aplicativo, no servidor
Web, monta um comando SQL para ser passado para o banco de dados. As
queries SQL nada mais são que comandos processados pelo banco de dados.
OSTENSIVO 5-35
SQL Injection
Vamos ver em maiores detalhes agora alguns dos principais ataques de

internet. Já falamos um pouco sobre os ataques de injeção, onde uma aplicação
monta comandos para outra aplicação a partir de dados fornecidos pelo usuário. O
SQL Injection (ou Injeção de SQL) é um caso particular muito comum deste tipo de
ataque. O SQL Injection foi um ataque muito comum principalmente no início da
Web Dinâmica entre o final dos anos 90 e o início dos anos 2000. Nesta época era
muito fácil encontrar sistemas frágeis a este ataque. Hoje, justamente devido a
inúmeros ataques, os desenvolvedores tomam mais cuidados com esse tipo de
ataque. Também existem um maior número de controles nas plataformas.
O SQL Injection também ficou muito associado ao uso do ‘ (plic) e a
linguagem ASP. Importante saber que existem diversos ataques que não precisam de
plic e que praticamente todas as linguagens são suscetíveis ao ataque, se os
comandos SQL forem montados por concatenação de strings. Esse ataque foi muito
comum no ASP apenas porque foi uma das primeiras linguagens de Web dinâmica e
vários sistemas criados nela não tiveram a preocupação com segurança. Mas é
interessante entendermos exatamente como funciona esse ataque. Vamos pegar um
exemplo (em ASP, a propósito...). Por exemplo, uma tela de login de uma aplicação,
com um campo para o login e a senha é apresentada com o código HTML
correspondente. O usuário digita o login e a senha e clica em “login”. O comando
então é transferido para outro código...
OSTENSIVO 5-36
SQL Injection (2)
O código que trata a tela de login geralmente vai pegar o que o usuário
digitou como login e como senha e precisa verificar no banco de dados se existe um
usuário com aquele login e cuja senha seja aquela. Geralmente a aplicação terá uma
tabela no banco de dados, que pode ser chamar, por exemplo “User”. Essa tabela terá
uma coluna “Login” e outra coluna “Pass”. Nesta situação, uma forma de fazer isso é
montar uma query na forma:
SELECT * FROM User WHERE Login =‘Fulano’ AND Pass=‘123’
O que é exatamente o que faz o código acima. Busca todos os registros

(SELECT *) da tabela “User” onde (WHERE) Login seja o que foi digitado no campo
login e (AND) Pass seja o que foi digitado no campo senha. Em tese o código funciona
bem. Se houver aquele usuário com aquela senha, retorna apenas um registro, o
daquele usuário. Se o login ou a senha estiverem errados, não retorna nada e o
sistema dá acesso negado. Mas o que ocorre se o usuário digita no login ‘ or 1=1 -- ?
Bem... -- é o símbolo de comentário em SQL. A query ficaria:
SELECT * FROM User WHERE Login=‘’ OR 1=1 --‘ AND Pass=‘123’
Como tudo após o -- pode ser ignorado, a query irá retornar todos os
registros da tabela, pois 1 é sempre igual a 1. Mesmo que o Login sempre seja
diferente de ‘’, como é um OU, sempre vai retornar verdadeiro.
OSTENSIVO 5-37
SQL Injection – sem ‘ (plic)
Um exemplo de SQL Injection que não requer ‘ (plic), por exemplo,

ocorre quando o parâmetro a ser concatenado na string para a montagem da
query não é uma string mas sim um inteiro. Neste caso, o comando SQL não
requer o uso de ‘ (plic). Pode causar estranheza que uma variável do tipo inteiro
possa conter algo como “3298 or 1=1”, mas muitas variáveis em linguagens de
internet não tem tipo forte, isso quer dizer que, se atribuir algo que não seja uma
string, não irá gerar um erro, mas sim mudar o tipo da variável para string.
Esse exemplo mostra ainda que variáveis na URL da aplicação

também podem ser usadas para gerar ataques de SQL Injection. De fato, vários
ataques de Injeção podem ser feitos desta forma. Qualquer informação que possa
ser alterada pelo usuário pode ser usada para um SQL Injection, se a aplicação
não estiver preparada para tal.
OSTENSIVO 5-38
SQL Injection – Como evitar?
Durante o desenvolvimento da aplicação, a forma de evitar o SQL

Injection é o cuidado na hora de montar as queries SQL. Recomenda-se o uso de
parâmetros. O exemplo de código acima, em C#, exemplifica exatamente o mesmo
código do exemplo da falha mostrado antes. Note que, ao invés de concatenar
strings, o código monta a query e depois declara cada um dos parâmetros dizendo
o tipo de parâmetro (VarChar é o termo usado no SQL para string) e o tamanho
máximo do parâmetro.
Depois desta definição, os valores podem ser atribuídos sem

qualquer problema. Mesmo o “Betinho Tables” seria registrado da forma adequada
porque o banco de dados irá fazer a consideração adequada dos parâmetros.
Alguns sistemas também evitam SQL Injection impedindo caracteres

como ‘ (plic). De fato, a maior parte dos ataques SQL Injection requer esse
caractere e um sistema que simplesmente proíba esse caractere será bastante
resistente a este tipo de ataque. Mas existem alguns poucos que conseguem
contornar essa limitação. Também deve-se considerar que alguns nomes próprios
possuem o ‘ (plic), como Sant’ana, D’ávila, etc.
OSTENSIVO 5-39
SQL Injection – Hibernate
Em sistemas mais modernos, é comum o uso de uma biblioteca de

componentes especial chamada de camada de persistência. Esse tipo de biblioteca
contém todo o código necessário para “guardar” os objetos e informações da aplicação
no banco de dados. Assim, a aplicação não precisa tratar diretamente com o banco de
dados, poupando o desenvolvedor de uma montanha de trabalho. Existem várias
bibliotecas deste tipo, sendo a Hibernate, para Java, a mais comum.
Muitos desenvolvedores se preocupam com a possibilidade de SQL

Injection nestas camadas de persistência. Porém, de fato, como todas utilizam
parâmetros em suas queries internas, são imunes a esse tipo de ataque.
Essa garantia porém não deve ser levada a 100% porque o fato de
utilizar hibernate para persistência não impede que o desenvolvedor acesse
diretamente o banco de dados por algum outro caminho. Muito comum o desenvolvedor
afirmar categoricamente: minha aplicação não sofre de SQL Injection porque usei
Hibernate. Mas quando vamos testar a aplicação, descobrimos que tem uma telinha lá
dentro do programa que, para agilizar, o desenvolvedor fez uma query direta ao banco e
ali pode ter SQL Injection.
O próprio Hibernate disponibiliza uma função, session find, que permite o

acesso direto ao banco e praticamente pede para que seja usada concatenação de
strings.
Payment payment = (Payment) session.find("from com.example.Payment as payment

where payment.id = " + paymentIds.get(i));
O uso dessa função deve ser evitado e, se necessário, deve-se validar os

OSTENSIVO dados de entrada. 5-40
Garantia contra SQL Injection
Além das boas práticas de codificação apresentadas para o

desenvolvimento de aplicações, ao longo do processo de desenvolvimento
também é bastante útil proceder inspeção de código automatizado, pois a maior
parte das ferramentas é capaz de detectar construções de código suscetíveis a
SQL Injection.
Após a conclusão do desenvolvimento é fundamental que o sistema

seja testado contra SQL por ferramentas automatizadas. Veja que todos os
campos devem ser avaliados sendo contraproducente o teste manual. As
ferramentas apropriadas, tais como NetInspect, Acunetix e Metasploit varrem todos
os campos da aplicação tentando proceder uma injeção em cada um deles.
Finalmente, já com o sistema pronto, em ambiente de produção,

podem ser usados sistemas IPS ou Firewall de Aplicações, com o ModSecurity,
Fortify, e outros para evitar ataques deste tipo. Porém deve-se ter em mente que
esses tipos de sistema não são 100% efetivos. A melhor solução é trabalhar o
problema desde o desenvolvimento do sistema e incluir ainda esses sistemas de
proteção para garantir alguma entrada de dados que tenha escapado ao
tratamento correto. A resposta do dilema do defensor exige redundância.
OSTENSIVO 5-41
LDAP Injevtion
O LDAP é uma sigla em inglês para Protocolo Leve de Acesso a

Diretório (Ligthweith Directory Access Protocol). Um diretório é basicamente um
banco de dados, com uma diferença importante: os bancos de dados são
otimizados tanto para escrita quanto para leitura, enquanto o diretório é otimizado
para leitura. Ou seja, leva mais tempo para escrever um dado em um diretório do
que para escrever o mesmo dado no banco de dados, mas, em comparação, a
leitura do dado no diretório é muito mais rápida que num banco de dados normal.
Ocorre que algumas informações são lidas muitas vezes, mas só são alteradas
muito de vez em quando. Então um diretório é muito mais eficiente nestes casos.
Um caso típico de informações que são escritas e alteradas poucas

vezes, mas lidas muitas vezes é, por exemplo, uma lista de usuários. Um usuário
vai ter sempre o mesmo login, o mesmo nome, vai mudar de endereço e telefone
muito de vez em quando. Mas sempre que um usuário precisa falar com outro vai
entrar em contato com esse. Um usuário troca sua senha muito de vez em quando,
mas se loga todo dia no sistema, então todo dia a aplicação tem que acessar essa
informação. O falto de armazenar dados do usuário, torna o diretório um alvo
preferencial de um ataque. Ocorre que o protocolo LDAP é similar com o SQL. É
uma linguagem em que são passados comandos para o servidor LDAP. Embora
seja totalmente diversa do SQL, a ideia é a mesma.
OSTENSIVO 5-42
LDAP Injection (2)
Seguindo o mesmo exemplo que utilizamos no SQL Injection, repare

que o fato do comando LDAP ser montado a partir da concatenação de strings e
variáveis pode levar a um ataque.
Tal como nosso exemplo inicial, o comando irá buscar um usuário no

diretório LDAP com tal login e tal senha. Porém, se for usado um nome de usuário
inválido, como o mostrado na segunda caixa, retornará o usuário indicado, porém
sem verificar a senha, posto que o texto (&) indica uma condição sempre
verdadeira (tal como o 1=1 no caso do SQL Injection). O segundo fecha parêntesis
fecha a expressão que começa com um abre parêntesis. Tudo que vier depois de
fechar o comando, é considerado comentário.
Repare que, no caso de injeção LDAP não há necessidade de se

preocupar com o ‘ (plic) mas sim com o ( (abre parêntesis) e o ) (fecha parêntesis).
Note que, no caso do LDAP Injection não há um mecanismo

padronizado, tal como os parâmetros na query SQL. Neste caso, temos que
sanitizar e garantir que a entrada de dados está correta.
OSTENSIVO 5-43
Script Injection
O script injection é outra forma muito comum de injeção. Este

caso ocorre quando uma informação fornecida por um usuário é utilizada
para montar a página HTML do outro usuário. No exemplo acima, um usuário
foi solicitado a entrar um dado, o seu nome. Normalmente ele forneceria o
nome “fulano” esse nome seria armazenado no banco de dados. Quando um
outro usuário solicitar a lista de usuários do sistema, a aplicação vai
consultar o banco de dados e montar a página HTML. Essa página será
montada seguindo o código HTML, em que o texto a ser apresentado é o
texto comum e alguns comandos são inlusos na forma de TAGs, entre <
(menor) e > (maior). Por exemplo, o TAG <br/> é para pular linha, <b> é para
colocar em negrito, etc.
Um dos TAGs especiais são os <script> que indicam a execução
de um código JavaScript. Esse código pode ser usado para uma série de
ações e são executados no computador do usuário pelo navegador desse.
No exemplo de ataque, ao invés de escrever apenas o seu
nome, o atacante digitou
fulano <script> alert(‘olá mundo!’); </script>
Quando for mostrar o nome do fulano, a aplicação irá buscar o

conteúdo no banco de dados e colocará na página HTML, só que o
navegador do usuário vai entender que existe um código script a ser
executado. No caso, o código em questão irá apenas abrir uma janela de
aviso com a informação “olá mundo!”. Esse código, por óbvio, não é danoso.
Mas um atacante pode utilizar diversos comandos que podem gerar um
ataque real à aplicação.
OSTENSIVO 5-44
O ataque de Script Injection é tão comum que alguns servidores Web (particularmente o
ISS 6 e posteriores) passaram a proibir dados de entrada com os sinais < e >. De fato
trata-se de uma medida de segurança efetiva, pois tais caracteres muito raramente
fariam parte da entrada de dados normal.
Ainda assim, deve-se lembrar que é possível fazer Script Injection sem esses caracteres,
quando o campo guardado no banco de dados é retornado na cláusula value de campos
do tipo input. Essa cláusula é usada principalmente em telas de atualização de registro,
pois indica o valor default do campo a ser apresentado para a edição do usuário.
Caso o sistema seja bem defendido por sistemas de IDS, IPS ou Firewalls de Aplicação, o
uso deste tipo de ataque pode ser detectado com alguma facilidade. Como apontamos,
o uso de sinais < e > não é comum em entrada de dados e os sistemas verificam isso
com prioridade.
Porém muitas vezes isso pode ser contornado buscando realizar a injeção via um outro
sistema que gere dados a serem usados no sistema a ser atacado. Se conseguirmos
“plantar” o injection no outro sistema, o ataque acabará ocorrendo no sistema alvo.
A2.Broken Authentication
Autenticação com falha ou problemas no gerenciamento de sessão

decorrem do fato que o servidor Web não tem nativamente um controle de sessão.
O usuário pode se autenticar, fazer o login numa página, mas como o servidor
sabe que uma outra requisição recebida vem do mesmo usuário?
Pelo IP da máquina que veio a requisição?
Pelo nome da máquina que veio a requisição?
Por uma informação armazenada na máquina gerada no momento
que foi feita a autenticação?
Por uma chave de criptografia gerada no momento da autenticação?
O problema é que muitos sistemas não fazem o controle de forma

adequada, permitindo que um atacante gere uma requisição ao servidor como se
fosse o usuário legítimo autenticado. Por exemplo, se o cookie de sessão puder
ser obtido por algum outro meio, outro usuário pode chamar o servidor web se
fazendo passar pelo usuário.
O desenvolvimento de aplicações “sessionless” são perseguidos por
muitos desenvolvedores porque aplicações deste tipo tem uma performance
excelente. Mas uma aplicação “sessionless” confia exclusivamente no cookie de
sessão para autenticação. Isso gera um ponto único de falha.
OSTENSIVO 5-47
Essa seria a visão de um processo de autenticação com o usuário fornecendo
autenticação em cada acesso. Mas note que seria muito trabalhoso para o usuário.
Outra alternativa seria o navegador guardar as credenciais do usuário e mandar essas
em cada requisição, mas isso seria uma falha de segurança pois indicaria o
armazenamento de credenciais.
A solução prática é que a autenticação é feita apenas no primeiro acesso (na tela de
login) e o servidor web manda um token de autenticação para o cliente. Esse token tem
uma validade finita. Essa seria a situação mais comum, sendo o token o próprio session
ID do navegador.
Uma forma mais segura ainda de autenticação é quando o token é trocado a cada
requisição. Isso é implementado por alguns servidores web, mas tem o problema de
diminuir a velocidade de conexão devido a necessidade de acompanhamento da
sequência de tokens. Na prática é pouco usado.
A quebra de autenticação consiste portanto em obter as credenciais do usuário ou o
token de sessão de forma a permitir que se passe pelo usuário face ao sistema.
Obter as credenciais de autenticação do usuário pode ser feita através de diversos tipos
de exploração. A falta de HTTPS por exemplo, permite capturar essas senhas no
momento da transmissão das informações.
Senhas fracas ou sem bloqueio podem ser obtidas por testes de força bruta.
Mecanismos do tipo esqueci minha senha podem ser usados quando temos os dados do
usuário, o que nem sempre é dificil.
Finalmente, alguns mecanismos de autenticação, embora não revelem a senha em si,

permitem ataques de replay, ou seja, não sabemos a senha, mas capturando a
comunicação entre o servidor e o navegador e tocando de novo, somos autenticados
novamente.
A falha na autenticação, porém, nem sempre é causada por
exploração do protocolo HTTP em si, o próprio mecanismo de autenticação da
aplicação pode conter erros que permitem uma exploração muito fácil. Todos as
situações acima eu já encontrei em análises de segurança em aplicações
públicas de grandes empresas. Não foi em aplicação da videolocador da
esquina. Empresas líderes em seu ramo, com atuação nacional, grande parte
das operações via web, com esse tipo de erro.
As vezes esse tipo de problema é difícil de descobrir sem ver o

código, pois a plataforma web oculta as informações. Por exemplo, no caso do
viewstate é difícil divisar o problema apenas olhando para o texto.
Note que em protocolo HTTP puro (sem SSL) é muito simples para qualquer elemento
no meio do caminho inteceptar o ID de sessão. Na verdade existem diversas maneiras
de obter o cookie de sessão desta forma.
Algumas aplicações web tem uma página inicial HTTP e, só se o usuário fizer login, que
passa para HTTPS. Isso muitas vezes gera uma fragilidade que pode ser explorada.
Podemos capturar o ID de sessão enquanto ainda estamos no HTTP e, depois que o
usuário passar para o HTTPS, o ID continua o mesmo. Podemos então quebrar a sessão
do usuário e usar o sistema como se fosse este.
Outra forma de sequestro de sessão é através de uma injeção de script. Um código
JavaScript é injetado fazendo com que o navegador do outro usuário passe o id de
sessão deste para um outro servidor conhecido onde podemos pegar essa informação.
OSTENSIVO 5-57
O Cross Site Scripting é um ataque de script injection, ou seja, de
injeção, que visa roubar a sessão de um outro usuário. O ataque requer que o
atacante possua um outro servidor web para ser usado, daí o nome “cross site”
ou seja, entre sites. O atacante irá digitar uma informação qualquer no sistema
incluindo um código script que pegue o session id e envie para o outro
servidor. Quando o usuário legítimo acessa o sistema e, por algum motivo,
pede para ver a informação mostrada por aquele usuário, o código será
executado na máquina dele. Esse código irá pegar o id de sessão e enviará a
um servidor externo. Esse servidor, claro, é controlado pelo atacante que pode,
então, obter o id de sessão de outro usuário.
De posse deste id de sessão, o atacante pode simular chamadas

ao sistema como se fosse o usuário legítimo. O sistema não tem como
distinguir uma chamada de outra, desde que tenham o mesmo session id.
O XSS ficou muito popular por ser usado em salas de bate papo
(chats) para ler conversas reservadas de outros usuários. Os sistemas atuais
não são mais suscetíveis.
A forma de evitar o XSS é a mesma de evitar outros ataques de
injeção de script: evitar os sinais < (menor) e > (maior).
A captura de ID de sessão em aplicações totalmente HTTPS é muito difícil, pois
geralmente os cookies de sessão tem os atributos HttpOnly (que impede o
acesso via JavaScript) e Secure (que impede o uso fora do HTTPS).
Existem porém ataque teóricos, como, por exemplo, o chamado CRIME.
“The new attack has been given the name CRIME by the researchers.The
CRIME attack is based on a weak spot in a special feature in TLS 1.0, but exactly
which that feature is has not been revealed by the researchers. They will say that
all versions of TLS/SSL including TLS 1.2.”
http://thehackernews.com/2012/09/crime-new-ssltls-attack-for-hijacking.html#
Aplicações podem fazer referência a diversos objetos, por
exemplo, arquivos, WebServices, interfaces, etc. Esses objetos podem estar
em diversos locais: no próprio servidor, em outro servidor de outra aplicação,
na própria máquina do usuário, etc.
Não há problema em si em nenhum destes acessos. O problema

é que o objeto referenciado deve estar preparado para a possibilidade de ser
acessado diretamente, sem ser via aplicação. Um atacante pode chamar
diretamente um WebService, por exemplo, ou pode ler um arquivo
diretamente. Os desenvolvedores geralmente cuidam bem da segurança no
acesso ao próprio sistema no próprio servidor, mas descuidam na avaliação
dos requisitos de segurança quando vão acessar outros objetos.
Um caso clássico são códigos em AJAX em aplicações Web.

Esses códigos são trechos de código JavaScript, que rodam portanto no
navegador do usuário, que acessam diretamente um WebService no próprio
servidor ou em outro servidor qualquer. Se esse WebService não cuidar de
verificar se o usuário que o chamou é válido...
A exploração da referencia insegura pode ser bloqueada por sistemas de IDS ou IPS
apenas se for feita de uma forma óbvia. Caso seja feito de forma aleatória com
ocultação de origem, não há nenhuma forma de detecção do ataque pois as requisições
não se distinguem de requisições legítimas.
Um caso clássico de referencia insegura consiste nas promoções que pedem códigos de
produto ou números na tampinha de refrigerantes. Esses códigos são casos clássicos de
referencia insegura.
Um atacante pode facilmente produzir milhares de códigos válidos simplesmente

explorando a força bruta. Por ser esse um golpe muito comum, de alguns anos para cá
essas promoções passaram a pedir que se guarde a embalagem do produto, numa
tentativa de coibir esse tipo de fraudo.
De qualquer forma, não é uma tarefa particularmente difícil falsificar uma embalagem,
ou pelo menos, é algo muito mais simples que falsificar uma nota ou selo.
Ressalte-se que tal procedimento consiste em crime de fraude e falsidade e o exemplo é

usado aqui apenas para efeitos acadêmicos.
Porque a referencia insegura é um problema? Primeiro que o uso de um identificador
público e óbvio facilita o ataque. As recomendações são que se use GUID ao invés de
números.
Mas esse problema só é resolvido de fato com a autenticação do usuário e o controle de

acesso garantindo que cada usuário só tenha acesso aos dados de direito.
A5. Security misconfiguration
Uma aplicação só pode ser tão segura quanto segura é a plataforma

em que ela executa. Essencial garantir que o web server, o banco de dados, o
servidor de aplicação, o sistema operacional em si, enfim todos os componentes e
sistemas que dão apoio à aplicação estejam seguros.
• Política de aplicação de patches e atualizações de segurança

• Configuração adequada dos parâmetros dos sistemas
• Restrição de acessos indevidos
• Proteção física dos servidores
• Eliminação de quaisquer serviços não necessários
• Etc...
Embora não seja um aspecto da aplicação em si, é importante pois

grande numero de falhas em aplicações são, na verdade, derivados de falhas nas
camadas subjacentes ou camadas de apoio.
OSTENSIVO 5-64
A má configuração de um servidor web é geralmente explorada por mapeamento via
port scanner, teste de vulnerabilidade e outros. Note que, sendo falha na camada do
sistema operacional e de suporte a aplicação, são explorações mais afeitas a
infraestrutura do que a aplicação. Existem algumas situações de falha de configuração,
porém, que caem claramente dentro do escopo de exploração de aplicações.
Uma aplicação tem páginas além daquelas que se espera que
sejam vistas pelo usuário. Por exemplo, algumas vezes os desenvolvedores
deixam versões de backup das páginas, com a extensão .BAK. Ocorre que o
servidor web, quando chamado a baixar um arquivo cuja extensão não
reconhece, faz simplesmente o download do arquivo para a máquina do
usuário. Assim, um arquivo de código com a extensão .BAK, ao invés de ser
interpretado pelo servidor, seria baixado na máquina do usuário mostrando
todo o código do sistema com informações sensíveis.
Além destas, não é incomum o desenvolvedor criar páginas de

teste do sistema, para uso próprio. Essas páginas não estariam entre as
páginas normais do sistema nem teriam qualquer link para elas, sendo
necessário saber a URL para acessar. Porém, muitas vezes, essas páginas
apresentam informações sensíveis. Não só é arriscado algum atacante
descobrir essas páginas para ataque como também não se pode descartar a
possibilidade do desenvolvedor que criou a página sair da organização e
divulgar tal página. O desenvolvedor não se preocupa com isso porque
imagina que o usuário não vai saber o nome da página, mas os programas de
ataque testam todas as páginas com extensões diversas, também páginas
como test.jsp, teste.jsp, admin.asp, etc. O que acaba identificando esses tipos
de problemas.
Até com o uso do google é possível localizar muitas dessas

páginas, utilizando os filtros do google.
O tratamento de arquivos com extensões diferentes pode ser diretamente configurado
no servidor web. Assim, o fato de haverem arquivos com extensões diferentes seria
inócuo. Mas fica claro que é um problema com dois lados: é preciso que o
desenvolvedor da aplicação seja descuidado e deixe arquivos de tipos não esperados no
diretório da aplicação e é preciso que o gestor do servidor web não configure o mesmo
adequadamente.
Havendo duas condições assim tão óbvias chega a ser chocante o grau de sucesso que
consegue-se obter em testes deste tipo.
Existe uma outra exploração que já foi muito comum, mas hoje é vedada por todos os
principais servidores web, chamada contorno de diretórios. Descrevemos o mecanismo
apenas para conhecimento, pois tal ataque é inviável em qualquer servidor com menos
de 10 anos de idade.
A6. Sensive data exposure
Muitas vezes situações inesperadas ou erros fatais levam a aplicação

a mostrar dados sensíveis e informações que não deveriam ser apresentadas. Um
caso clássico deste problema é a aplicação que apresenta o stack trace em
produção. Stack trace significa, literalmente, “rastreamento de pilha” e é uma lista
da sequencia de erros menores que levaram ao erro fatal apresentado ao usuário.
O stack trace é uma tela similar a apresentada no slide. Trata-se de

informações úteis aos desenvolvedores para depurar a aplicação e identificar a
origem de um erro. Porém esse tipo de informação não deve nunca ser mostrado
ao usuário final em produção, posto que fornece informações que podem ser úteis
a um atacante. A melhor solução, nestes casos, é registrar os stack trace em uma
trilha de auditoria e mostrar para o usuário apenas uma informação “erro interno”.
Mas não é só no caso do stack trace padrão. Muitas mensagens de

erro, criadas por desenvolvedores para ajudar na depuração, mostram informações
sensíveis que podem ser usadas por atacantes. Mensagens ao usuário devem
informar o mínimo necessário, nunca objetos ou variáveis internas.
OSTENSIVO 5-69
A apresentação de erros do sistema na página do usuário é também um problema que
precisa de dois erros: do desenvolvedor em não tratar um erro corretamente e da
configuração do servidor, onde pode ser definido um tratador padrão para páginas de
erro.
Neste ataque o hacker observa um parametro que, se manipulado,
levará o servidor a buscar um arquivo em outro servidor e, se do tipo correto,
executá-lo no host. Os passos para este ataque são:
1 – O atacante faz uma requisição especial, mudando um parâmetro

específico (neste caso o parâmetro page), redirecionando este para um
servidor auxiliar do atacante. Neste servidor, há um código especial
armazenado pelo hacker (evil.txt) que é um código PHP que dará um
shell para o atacante, se executado no servidor;
2 – O servidor recebe a requisição e, em face de uma falha de
programação, irá buscar o arquivo no servidor do hacker, pois o mesmo
foi passado como parâmetro na requisição;
3 – Ao receber o arquivo de volta, por este se tratar de um PHP, ele será
executado; e
4 – O atacante obtém um shell no servidor
A injeção de arquivos remotos e, até onde vai o conhecimento do autor, um ataque
específico da linguagem PHP. Mesmo nesta linguagem, em versões posteriores a 4.6, é
altamente improvável que venha a ocorrer, posto que foram inclusas diversas proteções
contra este problema.
Todas as linguagens permitem que seja feito um include, que é um comando do tipo:
“pare de ler este arquivo, leia e processe aquele arquivo todo, depois continue na
próxima instrução”. O que torna o PHP único é que ele permite que o arquivo incluso
seja passado na forma de uma variável fornecida pelo usuário. Todas as demais
linguagens requerem que o arquivo tenha um nome fixo, não alterável durante a
execução do sistema.
Explorar um include file portanto consiste em identificar uma página que chame outra
via um include. Em PHP isso é comum quando temos uma URL que tem conteúdo
completamente diferente, mas a URL continua a mesma. Fora isso, pode-se tentar fazer
o injection da mesma forma que nos demais ataques de injeção. Mas note que esse é
um erro de desenvolvedor, mas também uma falha de configuração, pois as versões
posteriores a 4.6 do PHP permitem uma configuração que impede este ataque.
Também conhecido como hot spot (ponto quente). O desenvolvedor
verifica os direitos de acesso do usuário e só mostra para ele as funções que ele
tem direito. Mas quando clica no menu, o usuário é direcionado para uma outra
página, onde executará a função sensível. O problema é que é muito comum o
desenvolvedor esquecer de verificar na função se o usuário tem direito àquela
função. Geralmente ele pensa: o usuário só chega até aqui se for pelo menu, se
não tem direito, não aparece no menu, então ele não tem como chegar aqui. O
problema é que se o usuário souber a URL completa da página da função, ele
chega direto lá. Mesmo sendo um usuário sem direitos.
Existem três tipos de hot spot:

1. Não verifica nem qual é o usuário que está logado. Mais grave. Mesmo sem
logar pode acessar a função. Não fica nenhum registro de quem usou a
função.
2. Verifica que o usuário está logado, mas não que tenha direito àquela função.
Qualquer usuário pode usar a função sensível.
3. Verifica que o usuário está logado e que tem direito a função, mas não se tem
direito ao registro específico. Muito comum.
O usuário logado, o direito deste à função e o direito deste ao

registro específico apresentado devem ser checados em cada página duas
vezes: na apresentação e no tratamento.
Outro problema muito comum em sistemas é que o programador falhe em proteger
uma página ou um registro. Trata-se de um erro de lógica do sistema, porém, um erro
muito comum, tanto que está entre os 10 principais ataques conforme o OWASP.
Esse ataque tem o nome, dentro da comunidade hacker de Hot Spot, ou ponto quente.
Pode ser o caso daquela página particular sequer verificar se o usuário está logado. Esse
é o pior tipo. Se alguém conhecer a URL, consegue acessar as informações diretamente.
Os outros dois tipos exigem que se tenha um usuário no sistema, porém fazem com que
usuários comuns com poucos direitos passem a ter acesso a informações privilegiadas.
Nesta situação o usuário logado com perfil simples, usando um URL completa, tem
acesso a um página de acesso privilegiado.
O terceiro tipo se confunde um pouco com a referência insegura. Trata-se da falta de

verificação não da página em si, mas do registro apresentado. O usuário logado tem
direito de acessar aquela página, mas não teria o direito de ver aquele registro
específico apresentado.
Note que esse tipo de falha é confundida com uma regra de negócio por IPS, IDS e
Firewalls de aplicação. Desta forma, não há como distinguir entre o acesso legítimo e a
exploração.
Deve-se, porém, evitar o acesso seguido e sequencial com páginas inválidas numa
eventual tentativa de descobrir a página por força bruta. Esse tipo de problema pode
sim ser detectado.
A identificação de hot spots pode ser muito útil caso tenhamos um usuário legítimo ou o
log de navegação de um usuário legítimo. Nesta situação conseguimos conhecer todas
as páginas do sistema e, desta forma, podemos testar se alguma delas possui tal falha
de acesso.
Pode-se obter a lista de URLs de um usuário legítimo também por um sniffer da rede ou,
em último caso, por tentativa e erro. Muitos sites usam padrões de nome de página o
que facilita esse teste.
No caso de Hot Spot nível 2 precisamos fatalmente de um usuário legítimo no sistema,
mesmo que seja um usuário com poucos poderes. Muitos sistemas tem um perfil
público e um perfil de administrador, por exemplo, assim a ideia é identificar
possibilidade do usuário comum acessar as informações do administrador.
Precisamos novamente ter as URLs que podem ser obtidas de um usuário legítimo pelos
mesmos meios que no hot spot 1, ou podem ser buscadas por tentativa e erro.
O terceiro nível de hot spot é quando conseguimos acessar
registros aos quais não teriamos acesso. Esse tipo de ataque é em tudo
similar ao ataque sobre referencia insegura a objeto. A única diferença aqui é
que, enquanto na referencia insegura o usuário não está necessariamente
logado no sistema, aqui o usuário já tem um perfil definido no sistema.
Aplicações podem fazer referência diversos objetos, por
exemplo, arquivos, WebServices, interfaces, etc. Esses objetos podem estar
em diversos locais: no próprio servidor, em outro servidor de outra aplicação,
na própria máquina do usuário, etc.
Não há problema em si em nenhum destes acessos. O problema

é que o objeto referenciado deve estar preparado para a possibilidade de ser
acessado diretamente, sem ser via aplicação. Um atacante pode chamar
diretamente um WebService, por exemplo, ou pode ler um arquivo
diretamente. Os desenvolvedores geralmente cuidam bem da segurança no
acesso ao próprio sistema no próprio servidor, mas descuidam na avaliação
dos requisitos de segurança quando vão acessar outros objetos.
Um caso clássico são códigos em AJAX em aplicações Web.

Esses códigos são trechos de código JavaScript, que rodam portanto no
navegador do usuário, que acessam diretamente um WebService no próprio
servidor ou em outro servidor qualquer. Se esse WebService não cuidar de
verificar se o usuário que o chamou é válido...
Trata-se de um caso particular de ataque de injeção. O atacante
consegue incluir um código de injeção de JavaScript em uma tabela do banco de
dados. Quando o usuário vai acessar aquele registro específico é vítima de
injeção de código JavaScript no código HTML da página ou o código é enviado
via email ou outro mecanismo.
O código contém um formulário que irá disparar informações para o

sistema alvo. O usuário está logado no sistema alvo e clica em um link (pode ter
sido mandado via email) e o código irá aproveitar a sessão aberta para fazer a
ação em nome do usuário.
82
Existem vários exemplos de CSRF, sendo os mais conhecidos uma falha que havia no
facebook e o problema com roteadores. O exemplo do google indicado acima é
hipotético, mas seria o caso em qualquer sistema em que um usuário podem mandar
mensagens para outros.
O CSRF é muito danoso porque contorna todos os mecanismos de proteção do Cookie.
Mesmo que o servidor esteja adequadamente configurado, com os cookies de sessão do
tipo HttpOnly e Secure, pode ser usado. Em tese o usuário não deveria clicar em links de
outros sites enquanto navega em sistemas críticos, mas usuários fazem isso o tempo
todo.
A9. Vulnerable components
Componentes são pequenos pedaços de código tão comuns que são

isolados para permitir o uso em várias aplicações. Uma biblioteca é um conjunto de
componentes publicado por um fabricante de software. Por exemplo, existem
componentes para validar CPF e CNPJ, componentes para preencher endereços,
componentes para efetuar cálculos matemáticos específicos. Componentes e
bibliotecas são muito úteis no desenvolvimento de aplicações porque permitem que
o desenvolvedor use a funcionalidade sem precisar escrever de novo um código
comum.
Usar componentes e bibliotecas faz parte do desenvolvimento. O
problema é quando se usa um componente ou biblioteca que contém uma falha de
segurança. Por exemplo, um componente que valida CPF, mas que deixa
determinado tipo de CPF inválido passar (11111111111, p. ex., é válido segundo a
regra do dígito de validação, mas não é válido segundo as regras da receita
federal). Esse componente pode abrir uma brecha na segurança da aplicação.
Existem casos de componentes desenvolvidos com falhas intencionais para permitir
ataques posteriores em aplicações desenvolvidas com eles.
Fundamental usar só componentes reconhecidos no mercado e que
passem por uma validação prévia. Em sistemas críticos de segurança recomendo
usar apenas componentes open source, pois o código do mesmo pode ser avaliado
para verificar se não há uma falha qualquer intencional nestes.
OSTENSIVO 5-85
A exploração de componentes inseguros é difícil, a menos que você seja o fornecedor
do componente. Pode-se buscar as listas de hackers da internet pela informação de
componentes com fragilidades conhecidas.
Uma outra estratégia seria criar um componente bacana, mas com um backdoor, e
distribuir gratuitamente. Existem vários casos deste tipo de exploração.
A10. Unvalidated forwards
Redirecionamento (redirect) ou encaminhamento (forward) são

operações muito comuns em páginas web. Ocorrem quando uma página web
chama outra. O usuário chama a página site1.com.br e este site direciona para
outra página, por exemplo, site1.com.br/principal.jsp. Não há problema de
segurança nisso. O problema ocorre quando a linha de redirect pode ser alterada
pelo usuário, por exemplo, quando é montada com base em alguma informação
que foi passada pelo usuário.
Um caso comum disso é o redirecionamento por língua. Em sites de

bancos, foi comum uma determinada época, que a página inicial verificasse qual a
língua configurada no navegador do usuário e direcionasse o mesmo para a
página em inglês ou em português do banco, por exemplo. A questão é uma
página chamava a outra passando, como parâmetro, a linguagem padrão do
navegador do usuário.
Ocorre que esse parâmetro é definido no navegador do usuário e

pode ser alterado por esse. Alterando esse parâmetro para um formato específico,
um eventual atacante pode acabar direcionando o usuário para outro site que não
o esperado.
OSTENSIVO 5-87
HTTP response Splitting
O ataque de divisão da resposta, response splitting , é um ataque

de DNS poisoning, ou seja, de envenenamento do servidor de nomes de
domínio, do DNS. Trata-se de um ataque que se aproveita do fato de haver, na
aplicação, uma redireção de página que usa, para a montagem da nova URL,
uma informação que foi passada pelo usuário.
O caso acima, um redirecionamento pega a informação do usuário

“Lang” para montar a URL menu.jsp?lang=English. A requisição HTTP que é
retornada para o navegador do usuário tem a forma indicada na parte de baixo.
Note que a palavra “English” está no cabeçalho HTTP, ou seja, antes da TAG
<html>. Um atacante poderia substituir este texto por um texto de ataque,
comprometendo o cabeçalho HTTP.
OSTENSIVO 5-88
HTTP Response Splitting (2)
Por exemplo, nesse caso foi incluso um texto grande no lugar da

palavra “English”. Note que o texto de ataque é todo o texto em vermelho indicado
abaixo. Para incluir caracteres para nova linha (enter) usa-se o %0d %0a.
Note que o navegador vai acabar recebendo uma requisição com o

cabeçalho dobrado. Duas vezes HTTP/1.1. Ocorre que, nesta situação, o
navegador vai ignorar o primeiro e executar o segundo cabeçalho. O segundo
cabeçalho é justamente o que foi inserido pelo atacante e pode, por exemplo,
direcionar o usuário para um site falso, mostrar informações indevidas, etc.
Note que, para prevenir esse tipo de ataque, é imprescindivel tratar

qualquer variável recebida do usuário que será usada em montagem de
redirecionamento retirando caracteres de enter, ou seja, %0d e %0a.
OSTENSIVO 5-89
Redefinindo o perímetro de segurança
Acima, é apresentado o desenho de uma rede com a idéia de uma

aplicação recebendo conexões nas portas 80 e 443, e depois acessando
segmentos de rede mais internos e críticos.
Nesse caso, o Firewall permite apenas a saída dos hosts internos

e a entrada para o servidor WEB, nas portas 80 e 443. Contudo, para a
aplicação que está hospedada no Web Server funcionar, é necessário permitir a
este servidor o acesso ao Database Server, na rede interna.
Mesmo neste cenário será possivel, para um usuário externo, ter

acesso ao banco de dados na rede interna explorando uma eventual falha na
aplicação hospedada no servidor WEB.
Com este cenário, uma aplicação WEB com vulnerabilidades pode

alterar todo um perímetro pois, independente de quantos firewalls ou até mesmo
IDS/IPS a rede possuir, um atacante externo poderá obter acesso aos dados nas
camadas mais profundas da rede.
Os ataques à aplicações vulneráveis são hoje os mais eficientes,

logo após os ataques de engenharia social.
OSTENSIVO 5-90
Ataques mais comuns
Vamos ver a seguir, em detalhes, os ataques mais comuns e as

medidas de proteção contra esses mais recomendadas. Evidente que existem
uma infinidade de ataques e surgem novos ataques todos os dias. Assim essa
lista não é fechada. Mas é bastante representativa. De fato, uma aplicação que
seja imune aos ataques aqui apresentados está acima da média de segurança
do mercado.
OSTENSIVO 5-91
Ameaça = cenário Hipotético
Antes de procedermos a apresentação dos ataques propriamente

ditos, vamos ressaltar alguns conceitos referentes ao que é um ataque em
aplicação. Note que a definição de ameaça pode variar conforme a situação,
porém, quando se fala de ameaça a uma aplicação temos que lembrar sempre
que é um cenário hipotético onde um agente utiliza um mecanismo para obter um
ativo de valor.
Se não houver nenhum agente interessado, não há ameaça.

Identifique quem são os agentes que podem ter interesse em atingir a aplicação.
Não se esqueça de agentes internos, funcionários, usuários, desenvolvedores.
Se não houver um ativo de valor, não haverá ninguém interessado

e, mesmo se alguém invadir a aplicação, não haverá o que lamentar. Preocupe-se
com aplicações que tem ativos de alto valor.
No mecanismo de ataque é onde a defesa da aplicação deve

trabalhar. Identificado o agente potencial e o ativo de valor, deve se buscar
eliminar qualquer fraqueza ou falta de um controle que permita que o agente
obtenha o ativo de valor.
OSTENSIVO 5-92
Ameaça OWASP
O site OWASP indica a mesma informação com alguns detalhes

adicionais. O mecanismo, por exemplo, considera o ataque que sempre recairá
sobre uma fraqueza do sistema que não tenha um controle adequado. De fato,
identificar as fraquezas, se possível eliminá-las, se não, ao menos mitigar seus
efeitos com controles é a forma que temos para evitar as ameaças ao sistema.
Note que cada agente potencial pode utilizar todos os ataques

disponíveis. Esses ataques podem recair sobre os mais diversos pontos fracos da
aplicação.
A dificuldade de defender uma aplicação é um caso clássico do

dilema do defensor. O defensor tem que defender todo o perímetro contra todos os
ataques possíveis. O atacante só precisa achar uma brecha. É uma tarefa muito
mais difícil defender uma aplicação do que atacar uma.
Tenha em mente portanto que, nas próximas telas, estamos vendo

apenas os ataques mas para avaliar o quão grave é um ataque para uma
aplicação em particular, é preciso ver os demais elementos: Agentes potenciais,
Ativo de valor, Controles de segurança, Fraqueza da aplicação ao ataque indicado,
etc.
OSTENSIVO 5-93
Repare que as variáveis são reservadas na memória na sequencia em que são criadas.
Assim, geralmente, o overflow de uma variável pode afetar as demais variáveis após a
sua declaração.
94
Buffer Overflow
Vamos ver os ataques mais comuns em aplicações iniciando pelo

ataque mais antigo: o Buffer Overflow (também conhecido como Buffer Overrun).
O termo overflow significa transbordamento. O termo buffer, no sentido utilizada
aqui, não tem uma tradução adequada em português. Literamente significa
“amortecedor” ou “área de amortecimento”. Quando uma aplicação reserva uma
área de memória do processador para guardar uma informação, por exemplo, um
texto, ela sempre reserva uma área um pouco maior que o texto em si, como que
uma “área de amortecimento” ou uma “área reserva” caso o texto cresça em
tamanho. Assim, buffer overflow poderia ser traduzido como “transbordamento da
área de reserva do armazenamento de uma informação na memória do
processador”.
Na prática ocorre quando a aplicação tenta guardar um texto ou outra

informação qualquer que é maior que a área reservada para essa informação.
Como parece óbvio, a maior parte das linguagens de programação gera um erro
nessa situação. É como se tentássemos salvar um arquivo de 2 Gb num disco que
só tem 1 Gb livre. Assim, Java, C# e outras linguagens mais modernas não são
suscetíveis a este tipo de ataque.
Porém algumas linguagens mais antigas, particularmente C e C++,

simplesmente não verificam o tamanho antes de escrever. Seria como, no caso
acima, que o arquivo fosse escrito de qualquer jeito, sobrescrevendo outros
arquivos que, por acaso, estejam no caminho deste. O motivo destas linguagens
não fazerem essa verificação é a agilidade.
OSTENSIVO 5-95
Buffer Overflow (2)
Sendo um ataque tão antigo e com a solução conhecida chega a ser

paradoxal que ainda existam tantas falhas deste tipo nos dias de hoje. Existem
algumas explicações porém:
Realmente a verificação de tamanho da memória é uma atividade

que consome tempo e, portanto, em aplicações de tempo real ou aquelas em que
a performance é algo prioritário, não é incomum recorrer-se a C ou C++ para
ganhar desempenho.
Muito código de base dos sistemas operacionais, bancos de dados e

outros foi escrito em C ou C++, tanto pela performance quanto pelo fato de sua
parte central ter sido desenvolvida a um par de décadas atrás, na época em que C
e C++ eram as melhores linguagens conhecidas.
Aplicações desenvolvidas em C++: Bancos de Dados Oracle e SQL

Server, Sistemas operacionais Windows (todo até o 95, não todo, mas a maior
parte desde então), Linux, a grande maioria dos device drivers (arquivos de
acionamento de dispositivos de hardware), etc.
O uso de componentes e bibliotecas podem levar a ataques deste

tipo mesmo em linguagens como Java ou C# que, a principio, fazem a verificação
de tamanho de todas as áreas.
OSTENSIVO 5-96
Buffer Overflow (3)
Para evitar problemas com buffer overflow, caso o sistema seja

desenvolvido em C ou C++, deve-se evitar algumas funções específicas. Isso
porque mesmo nesta linguagem, existem funções para registro em memória que
fazem o controle adequado do tamanho. Por exemplo, ao invés de usar a função
strcpy (copiar um texto para uma área de memória), deve-se usar a função strncpy
(copiar um texto para uma área de memória até o tamanho determinado).
Geralmente a versão com um “n” no nome significa a proteção para o tamanho da
memória.
sprintf sprintfn, vsprintf vsprintfn, strcat strncat, wcscpy wcsncpy, etc...
Em qualquer linguagem é importante evitar bibliotecas antigas ou que

possuam falhas de segurança conhecidas. Algumas funções do Windows também
possuem esse problema.
O buffer overflow é um problema que não pode ser tratado

externamente à aplicação, devendo ser cuidadosamente validado no momento do
desenvolvimento e estressado durante os testes da aplicação.
OSTENSIVO 5-97
Depuração de aplicação
Um ataque muito comum em aplicações standalone, cliente servidor,

etc., em que um executável é instalado na máquina do usuário consiste na
depuração da aplicação. Raramente aplicações web sofrem esse tipo de problema,
posto que a aplicação executa no servidor, mas muitas vezes aplicações
construidas em tecnologia Flash admitem ataque de depuração. Por exemplo,
Candy Crush e Song Pop.
O princípio deste ataque é que o usuário tem domínio total sobre a

máquina dele. Assim, com o auxílio de ferramentas ou recursos do próprio sistema,
pode ler dados que trafegam entre a sua máquina e o sistema, bem como alterar
quaisquer dados ali.
Eventuais proteções da máquina do usuário, como restrição de

acesso podem ser efetivas em um ambiente controlado, mas, mesmo neste caso,
estão sujeitas a ferramentas próprias que podem contornar esses controles. O
problema é que, fora isso, não existe nenhum tipo de controle de segurança
absoluto para evitar que o usuário contorne a segurança de uma aplicação que
está na máquina dele. Daí surge a recomendação de desenvolver sistemas
sensíveis sempre em arquitetura Web, posto que mais seguros que sistemas
cliente servidor.
OSTENSIVO 5-98
Depuração – Ferramentas
Dentre as diversas ferramentas que podem ser utilizadas para

depuração de sistemas instalados na máquina do usuário podemos destacara
algumas principais. Por exemplo as ferramentas do SysInternals são um conjunto
de pequenas ferramentas, da própria Microsoft, que permitem monitorar uma
aplicação executando no Windows. O objetivo dessas ferramentas é ajudar o
desenvolvedor a identificar erros ou situações de falha, mas acabam por permitir
a captura de dados e alteração de informações.
O Visual Studio, que é a principal ferramenta da Microsoft para

desenvolvimento de sistemas possui também ferramentas de depuração muito
poderosas, que permitem, por exemplo, executar o próprio windows em modo de
depuração, sem que a aplicação possa identificar a presença do depurador.
Um outro tipo de ferramenta altamente danoso são as ferramentas

de registro de ODBC que permitem a interceptação de toda a comunicação entre
a aplicação e o banco de dados. Dentre as informações que podem ser obtidas
desta forma está a credencial de acesso ao banco de dados. Apenas aplicações
instaladas na máquina do usuário permitem esse tipo de ataque, não havendo
forma de usar esse tipo de aplicação em um servidor Web, por exemplo.
Com o crescente aumento no uso de aplicações em dispositivos

móveis (celulares, iPads, etc) também surgiram diversas ferramentas para estes
dispositivos. Tal como nas aplicações instaladas na máquina do usuário, também
aqui o usuário tem poder total podendo ver e alterar os dados mantidos no
dispositivo. Um exemplo de ferramenta deste tipo é o PIRNI que intercepta toda a
comunicação de um iPad ou iPhone com os servidores.
OSTENSIVO 5-99
Campos Ocultos
Campos ocultos não são um ataque, porém são uma fraqueza de

aplicações que permitem a exploração de grande número de ataques, tais como
manipulação de parâmetros, SQL Injection, etc.
Campos ocultos ou hidden fields, são campos de um formulário

web que não aparecem para o usuário. Porém as informações estão presentes
na máquina do usuário, o que significa que sempre é possível ver essas
informações. Alguns sites tentam manipular a função do botão direito do mouse,
para impedir que o usuário veja essas informações, mas como já vimos, basta o
uso da ferramenta adequada para ter acesso a esta informação. Não há como
impedir que informações que estejam na máquina do usuário sejam vistas por
ele.
OSTENSIVO 5-100
Campos Ocultos
Algumas pessoas não sabem que, além de serem vistas, estas

informações também podem ser alteradas. O Internet Explorer nas versões 9 e
posteriores, com a função F12, bem como o FireFox com plugins apropriados,
permitem que os campos ocultos sejam alteradas livremente. Assim as aplicações
devem evitar colocar informações sensíveis nestes campos. Note que
informações de propriedade do usuário mesmo, guardadas em campos ocultos
apenas por uma questão de interface, não há problema. O problema ocorre
quando a informação deveria ser sigilosa ou não deveria ser alterada.
Não apenas os valores podem ser alterados como também

eventuais validações de informações feitas em JavaScript, na máquina do
usuário. Algumas páginas web, por exemplo, verificam se o CPF é válido através
de um código JavaScript na própria página. Essa validação pode ser contornada
com a função F12 descrita acima. Assim, é crucial que a informação seja validada
no servidor. Pode ser validada também no código JavaScript, mas tem que ser
validadas novamente no servidor.
Esse tipo de cuidado deve ser tomado durante o processo de

desenvolvimento e deve ser verificado exaustivamente no processo de teste.
OSTENSIVO 5-101
Ataques à camada Subjacente
Outro ponto que deve-se levar em conta é o fato de que, por mais
que a aplicação tenha segurança implementada, existe a chance do ataque se
originar na máquina do usuário. Obviamente a aplicação não pode garantir que a
máquina do usuário está imune a problemas. Mas existem alguns cuidados que
podem ser tomados para evitar problemas.
•Cuidados comuns de segurança na máquinas de usuários, tais como, anti-virus,

atualização do S.O., etc;
•Educação do usuário sobre riscos de segurança em emails, engenharia social,
etc;
•Uso de captchas para evitar ataques de força bruta;
•Autenticação de dois fatores para autenticação;
•Instalação de componentes de segurança no cliente.
Componentes de segurança tais como o Trustee e outros fazem

uma avaliação do nível de segurança da máquina cliente antes de permitir a
conexão e autenticação no site. Evita que o usuário acesse o site em Lan
Houses, por exemplo.
OSTENSIVO 5-102
Existem inúmeras formas de criar um interceptador de teclado. Alguns em user mode
(Ring 3) e outros em kernel mode (Ring 0). Já vimos alguns deles tais como o IME e o
kbdclass fliter. Existem diversas outras formas porém, em diversas posições do sistema
operacional. Note que a maioria destas formas já foi explorada uma ou mais vezes em
virus e trojans conhecidos.
CAPTCHA
A história do CAPTCHA começou com um teste idealizado logo que

foram inventados computadores. Um dos pioneiros nesta área, Alan Turing, criou
um teste para medir o quão bom era um sistema de inteligência artificial. Seria bom
o suficiente se um humano não conseguisse distinguir o computador de um
humano. Tratava-se de um teste totalmente teórico na época.
Curioso que muitos anos depois nos vemos a volta com o problema
oposto: como um programa pode DIFERENCIAR humanos de programas. A ideia
que é robos na internet podem causar grandes danos à aplicação, posto que
capazes de dezenas de operações por segundo, ao se fazerem passar por um
usuário legitimo.
Existem várias formas de CAPTCHA e todas exploram tarefas que são
triviais para seres humanos mas são muito complexas para a tecnologia atual. A
maior parte dos captchas pede que se leia uma frase e digite. Ocorre que com o
avanço das tecnologias modernas de reconhecimento de caracteres, hoje existe
apenas 28% de diferença entre humanos e os melhores programas de
reconhecimento de caracteres (segundo estudo de Princenton). Ou seja, na média,
de 100 textos, haviam 16 que nem o computador nem o humano conseguem ler, 56
que tanto o computador quanto o humano conseguiam ler e só 28 que o humano
conseguia e o computador não. Algumas novas formas de captcha tem surgido em
função disso, explorando outros aspectos diferentes do reconhecimento de texto,
tais como reconhecimento de figuras, jogos e até cálculos matemáticos.
OSTENSIVO 5-104
Outros ataques
Existem outros ataques menos comuns, mas nem por isso menos
importantes, por exemplo aqueles em que os agentes potenciais de ataque são
da própria equipe da aplicação, desenvolvedores e administradores. Esses
ataques podem ser evitados ou mitigados com alguns controles simples:
•Manter o código fonte em um sistema de gerência de versões;
•O sistema de gerência de versões mantém a informação sobre qual código foi

alterado por cada desenvolvedor;
•Código fonte deve ser revisto por ferramentas automatizadas com capacidade
para identificar ataques potenciais;
•A aplicação deve ser testada de forma extensa antes da colocação em
produção;
O banco de dados deve ser administrado por dois administradores,
sendo que apenas um deles tem direito de acessar as funções de auditoria, mas
não pode executar nenhuma outra ação, enquanto o outro administrador pode
fazer tudo, menos mexer nas funções de auditoria.
O ambiente deve sempre ser mantido por mais de um

administrador de ambiente e revisado periodicamente.
OSTENSIVO 5-105
OSTENSIVO 5-106
Identificação e Autenticação
Identificação e autenticação de usuários são coisas distintas, porém

andam sempre juntas. A identificação, como o nome diz, é meramente uma forma
de se identificar o usuário de forma inequívoca. A identificação só tem que ter uma
característica básica: uma identificação só pode pertencer a um único usuário.
Mesmo que esse usuário se aposente, deixe de usar o sistema, a identificação
permanece associada a ele e não pode ser usada para outro usuário. Além disso,
recomenda-se que a identificação seja fácil de lembrar e que não seja uma
informação pessoal.
A autenticação é algo mais complexo. A autenticação é uma forma do
usuário da aplicação garantir que ele é quem diz que é. Seja numa aplicação, seja
na vida real, existem apenas três formas de ter certeza que uma pessoa é quem
ela diz que é. Usamos muito no relacionamento interpessoal o reconhecimento de
características físicas. Aplicações também usam, na chamada autenticação
biométrica. Mas é mais comum, no caso de aplicações, o uso de algo que só o
usuário sabe (uma senha, por exemplo) ou algo que o usuário possui (um cartão,
token, etc.).
Os melhores mecanismos de autenticação utilizam dois fatores, ou
seja, algo que só o usuário sabe combinado com algo que só o usuário tem, por
exemplo. Trata-se do mecanismo recomendado para autenticação em sistemas
críticos. Note que não é considerada uma autenticação de dois fatores se a
aplicação pede duas coisas que só o usuário sabe, por exemplo, duas senhas.
Para ser dois fatores, precisam ser fatores distintos.
OSTENSIVO 5-107
Autenticação Biométrica
A autenticação biométrica tem sido cada vez mais usada, porém não
é o meio preferencial, visto que ainda é cara e, em alguns casos incomoda.
Considere ainda que existem falhas de diversos tipos, por exemplo, ataques
conhecidos. O número de autenticação biométrica é muito grande e incorpora
diversos aspectos do corpo humano.
A digital do dedo é a forma mais comum, porém existem algumas
restrições: existem pessoas que não as possuem, particularmente trabalhadores
de indústria química, de cimento e outros materiais abrasivos. Sem contar, por
óbvio, amputados. Os dispositivos mais comuns geram muitos erros. Tanto erros
falso negativo quanto falso positivo, ou seja, deixam de reconhecer uma digital
válida ou, o que é pior, reconhecem como válida uma digital que não é.
Para os fãs de filmes de ação, fiquem avisados que não funciona
cortar o dedo da pessoa para passar no mecanismo. Mas existem ainda casos de
quebra deste mecanismo com películas de gelatina com a impressão de digital de
outra pessoa.
Outros mecanismos tem melhor resultado, como a de retina e a de
iris, porém são caros ainda. A autenticação facial tem grande utilidade na
identificação de pessoas sem a cooperação desta, o que pode ser útil em algumas
aplicações.
OSTENSIVO 5-108
Certificado Digital
A autenticação por certificação digital é o tipo de autenticação que

mais tem crescido e que, na opinião dos especialistas, será a forma dominante de
autenticação de usuários no futuro não muito distante. Hoje todo contador e todo
empresário precisa ter eCPF e eCNPJ, não está longe o tempo em que a
identidade de todos terá um certificado digital.
Certificados digitais são arquivos de texto que ligam uma pessoa
específica (nome, CPF, RG, etc.) a uma chave pública. Essa chave pública é
utilizada em um mecanismo de criptografia assimétrica. Neste tipo de algoritmo, as
chaves são sempre geradas em pares: uma pública e uma privada. O que é
criptografado com a chave pública, só pode ser decriptografado com a chave
privada. O que é criptografado com a chave privada só pode ser decriptografado
com a chave pública.
A chave privada é mantida num Smart Card ou outro dispositivo
seguro que fica em poder do usuário. A chave pública é colocada em um
certificado, junto com a identificação da pessoa que tem a chave privada par
dessa. Esse certificado é colocado numa espécie de lista telefônica de pessoas,
onde estão as chaves públicas e certificados de várias pessoas. São as
Autoridades de Registro (AR) e as Autoridades Certificadoras (AC) que mantém
essas listas.
OSTENSIVO 5-109
Autenticação por Certificado
Para a aplicação autenticar o usuário, ou seja, para ter certeza que o

usuário é quem ele diz que é, a aplicação gera uma informação qualquer e manda
para o usuário. O usuário com seu Smart Card, criptograda essa informação
usando sua chave privada e retorna o resultado criptografado para a aplicação.
Esta tenta então decriptografar a informação com a chave pública do usuário que
está no certificado digital deste. Se conseguir decriptografar e obtiver a mesma
informação inicial, tem certeza que foi o usuário que a criptografou.
Trata-se portanto de uma autenticação pelo fator “algo que só o

usuário tem”, que é sua chave privada. Para agregar um segundo fator, a maior
parte dos Smart Cards requer uma senha para acesso à chave privada. Isso evita
que alguém possa usar o Smart Card perdido por um usuário.
Existem cuidados adicionais que devem ser tomados, por exemplo,

verificar a validade do certificado, checar a cadeia de certificados revogados (CRL)
e a validade do certificado raiz. Mas todos os cuidados tomados, a autenticação
por certificados é uma excelente alternativa.
OSTENSIVO 5-110
Login e Senha
Biometria e certificados digitais são alternativas melhores de

autenticação. Porém a maior parte dos sistemas ainda confia na senha para
autenticação do usuário. Se bem implementada, não há nenhum problema.
Trata-se de uma autenticação por algo que só o usuário sabe, perfeitamente
adequada a aplicações.
A grande vantagem da senha sobre as demais formas de

autenticação é a facilidade de implementar no sistema.
Existem porém desvantagens:

•Usuários tem muitas senhas para lembrar hoje em dia, acabam anotando,
usando a mesma senha, usando dados pessoais, todas péssimas práticas;
•Usuários podem contar sua senha para outras pessoas, até para permitir uma
atividade qualquer;
•Usuários podem esquecer a senha, requerendo um processo de recuperação
que, por si só, pode trazer novas vulnerabilidades;
OSTENSIVO 5-111
Armazenamento da Senha
O armazenamento da senha na aplicação deve ser cercada de

cuidados, visto que se trata de informação muito sensível. Antes de mais nada, as
senhas devem ser armazenadas na forma de HASH, que é uma forma de
criptografia irreversível. Recomenda-se usar hoje em dia SHA-256 ou SHA-512,
mas o uso de MD5 ou SHA-1 ainda é aceito. Note que, como a criptografia é
irreversível, não há como decriptografar a senha. O sistema criptografa a senha
digitada pelo usuário e compara o HASH com o HASH armazenado. Se forem
iguais, a senha é igual.
As senhas não devem ser criptografadas puras, mas sim uma
concatenação da senha com o login (identificação do usuário) e mais uma chave
fixa para a aplicação. Isso garante que mesmo que dois usuários utilizem a mesma
senha, os HASH não serão iguais.
Mas mesmo com todos esses cuidados, a tabela com os HASH de
senhas do usuário é extremamente sensível. Nunca copie os HASH de senhas do
ambiente de produção para o de homologação ou desenvolvimento, por exemplo.
Uma alternativa comum é o armazenamento dessas credenciais de
autenticação num servidor LDAP que já possui controle adequado atendendo ao
itens indicados.
OSTENSIVO 5-112
Login em Aplicações Web
Em aplicações web, é importante notar que a tela de autenticação e

todas as telas posteriores a esta devem estar no protocolo HTTPS, ou seja, com
criptografia entre o navegador e o servidor web. É errado o procedimento de
alguns sites que utilizam HTTPS no login mas depois voltam para o protocolo
HTTP, sem criptografia. Isso permite que a sessão seja obtida por diversos
ataques de sequestro de sessão. Apenas as páginas públicas anteriores ao login
do usuário podem ser no protocolo HTTP.
O servidor da aplicação deve possuir certificado digital apropriado,
pois isso evita ataques de man in the middle (literalmente, “homem no meio”), em
que um atacante consegue se fazer passar pela aplicação para o usuário e, ao
mesmo tempo, se faz passar pelo usuário para a aplicação. Também evita que o
usuário acesse sites falsos.
O login e a senha devem ser passados via POST, nunca via GET. O
método GET de passagem de parametros é aquele em que os parâmetros são
passados na URL, por exemplo,
“https://www.meusite.com.br/login.aspx?login=fulano&senha=123”. O HTTPS
criptografa toda a comunicação entre o navegador e a aplicação, mas NÃO
criptografa a URL, permitindo que o login e a senha sejam capturados no
caminho.
Finalmente é uma prática ruim de muitos desenvolvedores guardar
as credenciais de autenticação para
OSTENSIVO 5-113
Ciclo de Vida do Usuário
Um ponto importante quando tratamos de segurança na

autenticação do usuário é que não basta cuidar do momento da autenticação em
si. É preciso observar e planejar todo o ciclo de vida do usuário, ou seja, de nada
adiante uma autenticação 100% segura se qualquer um consegue criar um
usuário e obter acesso ao sistema.
A aplicação não tem como autenticar o usuário que está sendo
criado. É preciso que exista um processo anterior de autenticação física deste
para a criação do usuário. Recomenda-se ainda ampla auditoria neste processo
de forma a permitir auditoria sobre todos os usuários com poder de criar novos
usuários. Toda a criação de usuário deve possuir documentação comprobatória.
Outros eventos ao longo da vida do usuário devem ser observados,
por exemplo, transferências para outros setores, troca de senha, troca de
direitos, férias, promoções, etc. tudo deve ser levado em conta. Finalmente é
importante observar como será o desligamento do usuário. Recomenda-se que o
desligamento seja sempre lógico, nunca físico, de forma que os dados do
usuário sejam mantidos para propósito de auditoria.
OSTENSIVO 5-114
Gestão de Identidade
A dificuldade de acompanhar os procedimento de criação de

usuários, mudança de perfil de acesso, desligamento, etc., em grandes
organizações levou à criação dos chamados sistemas de gestão de identidade,
ou identity manager (IM). Estes sistemas são na verdade grandes interfaces para
um sistema de diretório onde as informações de todos os usuários, aplicações e
perfis de acesso na organização. Nesta interface única o departamento
responsável pelo controle do pessoal pode cadastrar novos usuários e designar
acessos aos diversos sistemas. Cada sistema tem uma interface com o sistema
de IM e seus usuários e perfis são definidos a partir daí.
OSTENSIVO 5-115
Métrica da Senha
Importante também que o sistema requeira senhas fortes. Usuários

tendem a usar senhas fracas que podem ser facilmente quebradas por força
bruta ou por ataques de dicionário. Uma boa senha não deve ser menor que oito
caracteres e deve conter números, letras maiúsculas e minúsculas e sinais, pelo
menos um de cada. De fato, as boas práticas recomendam que a senha mínima
seja de doze caracteres, também incluindo um caractere de cada tipo para
considerar o aumento da capacidade de quebra por força bruta no futuro.
Caso a senha tenha que ser numérica, devem ser impedidas

também sequencias, repetições e quaisquer informações do próprio usuário, tais
como telefone, CPF, data de aniversário, etc.
OSTENSIVO 5-116
Bloqueio da senha
Outra proteção importante para evitar a quebra de senhas por força

bruta é o bloqueio por tentativas erradas de login. A implementação desta
característica visa impedir o ataque por força bruta, ou tentativa e erro, bloqueando
a senha após um número de tentativas erradas. É importante que o bloqueio tenha
uma duração mínima grande ou requeira que o usuário reative pessoalmente sua
conta. Além disso, é importante que o bloqueio funcione contra ataques
simultâneos: ao invés de tentar uma senha após a outra, o atacante, com ajuda de
um robô, pode abrir 100 janelas e disparar 100 requisições com 100 senhas ao
mesmo tempo.
Importante também que a senha inicial designada ao usuário seja

trocada no primeiro login, posto que trata-se de senha que também é de
conhecimento da equipe que cadastrou o usuário. Além disso, se o usuário não for
obrigado a trocar sua senha no primeiro login, é provável que fique com a mesma
por muito tempo.
OSTENSIVO 5-117
Bloqueio da senha
Mesmo com a troca inicial, é importante que o usuário seja obrigado

a trocar a senha periodicamente, pelo menos uma vez por ano. A recomendação
das boas práticas porém é forçar a troca da senha a cada noventa dias (3 meses).
Usuários contam suas senhas, escrevem em papel, de forma que, com o tempo, o
sigilo da senha se perde. A frequência de troca muito alta tende a aumentar os
chamados a suporte, pois é muito comum o usuário trocar a senha e
imediatamente esquecer a senha nova.
Importante também planejar o mecanismo caso o usuário tenha

esquecido a senha. O mecanismo deve possuir, no mínimo, um mecanismo de
garantia de autenticidade do usuário. Por exemplo, a senha só pode ser reativada
pelo email que se sabe ser do usuário. Mesmo assim, recomenda-se que existam
outras formas de autenticação para evitar que o comprometimento do email possa
levar ao comprometimento da conta na aplicação.
OSTENSIVO 5-118
Resposta da Autenticação
A resposta da autenticação deve ser a mesma caso a senha esteja

errada ou o login esteja errado. O motivo é para evitar que um atacante consiga
descobrir logins ou identificações de usuários válidas no sistema por tentativa e
erro. Esse tipo de ataque é chamado de “enumeração de usuários” e facilita
ataques de engenharia social. Note que no registro da trilha de auditoria do
sistema pode conter a informação sobre se foi o login ou a senha que está
errada, apenas a mensagem para o usuário deve ser restrita.
Deve-se cuidar também para que no mecanismo de “esqueci minha

senha” não seja informado também se um usuário é válido ou não. Por exemplo,
se a pessoa disser que esqueceu a senha do seu usuário e colocar um usuário
inválido, o sistema deve seguir sem avisar que aquele usuário não existe.
OSTENSIVO 5-119
Acesso ao Sistema
O aviso de responsabilidade legal tem o objetivo simples de impedir

que o usuário alegue não saber que não podia retirar informações do sistema em
um eventual processo legal. O histórico de acesso, por outro lado, tem um objetivo
claro: permitir que o usuário identifique se sua conta foi acessada por outra
pessoa. Caso a data do último acesso não corresponde a data que ele
efetivamente acessou a conta, isso indica que houve um acesso indevido por outra
pessoa.
OSTENSIVO 5-120
Contorno do mecanismo
O controle de acesso é a funcionalidade de segurança da aplicação

que verifica se o usuário tem direito a ver ou alterar determinada informação e
permite esse acesso ou não. Geralmente é composta de uma tabela ou lista de
direitos de acesso definida conforme o perfil do usuário. O fato é que, em algum
ponto da aplicação, existe um código que verifica se o usuário tem direito a ver a
informação ou não.
A questão é que todo mecanismo de controle de acesso tem uma

fraqueza comum: se contornado, perde sua eficácia. Claro que, ciente disto,
busca-se meios de garantir que todo o acesso a informações passe pelo controle
de acesso. Note que o ataque conhecido como contorno do controle de acesso
geralmente é feito explorando-se outras fragilidades fora da aplicação em si. Por
exemplo, se o banco de dados aceita conexões diretas, um usuário pode tentar
conectar-se diretamente a este e, assim, contornar o controle de acesso.
OSTENSIVO 5-121
Contorno...como resolver
Não há uma forma de impedir totalmente esse possível ataque, mas

existem formas de dificultar essa tarefa. Notoriamente o que desejamos proteger
são os dados, não a aplicação. Então quanto mais próximo dos dados estiver o
controle de acesso, melhor a segurança da aplicação. O ideal seria fazer todo o
controle de acesso no banco de dados. Algumas aplicações de fato fazem isso.
Porém a implementação do controle de acesso no banco de dados é algo muito
caro em termos de desenvolvimento de sistemas, pois os bancos de dados não
são direcionados para a execução desta tarefa. Assim, normalmente, num sistema
em n camadas, a tarefa cai para a camada seguinte, o servidor de aplicação. Esse
tipo de arquitetura é bastante adequado.
Fazer na camada seguinte, que seria o servidor web, já é menos
indicado. A pior situação seria fazer isso na camada de interface. Por exemplo, um
sistema que faça o controle de acesso em JavaScript. Nota-se que seria algo
totalmente ilógico e facilmente poderia ser contornado. Nunca deve ser feito o
controle de acesso na máquina do usuário, pois, como já vimos, essa máquina
está totalmente no controle deste.
Importante ainda garantir que todas as conexões após o controle de
acesso tenham um alto grau de segurança. Neste caso, a conexão do servidor de
aplicações com o servidor do banco de dados.
OSTENSIVO 5-122
Conexão ao BD
A conexão entre a aplicação com o servidor de banco de dados

requer a chamada “string de conexão ou banco de dados” ou as credenciais de
conexão ao banco de dados. Basicamente esta informação indica qual o
endereço do servidor do banco de dados, um usuário e uma senha para a
conexão, além de outros itens de configuração que variam de banco de dados
para banco de dados.
Estas credenciais não devem nunca ficar diretamente no código.

Devem ser mantidas sempre num arquivo a parte, por exemplo, o web.config (no
caso da plataforma .net) ou .PROPERTIES (no caso de sistemas Java). O motivo
disto é que, como qualquer senha, deve ser trocada periodicamente. Em caso de
ataque, deve ser possível trocar essa senha sem que seja necessário alterar o
código da aplicação e, finalmente, é interessante que a equipe de
desenvolvimento não conheça as credenciais de produção.
OSTENSIVO 5-123
Interfaces com outros sistemas
Quando buscamos pontos fracos em aplicações, o primeiro lugar para

procurar é nas interfaces da aplicação com outras aplicações ou sistemas.
Geralmente esse tipo de mecanismo apresenta falhas justamente porque os
desenvolvedores tem a tendência de não ver a interface como parte da aplicação e
portanto como responsabilidade da equipe. Quanto uma aplicação tem que enviar ou
receber dados de outra são precisos controles de segurança mínimos:
• Garantia de autenticidade – como as aplicações podem ter certeza que estão
falando com a aplicação correta?
• Garantia de confidencialidade – como garantir que os dados não sejam
observados no trajeto entre as aplicações?
• Garantia de integridade – como garantir que os dados não sejam alterados ou
destruídos no trajeto entre as aplicações?
• Garantia de disponibilidade – como tratar a falta da outra ponta da interface?
• Garantia de rastreabilidade – como garantir que as informações trafegadas são
registradas e podem ser auditadas em caso de problemas?
Atender todos os itens acima parece algo bastante difícil. Hoje existe
uma solução quase que global e que funciona muito bem: Web Services sobre
HTTPS com certificados digitais em ambas as pontas. Essa solução deve sempre
ser buscada em novos sistemas. O problema é que, quando fazemos interface com
um sistema mais antigo, nem sempre temos essa possibilidade.
OSTENSIVO 5-124
Integridade de dados
Além dos aspectos de controle de acesso e proteção de interfaces,

os sistemas devem se preocupar ainda na garantia de integridade interna das
informações. Existem três controles importantes para a garantia da integridade de
informações, ou seja, para evitar que informações sejam alteradas de forma
indevida ou perdidas. A integridade física refere-se a possibilidade do local onde
as informações foram armazenadas ser fisicamente destruído ou danificado. Um
disco com erro ou uma falha no equipamento. A solução para esse tipo de
problema é naturalmente a redundância, ou seja, nunca deve haver um só disco
rígido ou uma só cópia das informações. Esquemas com múltiplos discos são
sempre indicados.
A integridade estrutural refere-se a manutenção das chaves
primárias e chaves estrangeiras no banco de dados. Quando uma tabela do
banco de dados faz referência a outra tabela, deve-se garantir que os registros
sejam gerenciados em conjunto, evitando que mudança em uma tabela torne os
dados na outra tabela inválidos.
Finalmente, a integridade transacional é importante e envolve várias
funções do sistema. Uma transação é um conjunto de operações realizadas pela
aplicação que só fazem sentido se forem feitas todas em conjunto. Por exemplo,
quando você faz o pagamento de uma conta no internet banking isso é uma
transação que é composta de duas ações distintas. Primeiro a aplicação retira o
dinheiro da sua conta, depois registra o pagamento da conta na tabela de boletos.
Se, por exemplo, ocorrer um erro no segunda ação seu dinheiro vai sumir. Por
isso existem os comandos StartTransaction, Commit e Rollback. Se houver um
erro em qualquer etapa, todas as ações realizadas até ali devem ser desfeitas.
OSTENSIVO 5-125
Informação Residual
Informação residual refere-se a informação que foi apagada do

sistema. Todos sabemos, por exemplo, que apagar um arquivo do windows não
elimina de fato a informação. Esta pode ser colocada na lixeira, mesmo depois o
windows apenas marca o arquivo como apagado. O mesmo ocorre com
informações em um banco de dados.
Em qualquer caso, mesmo uma informação apagada e reescrita
várias vezes ainda pode ser recuperada por equipamentos especiais que
aproveitam o fato que a cabeça de gravação do disco rígido, com o tempo, se
desloca levemente deixando traços da informação anterior nas margens da trilha
principal. Claro que isso não pode ser feito de forma simples. É preciso recuperar
o disco rígido e levá-lo a um laboratório próprio. Porém alguns tipos de
informação são sensíveis a ponto de justificar tal procedimento.
Finalmente um outro tipo de informação residual são os proxies e
caches na internet. Estes servidores tem por objetivo aumentar a velocidade do
trafego pelo armazenamento temporário de algumas informações. Porém isso
implica em criar cópias de informações que perdemos o controle. Existem porém
mecanismo para impedir isso, basicamente o uso de HTTPS e informação expires
no cabeçalho HTTP.
OSTENSIVO 5-126
Privacidade
A privacidade é normalmente uma preocupação maior dos usuários

de uma aplicação do que de quem defende uma aplicação. Porém existem
controles de segurança importantes para tratar a privacidade das informações de
usuários na aplicação. Existem quatro tipos básicos de privacidade:
Invisibilidade – Ocorre quando um usuário não pode obter
informações de outro usuário. O sistema em si vê todas as informações de todos
os usuários. É o caso da privacidade do facebook, por exemplo.
Pseudônimo – Ocorre quando a identidade do usuário é protegida por
um pseudônimo. Apenas um mecanismo seguro pode ligar o pseudônimo ao
usuário real, se for necessário. Esse tipo de privacidade é usado em aplicações
“disque-denúncia” com premiação.
Não rastreamento – Ocorre quando o usuário é autenticado pelo
sistema, então o sistema sabe quem é o usuário, mas as ações ligadas ao usuário
não são registradas de nenhuma forma. Isso impede que o sistema ou qualquer
outro usuário saiba quem realizou que ações. Trata-se da privacidade da urna
eletrônica brasileira. O eleitor é identificado, mas seu voto não é ligado a ele.
Anonimato – Trata-se da forma mais extrema de privacidade. Os
usuários do sistema não se identificam. Se não há qualquer identificação dos
usuários, não há quebra de privacidade.
OSTENSIVO 5-127
Segurança no Desenvolvimento de 25.11.14
Aplicações Críticas
O controle de segurança sobre o programador, conforme vimos, é composto pelo uso de

gerencia de configuração, compilação ou build automatizado, inspeção de código
periódica e responsabilização do desenvolvedor. Também é importante que cada
programador tenha sua senha individual e controles sobre o ambiente de programação.
www.modulo.com 128
O controle sobre o administrador do banco de dados, por outro lado, requer a dupla
administração.
Um administrador pode tudo, menos mexer ou visualizar a auditoria. Outro

administrador não pode nada, a não ser ver e administrar a auditoria. Tudo que o
primeiro administrador faz é registrado na auditoria do banco de dados e verificado
periodicamente pelo segundo administrador.
Trata-se de controle posterior, é fato, porém garante ao mesmo tempo a agilidade na

administração da informação com a capacidade de identificar e detectar ataques
internos.
www.modulo.com 129
Segurança do Ambiente de Desenvolvimento
Como vimos, muitos dos controles de segurança de uma aplicação

dependem do processo em que esta foi desenvolvida. Assim é importante
cuidarmos para que o ambiente onde as aplicações são criadas, ou seja, o
ambiente de desenvolvimento, tenha mecanismos de segurança adequados.
OSTENSIVO 5-130
Ambiente Seguro
A segurança de um ambiente de desenvolvimento é composta por

alguns elementos centrais indicados no slide. A restrição física e lógica é
necessária porque tanto a saída de código fonte sensível quanto a entrada de
componentes e código malicioso podem ser muito ruins para a segurança final do
sistema. Veremos isso em mais detalhes na segregação de ambientes.
Os controles de segurança são aqueles controles normais que
devem valer para todos os ambientes: máquinas com anti-virus e backup, política
de mesa limpa, etc.
A gerência de configuração é uma ferramenta muito importante
principalmente para garantir a segurança da aplicação contra eventuais ataques
do desenvolvedor.
Finalmente a inspeção de código e os testes de segurança são
fundamentais para a qualidade da aplicação gerada. A inspeção de código tem a
capacidade de identificar falhas no código que podem ser exploradas no futuro
por um agente de ataque e também a inclusão de código malicioso por
desenvolvedores. Os testes de segurança tem por objetivo verificar se a
aplicação está suficientemente robusta para aguentar os ataques que fatalmente
irá receber quando em produção.
OSTENSIVO 5-131
Segregação de Ambiente
A segregação de ambiente é um principio central da segurança no

desenvolvimento de sistemas. Ele diz que os desenvolvedores não devem ter
qualquer acesso ao ambiente de produção, ou seja, acessar diretamente o
banco de dados de produção, configurar diretamente maquinas no ambiente de
produção e etc. Não impede que os desenvolvedores sejam usuários normais
das aplicações em produção, mas eles não podem ser administradores nem ter
qualquer acesso interno às aplicações em produção.
Esse impedimento, que é muito difícil na prática, visa impedir que
desenvolvedores possam incluir código malicioso diretamente no ambiente de
produção e também garantir que o processo de colocação da aplicação em
produção não é um segredo, ou seja, que segue um procedimento escrito.
Desenvolvedores tendem a adotar uma postura de pais de suas aplicações. Isso
é algo ruim porque se um desenvolvedor sai da equipe, a aplicação fica órfã.
Também reforça esse principio que os bancos de dados de
desenvolvimento e homologação, ou seja, os bancos de dados em que as
aplicações são desenvolvidas e testadas, não devem conter dados válidos de
produção. Isso decorre do fato que os ambientes de desenvolvimento e
homologação, por sua natureza, tem uma configuração de direitos de acesso
menos restritiva. Dados de produção poderiam ser roubados com facilidade
desta forma.
OSTENSIVO 5-132
Banco de Desenvolvimento
O fato dos desenvolvedores não poderem mexer diretamente no

banco de produção e que os bancos de homologação e desenvolvimento não
podem ter dados de produção apresenta dois problemas práticos: as mudanças
no banco de desenvolvimento precisam ser replicadas para os demais bancos.
Os dados do ambiente de desenvolvimento e homologação precisam ser o mais
próximo possível do banco de produção.
A solução para as alterações no banco de produção é a utilização
de scripts de alteração. Esses scripts são escritos pelos desenvolvedores e
repassados para a equipe de manutenção do banco de produção. A equipe
então pode avaliar se os scripts são adequados e, sendo adequados, pode
executar as alterações em produção.
Para ter um banco de desenvolvimento próximo ao banco de
produção são utilizados mecanismos de scrambler, ou misturador, esses
mecanismos pegam os dados do ambiente e copiam para outro ambiente mas
trocando todas as referencias e embaralhando os dados. Assim, ao final, o
banco de homologação vai ter uma base similar a de produção, porém
totalmente inválida.
OSTENSIVO 5-133
Gerência de Versionamento
A gerência de versionamento, gerência de versões, gerência de

configuração é uma ferramenta utilizada pelos desenvolvedores para guardar o
código fonte das aplicações. Essa ferramenta atua como um repositório de
arquivos de código fonte e tem as seguintes funcionalidades:
Para cada arquivo armazenado, quando este é alterado, guarda as
alterações, de forma que pode ser obtida qualquer versão daquele arquivo;
Os desenvolvedores devem se autenticar para poder guardar os arquivos de
código fonte, alterá-los, etc;
Cada alteração fica registrada também o nome do desenvolvedor que
fez a alteração;
Algumas das ferramentas fazem a compilação do código
armazenado automaticamente, bastando o desenvolvedor avisar que está pronto;
Permite o controle de acesso, ou seja, nem todos os
desenvolvedores podem mexer em todos os fontes;
Permite que dois desenvolvedores trabalhem no mesmo código e depois consegue
juntar as duas alterações mantendo o formato do arquivo;
Como contém todo o código fonte da aplicação, é ideal para o
backup das informações;
Essas ferramentas portanto são uteis por vários motivos, inclusive
pela segurança.
OSTENSIVO 5-134
Controle sobre o programador
O controle sobre o programador é algo muito difícil, posto que este

tem controle total sobre o código fonte da aplicação. Muitas vezes são
profissionais caros e difíceis de encontrar no mercado. Porém existem inúmeros
casos de programadores que incluíram código malicioso com o objetivo de
ganho financeiro ou até para ter acesso posterior ao código. O controle é feito
portanto com a ferramenta de gerência de versionamento, configurada
adequadamente para registrar todas as alterações feitas por desenvolvedores.
Além disso é imprescindível que o código fonte passe por inspeção

de código periódica, visto que a maior parte do código malicioso incluso por
desenvolvedores não tem como ser pego em testes de segurança, apenas com
inspeção de código. Essa inspeção deve ser realizada periodicamente e, claro,
sendo identificado um problema, recomenda-se a punição adequada ao
desenvolvedor. Esse mecanismo visa, por óbvio, desestimular o tipo de prática
que, via de regra, é de difícil detecção.
OSTENSIVO 5-135
Desenvolvimento terceirizado
Muitas vezes o desenvolvimento de aplicações é feito de forma

terceirizada, ou seja, uma equipe externa é chamada para produzir a aplicação.
Nestas situações surgem preocupações de segurança pois temos menos controle
sobre a equipe que efetivamente irá desenvolver o código fonte. Todas as
preocupações com a segurança do código ficam maiores. Quando a terceirização
é externa, ou seja, a aplicação é desenvolvida totalmente fora da organização,
considera-se também o problema da perda de sigilo do código fonte.
De fato, nestas situações, deve ser requerido de forma contratual que

a fábrica de software possua os controles de segurança desejados, ou seja:
• Seja utilizado sistema de gerenciamento de versões, responsabilização do
desenvolvedor, etc;
• O mesmo desenvolvedor não trabalhe em mais de um projeto no período de
execução do projeto na empresa;
• Que o código fonte do sistema passe por inspeções periódicas e seja
armazenado com sigilo;
• Que sejam feitos os testes e avaliações pertinentes.
Muito importante que essas preocupações sejam explicitadas no

momento da contratação da empresa terceira pois implicam em custos e não
haverá como incluí-las posteriormente no contrato.
OSTENSIVO 5-136
Central de Testes
Adicionalmente é muito comum que sejam adotadas práticas de

reteste e qualidade no recebimento da aplicação. Refazer todo o teste ao
receber a aplicação é contraproducente posto que o objetivo é justamente que a
fabrica faça o desenvolvimento completo. Porém é necessário que seja feita uma
avaliação para garantir que a aplicação recebida atenda os critérios de
segurança esperados. Os testes da aplicação devem ser conduzidos de forma
integral pela fábrica de software, porém sempre com base em planos de teste
detalhados. Desta forma, os testes podem ser reproduzidos.
Normalmente faz-se um teste por amostragem: refaz-se 10% dos

planos de teste na empresa. Esses testes, por óbvio, devem passar, visto que já
foram feitos pela fábrica e fornecem um indicativo que a fábrica de fato testou a
aplicação adequadamente. Adicionalmente é crucial que seja feita a inspeção no
código que pode também ser por amostragem.
OSTENSIVO 5-137
O Erro na Aplicação
Toda aplicação pode encontrar erros e falhas. De fato, as

aplicações, softwares, estão entre os mecanismos mais complexos produzidos.
Essa complexidade acaba por gerar um grande número de erros e falhas. Assim
é crucial que sejam feitos diversos testes ao longo do desenvolvimento da
aplicação e mesmo depois desta pronta.
Existem distinções teóricas entre defeito, erro e falha, conforme

indicado acima. Para todos os efeitos, porém, todos os casso são ameaças a
segurança da aplicação e precisam ser tratados. Mesmo após pronta a
aplicação, é importante ter em mente que esta pode apresentar erros. Sempre
haverão correções a serem feitas, novas versões e mudanças no sistema.
Inúmeros estudos mostram que quanto mais cedo um erro é

identificado no processo de desenvolvimento, mais barato é sua correção. Dai a
execução de inspeções de código e testes unitários bem no início do processo
de desenvolvimento.
OSTENSIVO 5-138
Ferramenta de Gestão
Como os erros e falhas vão acompanhar a aplicação por toda a

vida útil desta, é imprescindível que exista uma ferramenta de registro destes
problemas. As ferramentas mais comuns permitem que os usuários da aplicação
registrem os problemas e solicitem a correção. Normalmente uma equipe de
manutenção irá priorizar os problemas identificados repassando para a equipe
de desenvolvimento quais devem ser tratados e qual a prioridade de cada um
deles.
A correção de um erro passa então por algumas fases: detecção,

investigação (para descobrir a origem da falha), proposta de solução (projeto da
correção), priorização, alteração, teste e avaliação, colocação em produção da
nova versão. Todas essas atividades são registradas nestes sistemas o que
permite não só ter o controle sobre as falhas mas também obter métricas de
qualidade do software.
OSTENSIVO 5-139
Testes de Avaliação de Segurança
Os testes importantes para a segurança da aplicação dividem-se m

quatro grandes grupos indicados no slide acima. Dois deles são realizados
periodicamente ao longo do ciclo de desenvolvimento e dois são realizados ao
final, sempre que uma nova versão é colocada em produção.
Note que a forma precisa que esses testes são feitos varia de
empresa para empresa e conforme a capacidade da equipe de testes e de
desenvolvimento, porém todos tem algumas características em comum:
• Sempre que possível, se utilizam ferramentas. Os tempos do testador de
software que sentava no micro e ficava mexendo na aplicação acabaram;
• Os planos de teste, ferramentas usadas e resultados obtidos são registrados e
armazenados. Permitem o reteste posterior, garantem a execução dos testes e
a limitação de responsabilidade;
• O analista de teste deve ter o mesmo nível de conhecimento na plataforma de
desenvolvimento que o desenvolvedor do sistema;
• O analista de teste não é o cara que vai testar o sistema: é o cara que vai criar
os planos de teste, escrever os scripts de teste, rodar as ferramentas, coletar
os resultados, etc;
Evidente que nenhum teste é adequado se os resultados não forem
impeditivos: aplicação não testada ou com teste com resultado final não aprovado
não entra em produção.
OSTENSIVO 5-140
Inspeção de Código
A inspeção de código consiste em um desenvolvedor diferente do

desenvolvedor que produziu o código, revisar o código produzido. O desenvolvedor
original tem dificuldade de ver um erro no seu código porque está “acostumado”
com ele. Outro desenvolvedor pode ver a coisa de forma diferente e identificar a
falha. Trata-se, de fato, de um mecanismo muito eficaz. Muitos problemas são
encontrados desta forma. O problema é que o desenvolvedor que vai revisar tem
que conhecer a aplicação, entender a linguagem e pode demorar mais tempo para
revisar do que o tempo que foi gasto para produzir o código.
Para não tornar a inspeção algo inviável, recorre-se a ferramentas
que analisam todo o código e apontam áreas problemáticas. O revisor então só
precisa avaliar aquelas áreas específicas, não sendo requerido que veja todo o
código fonte.
As vantagens da inspeção incluem o fato que pode ser feita desde o
início do processo de desenvolvimento. Recomenda-se que seja feita em todo o
código que passe no teste unitário, por exemplo em cada ciclo Scrum.
Uma vantagem grande para o aspecto da segurança advém do fato
deste tipo de teste ser o único capaz de identificar código malicioso colocado pelo
desenvolvedor. Tipicamente um backdoor colocado por desenvolvedor irá requerer
que o usuário clique numa parte do sistema e digite F5, ‘B’, 33 e só então será
aberta a tela do backdoor. Por melhor que seja o teste funcional do sistema, pouco
provável que acabe por identificar que há um backdoor.
OSTENSIVO 5-141
Ferramentas – Inspeção de Código
Existem inúmeras ferramentas para auxilio na inspeção de código,

sendo algumas delas indicadas acima. As ferramentas freeware FindBugs e
Clang também são boas alternativas para esse tipo de trabalho. Importante notar
que a mera execução da ferramenta costuma gerar muitos falsos positivos
sendo necessário que um desenvolvedor avalie os códigos apontados pela
ferramenta para a conclusão final do processo. As ferramentas de fato apenas
apontam os pontos fracos, não identificam exatamente a vulnerabilidade.
O Safeval tem a característica particular de ser em português e a

vantagem de tratar muitas linguagens de programação além das mais comuns.
Por exemplo, é a única ferramenta efetiva a inspecionar código em Oracle Forms
e Lotus Domino. Pode ser usada não apenas em aplicações Web mas também
aplicações cliente servidor e em aplicações mobile, para celulares e dispositivos
móveis.
OSTENSIVO 5-142
Testes funcionais unitários
Os testes unitários consistem na execução de pequenos testes tão

logo uma pequena parte do código esteja pronta. Por exemplo, assim que
concluímos a codificação de uma classe Java, criamos outra classe com o
objetivo de testar aquela. Essa classe de teste irá chamar todas as funções e
métodos da classe desenvolvida passando os parâmetros esperados ou não e
irá avaliar se a resposta da classe desenvolvida está em conformidade com o
que foi especificado.
Também pode ser feito através da codificação de um script de teste

para cada classe ou função. Normalmente o próprio desenvolvedor produz a
classe de teste, mas recomenda-se que essa tarefa seja feita por outra pessoa,
um analista de teste, para evitar que a classe de teste contenha condições e
paradigmas ocultos. O desenvolvedor pode ter entendido errado a ideia da
classe e daí vai produzir a classe errada e a classe de teste errada.
Ao concluir um ciclo de desenvolvimento, todas as classes e

funções produzidas com suas classes de teste são avaliadas para garantir a
adequação do código até aquele ciclo. Os ciclos de desenvolvimento, nas
metodologias ágeis mais comuns, duram 15 dias ou duas semanas.
OSTENSIVO 5-143
Ferramentas – Teste Unitário
Existem inúmeras ferramentas para o teste unitário, embora muitas

delas sejam ligadas à plataforma ou linguagem. A grande maioria visa a
linguagem Java. Essas ferramentas muitas vezes são as mesmas que fazem os
testes integrados. Importante notar que o objetivo original dos testes unitários e
dessas ferramentas é a qualidade do código. Mas estamos preocupados
também com a segurança do código. Assim é importante que sejam incluídos
testes em que são passados, por exemplo:
• Informações muito mais longas que o esperado, para verificar a possibilidade

de buffer overflow;
• Informações inválidas com ‘ (plic), “ (aspas), / (barra), \ (contrabarra) etc;
• Condições inválidas como informações incoerentes;
Nestes casos, espera-se que ocorra um erro, mas que esse erro
seja normal, ou seja, não comprometa a segurança do sistema.
OSTENSIVO 5-144
Teste integrado
O teste integrado é aquele teste que é feito com o sistema todo,

ou, pelo menos, com uma parte significativa do sistema operando em conjunto.
Enquanto o teste unitário irá identificar eventuais problemas em um pequeno
módulo ou classe do sistema, o teste integrado irá avaliar possíveis erros
advindos de falha no “encaixe” de um módulo com outro. O teste integrado,
embora possa ser realizado em ciclos também, é particularmente útil no
processo de homologação da aplicação, ou seja, quando esta irá para produção.
Note que o teste integrado deve verificar todos os requisitos de

segurança do sistema. Por exemplo, se a especificação do sistema diz que se
errar a senha 3x a conta será bloqueada, deve haver algum teste ou script
próprio para testar isso.
OSTENSIVO 5-145
Ferramentas – Teste integrado
Existem também um grande número de ferramentas para teste

integrado, que são similares às de teste unitário. Importante é que exista o teste
com uma ferramenta definida, sempre feito com scripts e planos de teste bem
definidos para permitir o reteste.
OSTENSIVO 5-146
Teste de Invasão
O teste integrado verifica se os requisitos de segurança foram

atendidos. Porém é preciso verificar se a aplicação gerada é resistente a
ataques normais. Para tal, procede-se o teste de invasão, também chamado de
teste de penetração ou análise de vulnerabilidade. Este teste consiste em agir
como um potencial atacante, utilizando ferramentas e técnicas típicas de ataque.
OSTENSIVO 5-147
Ferramentas – Invasão
As ferramentas de ataque são particularmente numerosas, sendo

que é importante que tais ferramentas sejam executadas por alguém com
conhecimento em ataques. Isso porque essas ferramentas tem diversas
particularidades de configuração que demandam conhecimento do objetivo final
e da mecânica do ataque.
Importante a questão do tempo de ataque. Lembre-se que o

profissional que fará o teste tem alguns dias para tentar vencer as defesas da
aplicação. O atacante real, por outro lado, terá muito mais tempo. Por isso
recomenda-se que sejam testes caixa branca, ou seja, que o analista de teste
que fará o teste de invasão conheça o sistema e seu código, podendo assim
direcionar o ataque para os pontos mais frágeis.
OSTENSIVO 5-148
Ferramentas para Segurança de Aplicações
Nesta parte final do curso, vamos ver algumas ferramentas

utilizadas para avaliar a segurança de aplicações inclusive com alguns testes.
OSTENSIVO 5-149
Ferramentas
Nikto
Script Perl, utilizado para fazer um levantamento de informações

sobre o web server e suas extensões instaladas (PHP, SSL, dentre outras).
Fornece informações importantes para análise, como a versão do servidor web,
quais métodos ele suporta, dentre outras informações relevantes.
Esta ferramenta pode deixar rastros em log de servidores web e

ser detectada por um IDS.
OSTENSIVO 5-150
Ferramentas
Dirbuster
Ferramenta da Owasp, que faz testes de força bruta contra

servidores web tentando localizar sub-níveis deste servidor web e arquivos
ocultos.
Usa um arquivo com um dicionário para fazer comparações contra
o servidor web. Caso as requisições dele resultem em um código 200
(Sucessful) será registrada a existência do arquivo e que o mesmo está
disponível.
Ferramenta barulhenta, que deixa rastros nos logs. Parte destes
rastros podem ser ocultados se alterando o UserAgent da ferramenta.
OSTENSIVO 5-151
Ferramentas
W3AF
W3AF (Web Aplication Attack and Audit Framework) é um conjunto de

ferramentas automatizadas para levantamento de vulnerabilidades e exploração
das mesmas, o qual pode simplificar muito a tarefa de auditoria e ataque contra
sites web.
É uma ferramenta que deixa muitos rastros e costuma gerar muitos
falso-positivos.
OSTENSIVO 5-152
Ferramentas
Web Scarab
Ferramenta da Owasp, é um framework para análise de aplicações

HTTP e HTTPS, sendo mais utilizado como um Proxy para interceptar as
requisições HTTP, dando a oportunidade para o analista (ou hacker) interpretar
os resultados ou até mesmo alterar o mesmo antes de ser enviado ao servidor.
Como outras ferramentas do gênero pode deixar no log do servidor
o seu UserAgent, desde que não seja modificado pelo analista/hacker.
OSTENSIVO 5-153
Ferramentas
BurpSuite
Semelhante ao Webscarab, mas com mais recursos, o BurpSuite

permite capturar as requisições HTTP para análise e modificação.
Possui uma versão pública e uma comercial. A segunda possui
capacidades de exploração de aplicações de forma automatizada.
OSTENSIVO 5-154
Ferramentas
Guyère
Uma aplicação do Google que serve como laboratório para testes

de segurança Web. Excelente Sandbox para testes com XSS
OSTENSIVO 5-155
Ferramentas
SQL Map
A mais popular ferramenta do gênero, o SQLMap automatiza o

processo em detectar e explorar aplicações com falhas de SQL Injection,
permitindo obter acesso integral ao banco de dados ou executar outras funções
no servidor alvo.
OSTENSIVO 5-156
Ferramentas
ModSecurity
MosSecurity é um Web Application Firewall (WAF), disponível para

Apache e Microsoft IIS. Os principais recursos desta ferramenta são:
• Melhorias no seu sistema de Log, mais adequado para aplicações web;
• Monitoramento em tempo real e deteção de ataques;
• Prevenção de ataques conhecidos;
• Funciona como componente integrado do servidor Web, melhorando sua
performance; e
• Capaz em defender o apache HTTP server contra ataques de DoS na camada
7 (aos quais o Microsft IIS é imune).
OSTENSIVO 5-157
Ferramentas
Pirni
O pirni é uma ferramenta tipo packet sniffer para dispositivos

móveis baseados em iOS, ou seja, iPhone, iPad, etc. Captura todos os pacotes
trafegados no dispositivo, todas as conexões realizadas. Não tem um
mecanismo para visualizar os pacotes, porém. Recomendamos utilizar o
WireShark ou outro sniffer para visualizar os pacotes.
OSTENSIVO 5-158
Ferramentas
DisAid
O diskaid é fundamental para a depuração e coleta de informações

em dispositivos móveis baseados em iOS. Permite abrir o dispositivo na forma
diretório e acessar todas as informações sem as limitações impostas pela
segurança do iOS. É o pacote mais completo que não requer a quebra da
validação do iOS (jailbreak).
OSTENSIVO 5-159
OSTENSIVO
Acunetix
O acunetix permite a execução de um conjunto de ataques mais

comuns em aplicações Web, testando todos os campos da aplicação por SQL
Injection, Code Injection e demais formas de entradas ilegais. Funciona de forma
bastante automatizada, mas é recomendável passar primeiro pelas telas de login
de forma manual e, só depois, liberar o sistema para ataque. Note que numa
aplicação grande, rodando todos os testes, pode levar até um dia inteiro para
executar.
OSTENSIVO 160
A ferramenta da IBM faz os testes similares aos do Acunetix, ou seja, o teste de invasão
e também possui um módulo próprio para a inspeção de código, porém limitada a duas
linguagens: Java e PHP. O fato de não tratar a plataforma .NET nem outras linguagens
acaba por dificultar seu uso amplo. Deve-se considerar ainda que a ferramenta requer a
compilação do programa pela mesma. Isso torna o teste independente mais complexo
de se realizar.
www.modulo.com 161
WebInspect da HP era uma ferramenta limitada, porém com a aquisição pela HP da

Fortify, imagina-se que as próximas versões devem incluir melhorias significativas. A
aplicação da HP realiza testes caixa preta (dinâmicos) e inspeção de código em cinco
linguagens, inclusive C#, Java e PHP.
www.modulo.com 162
Ferramentas
Safeval
O Safeval é um sistema de inspeção de código fonte. Identifica

fragilidades no código fonte da aplicação, locais com potencial para ataques e,
muito importante, identifica código malicioso colocado pelo desenvolvedor. Requer
a revisão manual dos pontos encontrados visto que, como todas as demais
ferramentas de inspeção de código, seu trabalho limita-se a apontar áreas
possivelmente vulneráveis. Se usado diretamente, gera grande número de falsos
positivos. Funciona em diversas linguagens e plataformas e possui uma parte web
para gestão dos problemas de segurança.
OSTENSIVO 5-163

Unidade de Ensino - 5 - V25NOV2014

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Unidade de Ensino - 5 - V25NOV2014

Título original:

Enviado por

Direitos autorais:

OSTENSIVO GUIA DE ESTUDO

Nesta unidade conheceremos:

• As principais definições em Segurança em Aplicações;

Na parte inicial desta matéria, vamos rever alguns conceitos

Todos os ícones do seu computador são aplicações que foram

Vamos ver as principais etapas deste processo de desenvolvimento

Vamos ver ainda os principais tipos e arquiteturas de aplicações.

Finalmente, vamos focar na arquitetura Web, visto ser amplamente

O que é uma aplicação?

Tipicamente uma aplicação é uma ferramenta de auxilio a algum

Uma aplicação geralmente vem automatizar um processo que já

Isso é importante para a segurança porque ao entender o processo

Toda aplicação é uma mudança

Um dos aspectos relevantes para a segurança é que a implementação

Nunca faça o deploy de um novo sistema as vésperas de um evento

Toda aplicação é uma mudança

Muitas pessoas normalmente bastante cientes da necessidade de

Uma aplicação sempre terá muitas versões. Assim, numa organização

Evite estrear novas tecnologias e novos sistemas, quando a segurança estiver

Como a criação de aplicações para auxílio nas mais diversas

A criação de aplicações para as mais diversas áreas leva, claro a

Outras falhas também custos enormes. Destaca-se a falha na

Porque existem erros e falhas de segurança em aplicações? Em

• Levantamento inicial, visando identificar o que a aplicação precisa conter, qual

Computadores são máquinas extremamente limitadas. De fato, só

Na compilação, após a criação do código fonte, ocorre uma fase de

A interpretação consiste em um programa próprio que entende

A linguagem compilada é rápida e pouco flexível. A linguagem

O código intermediário é muito mais próximo do código de máquina

Um código fonte compilado gera um executável que, mesmo que o

Um código intermediário pode ser traduzido de volta no código

Uma forma de minimizar essa possibilidade é a assinatura de

Para entendermos melhor essa questão da fragilidade do código de

Toda aplicação conta com três elementos principais:

• A camada de dados, onde estão armazenadas as informações do sistema,

Geralmente o atacante tem pouco interesse na camada de interface.

Toda aplicação conta com três elementos principais:

• A camada de dados, onde estão armazenadas as informações do sistema,

A forma como esses elementos são agrupados é que define a

Outro tipo clássico de arquitetura são as aplicações standalone ou

As aplicações mais modernas são construídas em 3 ou mais

Segurança das Aplicações Web

Embora a arquitetura Web seja apenas uma das arquiteturas de

Nos primeiros dias da Internet, a World Wide Web consistia apenas

A chamada poderia passar algumas informações, sendo que o

A requisição do comando GET contém, na primeira linha, o nome do comando, a página

Outros identificam o navegador de origem da requisição. O exemplo acima mostra a

Existem outros headers para controle de caches e otimização da mensagem e,

A primeira linha indica a versão do protocolo, um código de status, seguindo o padrão

Em seguida o servidor manda outros pares header: valor passando parâmetros

Finalmente o servidor define ou altera cookies e também fornece algumas informações

O SSL se tornou o padrão de facto da criptografia Internet, pois permite

Note que o esquema mostrado acima é apenas uma

Embora esta proteção seja muito boa, ainda é suscetível a man-in-

Importante notar também que a URL e todas a linha do comando

Da mesma forma que no caso anterior, note que o esquema

A OWASP (Open Web Application Security Project) é um projeto

Para maiores informações sobre a OWASP: https://www.owasp.org

Injeção de comandos é um ataque muito comum em várias

Mas comandos de Injection não requerem SQL nem ambiente

Vamos ver em maiores detalhes agora alguns dos principais ataques de

SQL Injection (2)

O que é exatamente o que faz o código acima. Busca todos os registros

SQL Injection – sem ‘ (plic)

Um exemplo de SQL Injection que não requer ‘ (plic), por exemplo,