Você está na página 1de 131

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 GUIA DE ESTUDO

OSTENSIVO 5-2
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

Requisição HTTP

Existem dois tipos de mensagens HTTP: request, response


HTTP request message:
• ASCII (formato legível para humanos)

OSTENSIVO 5-29
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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 GUIA DE ESTUDO

OSTENSIVO 5-34
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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 GUIA DE ESTUDO

OSTENSIVO 5-77
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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
OSTENSIVO GUIA DE ESTUDO

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