Unidade de Ensino - 5 - V10SET2013

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
Internet 2.0 e aplicações dinâmicas
Os primeiros sites possuíam apenas hyper-texto (Apenas HTML),

possuindo limitada funcionalidade. Contudo estes sites (hoje chamados de sites
estáticos) possuem uma superfície de ataque muito menor (apenas
vulnerabilidades no servidor ou HTTP server podem ser exploradas)
Com o tempo foram criados meios de haver aplicações e códigos

dinâmicos nas páginas. Um dos primeiros foram os scripts CGI (Common Gate
Interface). Posteriormente, outras funcionalidades surgiram com os mesmos
objetivos, como os JSP (Java Server Pages), ASP (Active Server Pages) e PHP
(Personal Home Page)
Com as funcionalidades novas dos códigos dinâmicos vieram também

vulnerabilidades, aumentando a superfície de ataque para os hackers.
OSTENSIVO 5-20
Fatores de sucesso para web apps
Antes das aplicações WEB, criar uma aplicação era apenas uma
das etapas para torná-la operacional. Era necessário ainda distribuí-la e mantê-
la atualizada. Ambas as tarefas podem simplesmente tornar impraticável
determinado uso de um sistema de informação.
Algumas das características que tornaram as aplicações WEB
populares foram:
• O protocolo HTTP, leve e não-orientado à conexão;

• A ampla disponibilidade de browsers em diferentes plataformas (aplicações
podem ser usadas em qualquer plataforma);
• O rico conjunto de funcionalidades provido pela maioria dos browsers;
• A crescente simplicidade em se desenvolver para a Web; e
• Exposição dos sistemas back-end que as alimentam e de seus dados reduzida
(apenas a aplicação fica exposta).
Tendo como base estas características algumas aplicações

surgem, sendo apenas viáveis se forem WEB, tais como comercio eletrônico e
on line banking.
OSTENSIVO 5-21
Aplicações Web
As aplicações Web porém compartilham muito mais que uma

plataforma dinâmica e de fácil uso. A criação de interfaces entre aplicações
conhecidas como Web Services permite que diversas aplicações trabalhem em
conjunto. Hoje muitas aplicações buscam dados e informações em outras,
gerando inúmeras possibilidades.
Um WebService pode ser entendido como uma página web que é

feita não para um usuário, mas para um outro sistema ler as informações. Um
sistema que precise, por exemplo, descobrir o CEP de uma rua, pode chamar um
WebService apropriado dos correios, fornecendo o nome da Rua. Este
WebService irá retornar o CEP em um padrão fácil de entender.
Se, por um lado, esse tipo de ligação entre aplicações permite

muitas funcionalidades novas, traz também novos riscos para a segurança: seu
sistema passa a depender de outro. Portanto, em sistemas críticos, deve ser
evitada a dependência de aplicações externas, sob risco de diminuir a
disponibilidade do sistema.
OSTENSIVO 5-22
Aplicações web e Criptografia
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.
OSTENSIVO 5-23
Visão Geral do HTTP
HTTP (hypertext transfer protocol)

O protocolo HTTP é baseado em requisição/resposta usando um
transporte confiável, normalmente TCP. É um protocolo da camada de aplicação da
Web, no modelo cliente/servidor:
• Cliente: browser que solicita, recebe e apresenta objetos da Web;e

• Servidor: envia objetos em resposta a pedidos.
HTTP 1.0: RFC 1945 e HTTP 1.1: RFC 2068
A página Web consiste de objetos. Objeto pode ser um arquivo HTML,

imagem JPEG, Java applet, arquivo de áudio,…Ela consiste de arquivo-HTML base
que inclui vários objetos referenciados e cada objeto é endereçado por uma URL
(Uniform Resource Locator)
OSTENSIVO 5-24
Visão Geral do HTTP
Conexões HTTP
HTTP não persistente:
• No máximo, um objeto é enviado sobre uma conexão TCP; e
• O HTTP/1.0 utiliza HTTP não persistente.
HTTP persistente:
• Múltiplos objetos podem ser enviados sobre uma conexão;
• TCP entre o cliente e o servidor;e
• O HTTP/1.1 utiliza conexões persistentes em seu modo padrão.
Uniform Resource Indicators (URI)

É o endereço de um recurso e inclui informações de como recuperá-lo.
O termo URL é usado como sinônimo pela maioria dos profissionais.
Formato de um URI :
Protocolo://[usuario:senha@]host.dominio[:porta]/recurso?parametro=valor
Exemplo: Considerando o URI http://www.test.com.br/index.php?id=43
- http é o protocolo;
- www.teste.com.br é o host e domínio;
- Index.php é o recurso;
- Id é o parâmetro;e
- 42 é o valor para o parâmetro id.
OSTENSIVO 5-25
Conceitos HTTP
O HTTP/1.0 - só provê autenticação básica, Controle desafio-resposta e NÃO

usa criptografia, mas apenas base64 encoding.
O HTTP/1.1 - introduziu o uso da Digest Access Authentication. A resposta

passa a ser um checksum (MD5) do usuário, senha, um OTP e a URL
requisitada.
User-Agent – Clientes web são considerados os User-agents. Cada web

browser possui seu código de User Agent. A informação do tipo de User-Agent é
registrada no log do servidor WEB. Esta informação pode ajudar a determinar,
por exemplo, se a aplicação está sendo estudada ou explorada por um hacker.
Contudo, este item pode ser alterado para enganar os sistemas de IDS na rede.
OSTENSIVO 5-26
Métodos HTTP
Os métodos disponíveis no protocolo HTTP são:
• GET – Faz uma requisição a um recurso;

• POST – Faz requisições de recursos, incluindo os parâmetros da requisição no
payload do pacote;
• HEAD – Apenas retorna os headers HTTP do servidor;
• TRACE – Permite ver como a requisição feita é vista pelo servidor;
• OPTIONS – Pergunta ao servidor quais métodos ele suporta;
• CONNECT – Cria um túnel HTTP para as requisições (usado quando há um
proxy envolvido na comunicação);
• PUT – Faz upload de um dado para o local apontado na URL;e
• DELETE – Remove o recurso apontado na URL.
OSTENSIVO 5-27
Código de erros HTTP
O Protocolo HTTP tem definido códigos de erro padrão, permitindo

facilitar o diagnóstico. Ele ajuda o administador do servidor a debugar
problemas, mas também pode ajudar o atacante a debugar o seu ataque.
São 5 as classes de códigos de erros:
•1xx – Informacional
•100 - Continue
•2xx – Sucesso
•200 - Ok
•3xx – Redicionado
•302 – Redirect
•304 – Not Modified
•4xx – Erro no cliente
•401 – Unauthorized
•404 – File not found
•5xx – Erro no Servidor
•500 – Server error
•502 – Bad gateway
Uma boa prática é não permitir que um servidor retorne estes códigos
de erro em aplicações já em produção. Em ambientes de desenvolvimento e
homologação é importante que estas opções estejam disponíveis.
OSTENSIVO 5-28
Requisição HTTP
Existem dois tipos de mensagens HTTP: request, response

HTTP request message:
• ASCII (formato legível para humanos)
OSTENSIVO 5-29
Estrutura de requisição HTTP
Na linha de requisição encontramos as informações sobre o

método, URL e versão. Ex: GET /index.html HTTP/1.1.
Nas linhas de cabeçalho encontramos algumas informações

importantes da comunicação. Ex: Host: www.test.com.br.
A linha em branco fecha o cabeçalho.
Nas linhas do Corpo da Entidade estão contidos os dados

tramitados na comunicação.
OSTENSIVO 5-30
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-31
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-32
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-33
OSTENSIVO 5-34
A4.Insecure object reference
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...
OSTENSIVO 5-35
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-36
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-37
A7. Missing access control
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.
OSTENSIVO 5-38
A8. CSRF – Request forgery
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. Esse código executa na
máquina dele e acessa, com o cookie de sessão dele, um outro serviço ou
aplicativo, como se fosse o usuário. Por exemplo, muitos usuários utilizam a
mesma senha para muitos sistemas, a credencial para o paypal pode ser a
mesma do facebook. Um aplicativo vulnerável pode roubar as credenciais de
autenticação e utilizar em outro sistema.
OSTENSIVO 5-39
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-40
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-41
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-42
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-43
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-44
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-45
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-46
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-47
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-48
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-49
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-50
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-51
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-52
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-53
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-54
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.
OSTENSIVO 5-55
SQL Injection – Hibernate
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 dados de entrada.
OSTENSIVO 5-56
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-57
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-58
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-59
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-60
XSS – Cross Site Scripting
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).
OSTENSIVO 5-61
System Code Injection
Embora os ataques Injection sejam muito comuns em aplicações

Web, é importante notar que não se trata de uma exclusividade. Conforme
explicamos no tópico sobre injeção. Qualquer aplicação que monte um comando
para um outro sistema, utilizando informações passadas pelo usuário, pode estar
sujeito a esse tipo de ataque.
O caso acima mostra uma injeção de código em aplicação cliente

servidor, em um comando que é montado e depois passado para a execução pelo
sistema operacional. Existem diversos outros tipos de injeção:
• CICS
• XML
• Etc.
Em todos eles caracteres especiais são usados. Assim, a regra

principal para evitar ataques é: cada campo deve aceitar apenas os caracteres
estritamente necessários.
Muitos firewalls de aplicação previnem vários tipos de ataque, mas,
tal como explicado para o SQL Injection, a prevenção deve incluir todo o
desenvolvimento.
OSTENSIVO 5-62
Enumeração de Páginas
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.
OSTENSIVO 5-63
Enumeração de Páginas
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.
OSTENSIVO 5-64
Ataques mais comuns
Alteração de parâmetros
Este ataque consiste em usar um proxy para fazer alteração em

parâmetros ocultos, os quais ficam escondidos como forma de segurança
destes. Modificar este parâmetro oculto irá causar a alteração de comportamento
da aplicação web de acordo com os dados inseridos.
Pode causar roubo de informações, roubo de seções e escalagem

de privilégios. Nos exemplos da figura, parâmetros legítimos são substítuidos por
comandos (view e delete), eventualmente causando alteração no funcionamento
da aplicação. Contramedida: Checagem de validade nos campos.
OSTENSIVO 5-65
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-66
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-67
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-68
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-69
Ataques mais comuns
Directory Transversal
Este ataque ocorre quando o hacker é capaz de navegar pela

estrutura de diretórios além do padrão daquela aplicação. Pode expor a estrutura
de arquivos do servidor que hospeda a página e pemitir ao atacante obter
informações confidenciais armazenadas naquele host.
Contramedidas:
• Definir de forma correta os direitos nas pastas do servidor Web;

• Aplicar correções que previnam a exploração da vulnerabilidade no sistema;e
• Princípio do mínimo privilégio: Servidor web estar rodando com um usuário
limitado pode auxiliar a impedir acessos via este ataque.
OSTENSIVO 5-70
Ataques mais comuns
Remote File Include
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
OSTENSIVO 5-71
Ataques mais comuns
Remote File Include
Contramedidas
• Checagem rigorosa no código de páginas para remover parâmetros

que possam ser usados para redirecionar o servidor a buscar arquivos
em outros hosts; e
Há um variante deste ataque, quando o hacker usa as mesmas
técnicas para obter ou executar um arquivo que está local no servidor
que hospeda a página vulnerável. A este ataque se dá o nome de Local
File Include (LFI)
OSTENSIVO 5-72
Ataques mais comuns
Envenenamento de Cookie e Seção
Cookies são usados para manter estado de seções HTTP, pois este não
é um protocolo orientado a seções. O envenenamento permite que um atacante
insira um conteúdo malicioso, moficando a experiência on-line do usuário e
assim obtendo acesso a informação não autorizada.
Um proxy pode ser usado para re-escrever dados de seção,
mostrando os dados em um cookie e especificando um novo ID de usuário, por
exemplo.
Contramedidas:
• Não armazenar senhas em texto claro ou com cifras fracas em cookies;
• Implementar limite de tempo para cookies;
• As credenciais de autenticação de cookies devem ser associadas com os
endereços IP; e
• Habilitar funções de logout nas aplicações.
OSTENSIVO 5-73
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-74
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-75
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-76
OSTENSIVO 5-77
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-78
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-79
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-80
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-81
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-82
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-83
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-84
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-85
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-86
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-87
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-88
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-89
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-90
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-91
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-92
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-93
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-94
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-95
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-96
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-97
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-98
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-99
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-100
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-101
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-102
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-103
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-104
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-105
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-106
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-107
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-108
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-109
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-110
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-111
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-112
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-113
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-114
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-115
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-116
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-117
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-118
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-119
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-120
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-121
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-122
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-123
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-124
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-125
Ferramentas
Web Server Log
Log de servidores Web podem trazer informações importantes

sobre as eventuais ações maliciosas de um atacante. Podemos encontrar no log:
• Tentativas de escaneamento com ferramentas automatizadas (identificação
através do useragent
• Tentativas de ataques mais comuns (Directory Transversal, tentativas em
acessar arquivos internos, executar um shell)
Uma boa prática é sempre análisar os logs em servidores web nos
primeiros indícios de uma atividade maliciosa, permitindo descobrir mais
rapidamente o que efetivamente está acontecendo.
OSTENSIVO 5-126
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-127
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-128
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-129
Ferramentas
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 5-130
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-131

Unidade de Ensino - 5 - V10SET2013

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Unidade de Ensino - 5 - V10SET2013

Enviado por

Direitos autorais:

Formatos disponíveis

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

Internet 2.0 e aplicações dinâmicas

Os primeiros sites possuíam apenas hyper-texto (Apenas HTML),

Com o tempo foram criados meios de haver aplicações e códigos

Com as funcionalidades novas dos códigos dinâmicos vieram também

Fatores de sucesso para web apps

• O protocolo HTTP, leve e não-orientado à conexão;

Tendo como base estas características algumas aplicações

As aplicações Web porém compartilham muito mais que uma

Um WebService pode ser entendido como uma página web que é

Se, por um lado, esse tipo de ligação entre aplicações permite

Aplicações web e Criptografia

O protoclo HTTP (Hyper Text Transfer Protocol) não possui capacidades

Para resolver este problema foi criado, pela Netscape, o protocolo

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

Visão Geral do HTTP

HTTP (hypertext transfer protocol)

• Cliente: browser que solicita, recebe e apresenta objetos da Web;e

HTTP 1.0: RFC 1945 e HTTP 1.1: RFC 2068

A página Web consiste de objetos. Objeto pode ser um arquivo HTML,