OWASP e o desenvolvimentoseguro de aplicações para a Web        ISELTech’12                                       2012.05....
@pontocomcarlos.serrao@iscte.ptcarlos.j.serrao@iscte.pthttp://www.linkedin.com/in/carlosserrao
“We wouldn’t have to spend so much             time,money, and effort on network security if we didn’t have such bad softw...
Segurança de Software
Segurança de Software• o software é ubíquo
Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa  vida
Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa  vida• funções críticas ...
Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa  vida• funções críticas ...
Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa  vida• funções críticas ...
Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa  vida• funções críticas ...
Problema no software• Características do software actual    • Complexidade         • Ataques exploram bugs designados por ...
WhiteHat Security, Website Security Statistics Report, Winter 2011
Vulnerabilidades                                                            Específicas                        cífic       a...
Tipologia de um ataque aplicacional                                              Network Layer                            ...
Tipologia de um ataque aplicacional                                              Network Layer                            ...
Tipologia de um ataque aplicacional                                              Network Layer                            ...
Tipologia de um ataque aplicacional                                              Network Layer                            ...
Citigroup attack...                      ...information accessed on                            360,069 accounts
Top 10, anyone?...                                     Attack vector      http://www.owasp.org/index.php/Top_10
2011 CWE/SANS Top 25 Most DangerousSoftware Errors 1. Improper Neutralization of Special Elements used in           13.Imp...
2011 CWE/SANS Top 25 Most DangerousSoftware Errors 1. Improper Neutralization of Special Elements used in           13.Imp...
Sony attacks               http://attrition.org/security/rants/sony_aka_sownage.html
Sony attacks                 “Several of Sonys sites have been               compromised as a result of basic SQL         ...
Sony attacks                 “Several of Sonys sites have been               compromised as a result of basic SQL         ...
https://www.dges.mctes.pt/wwwReportViewer/ReportViewer.aspx?Report=/RelatoriosBolsas/Autorizacao_ST&CandidatoID=XXXXXX&Can...
https://www.dges.mctes.pt/wwwReportViewer/ReportViewer.aspx?Report=/RelatoriosBolsas/Autorizacao_ST&CandidatoID=XXXXXX&Can...
SQL injection #101
Contexto• Falta de percepção da  segurança   • as (algumas) organizações não     investem o suficiente em     segurança (ou...
Motivação/ContextoTendênciasCisco para   2011
Motivação/Contexto      Número médio de vulnerabilidades sérias encontradas        em WebApps por sector (fonte: WhiteHat,...
Motivação/Contexto   Percentagem de ocorrência de problemas de segurança em              WebApps (fonte: WhiteHat, 2011)
Motivação/Contexto
Motivação/Contexto   Gartner	  Group	  (2009)              IBM	  (2009)                                              Outro...
... an open community dedicated to enabling    organizations to develop, purchase, and   maintain applications that can be...
OWASP?• Open Web Application Security Project   • Promove o desenvolvimento seguro de software   • Orientado para o desenv...
OWASP?• Open Web Application Security Project     • Organização sem fins lucrativos, orientada para esforço voluntário     ...
OWASP
OWASP
OWASP?
OWASP?• Top 10 Web Application Security Risks/Vulnerabilities    • Uma lista dos 10 aspectos de segurança mais críticos   ...
OWASP?    http://www.owasp.org/index.php/Top_10
OWASP
OWASP SUMMIT 2011
Ataques contra WebApps
Ataques• Ataques contra a infra-estrutura• Ataques contra a aplicação• Ataques contra os utilizadores• Outros ataques
Ataques parse input          escape output
Ataques contra a infra-estrutura      atacar a camada mais fraca
Aplicação WebServidor Aplicacional Servidor WebSistema OperativoDispositivos de Rede
Aplicação Web                                                       Servidor Aplicacional                                 ...
Aplicação Web                                                 Servidor Aplicacional                                       ...
Aplicação Web                                                   Servidor AplicacionalTodos os scripts desnecessários foram...
Aplicação WebTodas as aplicações de demonstração foram                 removidas?                   Servidor Aplicacional ...
Aplicação WebE aqui????             Servidor Aplicacional              Servidor Web             Sistema Operativo         ...
o seu sistema será tão seguro quanto a segurança do elo         mais fraco...                         ©"Darwin"Bell@flickr"
A6: Configuração de Segurança Incorrecta• Qual é o Risco?     • Se existir um elo mais fraco do que a própria aplicação Web...
Ataques contra a aplicação    injectar código hostil...
e se?....
e se?....            SELECT * FROM users usr        WHERE usr.username = ‘admin’;--’                     ANDusr.password=’...
e se?....
qualquer input do utilizador pode serum vector de ataque
A1: Injecção• Risco?  • Qualquer ponto de entrada da aplicação pode ser usada    como vector para injectar conteúdo hostil...
A1: Injecção• CONTRA-MEDIDAS  • Todas as entradas/input pode ser modificado do lado do cliente. É necessário    validar:   ...
A1: Injecção• CONTRA-MEDIDAS    •   NUNCA copiar o input do utilizador directamente para comandos de query (SQL, Xpath, LD...
A1: Injecção• CONTRA-MEDIDAS   • escolher a melhor estratégia de validação   • melhor: whitelist       • quando todos os v...
Ataques contra a aplicação brincar com identificadores óbvios...
e se?....                                            •     um atacante repara que o                                       ...
A4: Referências Directas a Objectos Inseguras• Qual é risco?    • Todas as referências podem ser modificadas do lado do cli...
Ataques contra a aplicaçãoquebrar os mecanismos de sessão        e de autenticação
e se?....
e se?....
e se?....
1    Utilizador envia credenciais                                                                                         ...
A3: Quebra da Autenticação e da Gestão deSessões• Qual o risco?    • o HTTP é um protocolo stateless. Cada pedido deve tra...
A3: Quebra da Autenticação e da Gestão deSessões• Quais as contra-medidas?   • ter a certeza que o ‘logout’ destrói efecti...
Ataques contra a aplicaçãoencontrar URLs “secretas” escondidas
e se?....
e se?....
e se?....            • um atacante repara que a              URL indica qual o seu papel                 /user/getAccounts...
A7: Falhas na Restrição de Acesso a URL• Qual o risco?    • URLs que conduzem a recursos confidenciais podem ser facilmente...
Ataques contra os utilizadoresredireccionar os utilizadores para outro lado...
e se?....
Atacante envia um ataque para a vítima através de um                      email ou página Web                      From: I...
A8: Redirecionamentos e Encaminhamentos não-Validados• Qual o risco?    • Um atacante pode usar a reputação do seu site de...
Evitar o A8• Existem diversas opções    • Evitar usar redirecionamentos e encaminhamentos sempre que puder    • Se usar, n...
Ataques contra os utilizadores  executar código hostil do cliente         no site de web...
e se?....
e se?....
XSS        1   Atacante monta a armadilha – actualizando o seu perfil                                                     ...
A2: Cross Site Scripting (XSS)• Qual o risco?     • Um atacante pode injectar código hostil a partir do lado do cliente na...
Ataques contra os utilizadores replicar e repetir pedidos previsíveis
e se?....
e se?....
Alice                 transferir 100€ para o                Bob                                   Bob através do bank.com ...
A5: Cross Site Request Forgery (CSRF)• Qual o risco?    • Um atacante pode construir o seu próprio site de web e iniciar p...
Outros ataquesquebrar criptografia fraca...
A9: Armazenamento Criptográfico Inseguro• Qual o risco?     • Um atacante pode não necessitar de tanto tempo como pode espe...
Evitar o A9•   Verifique a sua arquitectura        •   identificar todos os dados sensíveis        •   identificar todos os p...
Outros ataquesobservar o ambiente...
e se?....
A10: Protecção Insuficiente da Camada deTransporte• Qual é o risco?   • Visualização do tráfego, devido a insuficiente prote...
Evitar o A10• Protecção com os mecanismos adequados        •   usar o TLS em todas as ligações com dados sensíveis        ...
OWASP Top 10
OWASP Top 10 (2010)• A1: Injecção• A2: Cross Site Scripting (XSS)• A3: Quebra de Autenticação e da Gestão de Sessões• A4: ...
Riscos no OWASP Top 10        RISCO              Agentes                                               	  	  	  	  Vectore...
O “novo” Top 10 da OWASP (2010)                    http://www.owasp.org/index.php/Top_10
@pontocomcarlos.serrao@iscte.ptcarlos.j.serrao@iscte.pthttp://www.linkedin.com/in/carlosserrao
OWASP e o desenvolvimentoseguro de aplicações para a Web        ISELTech’12                                       2012.05....
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
OWASP e o desenvolvimento seguro de aplicações para a Web
Upcoming SlideShare
Loading in …5
×

OWASP e o desenvolvimento seguro de aplicações para a Web

3,670 views

Published on

Presentation made for ISELTech'12.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,670
On SlideShare
0
From Embeds
0
Number of Embeds
834
Actions
Shares
0
Downloads
79
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

OWASP e o desenvolvimento seguro de aplicações para a Web

  1. 1. OWASP e o desenvolvimentoseguro de aplicações para a Web ISELTech’12 2012.05.23 Carlos Serrão
  2. 2. @pontocomcarlos.serrao@iscte.ptcarlos.j.serrao@iscte.pthttp://www.linkedin.com/in/carlosserrao
  3. 3. “We wouldn’t have to spend so much time,money, and effort on network security if we didn’t have such bad software security” Viega & McGraw, Building Secure Software, Addison Wesley
  4. 4. Segurança de Software
  5. 5. Segurança de Software• o software é ubíquo
  6. 6. Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa vida
  7. 7. Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa vida• funções críticas de negócio dependem de software
  8. 8. Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa vida• funções críticas de negócio dependem de software• software está cada vez mais exposto à Internet
  9. 9. Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa vida• funções críticas de negócio dependem de software• software está cada vez mais exposto à Internet• exposição aumentada torna o software visível para terceiros
  10. 10. Segurança de Software• o software é ubíquo• dependemos do software nos diversos aspectos da nossa vida• funções críticas de negócio dependem de software• software está cada vez mais exposto à Internet• exposição aumentada torna o software visível para terceiros• nem todas as pessoas são bem intencionadas
  11. 11. Problema no software• Características do software actual • Complexidade • Ataques exploram bugs designados por vulnerabilidades • Estima-se entre 5-50 bugs por 1000 linhas de código • Windows XP 40 milhões de linhas de código • Extensibilidade • O que é o software nos nossos computadores? SO + software em produção + patches + 3rd party DLLs + device drivers + plugins + .... • Conectividade • Internet (1+ biliões de utilizadores) + sistemas de controlo + PDAs + telemóveis + ...
  12. 12. WhiteHat Security, Website Security Statistics Report, Winter 2011
  13. 13. Vulnerabilidades Específicas cífic as Web espeA p licações s Web standard e Aplicaçõ eb Se rvidor W Vulnerabilidades conhecidas e s documentadas Base de Dado e s Aplicaçõ ra tivo Siste ma Ope Rede WhiteHat Security, Website Security Statistics Report, Winter 2011
  14. 14. Tipologia de um ataque aplicacional Network Layer OS Layer Application Network Layer Layer OS Layer Custom Back-end Application Application Database Layer (End-user Application Traffic interface)
  15. 15. Tipologia de um ataque aplicacional Network Layer OS Layer Application Network Layer Layer OS Layer Custom Back-end Application Application Database Layer (End-user Application Traffic interface)
  16. 16. Tipologia de um ataque aplicacional Network Layer OS Layer Application Network Layer Layer OS Layer Custom Back-end Application Application Database Layer (End-user Application Traffic interface)
  17. 17. Tipologia de um ataque aplicacional Network Layer OS Layer Application Network Layer Layer OS Layer Custom Back-end Application Application Database Layer (End-user Application Traffic interface)
  18. 18. Citigroup attack... ...information accessed on 360,069 accounts
  19. 19. Top 10, anyone?... Attack vector http://www.owasp.org/index.php/Top_10
  20. 20. 2011 CWE/SANS Top 25 Most DangerousSoftware Errors 1. Improper Neutralization of Special Elements used in 13.Improper Limitation of a Pathname to a an SQL Command (SQL Injection) Restricted Directory (Path Traversal) 2. Improper Neutralization of Special Elements used in 14.Download of Code Without Integrity Check an OS Command (OS Command Injection) 15.Incorrect Authorization 3. Buffer Copy without Checking Size of Input (Classic 16.Inclusion of Functionality from Untrusted Buffer Overflow) Control Sphere 4. Improper Neutralization of Input During Web Page 17.Incorrect Permission Assignment for Generation (Cross-site Scripting) Critical Resource 5. Missing Authentication for Critical Function 18.Use of Potentially Dangerous Function 19.Use of a Broken or Risky Cryptographic 6. Missing Authorization Algorithm 7. Use of Hard-coded Credentials 20.Incorrect Calculation of Buffer Size 21.Improper Restriction of Excessive 8. Missing Encryption of Sensitive Data Authentication Attempts 9. Unrestricted Upload of File with Dangerous Type 22.URL Redirection to Untrusted Site (Open Redirect) 10. Reliance on Untrusted Inputs in a Security Decision 23.Uncontrolled Format String 11. Execution with Unnecessary Privileges 24.Integer Overflow or Wraparound 12. Cross-Site Request Forgery (CSRF) 25.Use of a One-Way Hash without a Salt 29 June 2011, http://cwe.mitre.org/top25/
  21. 21. 2011 CWE/SANS Top 25 Most DangerousSoftware Errors 1. Improper Neutralization of Special Elements used in 13.Improper Limitation of a Pathname to a an SQL Command (SQL Injection) Restricted Directory (Path Traversal) 2. Improper Neutralization of Special Elements used in 14.Download of Code Without Integrity Check an OS Command (OS Command Injection) 15.Incorrect Authorization 3. Buffer Copy without Checking Size of Input (Classic 16.Inclusion of Functionality from Untrusted Buffer Overflow) Control Sphere 4. Improper Neutralization of Input During Web Page 17.Incorrect Permission Assignment for Generation (Cross-site Scripting) Critical Resource 5. Missing Authentication for Critical Function 18.Use of Potentially Dangerous Function 19.Use of a Broken or Risky Cryptographic 6. Missing Authorization Algorithm 7. Use of Hard-coded Credentials 20.Incorrect Calculation of Buffer Size 21.Improper Restriction of Excessive 8. Missing Encryption of Sensitive Data Authentication Attempts 9. Unrestricted Upload of File with Dangerous Type 22.URL Redirection to Untrusted Site (Open Redirect) 10. Reliance on Untrusted Inputs in a Security Decision 23.Uncontrolled Format String 11. Execution with Unnecessary Privileges 24.Integer Overflow or Wraparound 12. Cross-Site Request Forgery (CSRF) 25.Use of a One-Way Hash without a Salt 29 June 2011, http://cwe.mitre.org/top25/
  22. 22. Sony attacks http://attrition.org/security/rants/sony_aka_sownage.html
  23. 23. Sony attacks “Several of Sonys sites have been compromised as a result of basic SQL injection attacks, nothing elaborate or complex.” http://attrition.org/security/rants/sony_aka_sownage.html
  24. 24. Sony attacks “Several of Sonys sites have been compromised as a result of basic SQL injection attacks, nothing elaborate or complex.” http://attrition.org/security/rants/sony_aka_sownage.html
  25. 25. https://www.dges.mctes.pt/wwwReportViewer/ReportViewer.aspx?Report=/RelatoriosBolsas/Autorizacao_ST&CandidatoID=XXXXXX&CandidaturaID=XXXXXX
  26. 26. https://www.dges.mctes.pt/wwwReportViewer/ReportViewer.aspx?Report=/RelatoriosBolsas/Autorizacao_ST&CandidatoID=XXXXXX&CandidaturaID=XXXXXX
  27. 27. SQL injection #101
  28. 28. Contexto• Falta de percepção da segurança • as (algumas) organizações não investem o suficiente em segurança (ou investem incorretamente) • programadores não percebem os riscos de segurança (ou não podem ou querem perceber) • DISCLAIMER: não estou com isto a insinuar que *TODOS* os programadores são maus ;-)
  29. 29. Motivação/ContextoTendênciasCisco para 2011
  30. 30. Motivação/Contexto Número médio de vulnerabilidades sérias encontradas em WebApps por sector (fonte: WhiteHat, 2011)
  31. 31. Motivação/Contexto Percentagem de ocorrência de problemas de segurança em WebApps (fonte: WhiteHat, 2011)
  32. 32. Motivação/Contexto
  33. 33. Motivação/Contexto Gartner  Group  (2009) IBM  (2009) Outros Outros 10% 25% Aplicacional Sites  Web  Vulneráveis 75% 90% WASC  (2009) Outros Outros 15% 22% Sites  Web  Vulneráveis 85% Fáceis  de  Explorar 78%
  34. 34. ... an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted
  35. 35. OWASP?• Open Web Application Security Project • Promove o desenvolvimento seguro de software • Orientado para o desenvolvimento de serviços baseados na web • Focado principalmente em aspectos de desenvolvimento do que em web-design • Um fórum aberto para discussão • Um recurso gratuito e livre para qualquer equipa de desenvolvimento
  36. 36. OWASP?• Open Web Application Security Project • Organização sem fins lucrativos, orientada para esforço voluntário • Todos os membros são voluntários • Todo o trabalho é “doado” por patrocinadores • Oferecer recursos livres para a comunidade • Publicações, Artigos, Normas • Software de Testes e de Formação • Chapters Locais & Mailing Lists • Suportada através de patrocínios • Suporte de empresas através de patrocínios financeiros ou de projectos • Patrocínios pessoais por parte dos membros
  37. 37. OWASP
  38. 38. OWASP
  39. 39. OWASP?
  40. 40. OWASP?• Top 10 Web Application Security Risks/Vulnerabilities • Uma lista dos 10 aspectos de segurança mais críticos • Actualizado numa base (quase) anual • Crescente aceitação pela indústria • Federal Trade Commission (US Gov) • US Defense Information Systems Agency • VISA (Cardholder Information Security Program)• Está a ser adoptado como um standard de segurança para aplicações web
  41. 41. OWASP? http://www.owasp.org/index.php/Top_10
  42. 42. OWASP
  43. 43. OWASP SUMMIT 2011
  44. 44. Ataques contra WebApps
  45. 45. Ataques• Ataques contra a infra-estrutura• Ataques contra a aplicação• Ataques contra os utilizadores• Outros ataques
  46. 46. Ataques parse input escape output
  47. 47. Ataques contra a infra-estrutura atacar a camada mais fraca
  48. 48. Aplicação WebServidor Aplicacional Servidor WebSistema OperativoDispositivos de Rede
  49. 49. Aplicação Web Servidor Aplicacional Servidor Web Sistema Operativo Estão todos caminhos desnecessários fechados? Dispositivos de Rede Estão todos os portos desnecessários fechados?Está o interface de administração acessível via web? Pode uma conta de administração ser quebrada? Está o dispositivo actualizado?
  50. 50. Aplicação Web Servidor Aplicacional Servidor Web Estão todos os serviços desnecessários desactivados? Sistema Operativo Estão todas as contas desnecessárias desactivadas?Todas as passwords de defeito foram alteradas? Está o sistema actualizado? Dispositivos de Rede
  51. 51. Aplicação Web Servidor AplicacionalTodos os scripts desnecessários foram removidos? Existem alguns recursos de backup/teste ainda Servidor Web disponíveis? Está o servidor de web actualizado? Foram alteradas todas as passwords por defeito? Sistema Operativo Dispositivos de Rede
  52. 52. Aplicação WebTodas as aplicações de demonstração foram removidas? Servidor Aplicacional Está o servidor actualizado? Está a parte de administração protegida de acesso externo? Indexação de directorias foi desactivada? Servidor Web Foram as passwords de defeito alteradas? Sistema Operativo Dispositivos de Rede
  53. 53. Aplicação WebE aqui???? Servidor Aplicacional Servidor Web Sistema Operativo Dispositivos de Rede
  54. 54. o seu sistema será tão seguro quanto a segurança do elo mais fraco... ©"Darwin"Bell@flickr"
  55. 55. A6: Configuração de Segurança Incorrecta• Qual é o Risco? • Se existir um elo mais fraco do que a própria aplicação Web, o atacante vai preferir atacar essa camada mais fraca• Quais são as principais contra-medidas? • Garantir a segurança de todas as camadas • Reduzir os serviços e contas ao mínimo • Não usar passwords por defeito • Ter tudo actualizado • Usar e aplicar as directrizes de segurança (segurança do SO, segurança do servidor Web, segurança do servidor aplicacional, etc.) • Manter a configuração por defeito da aplicação Web segura • “Funcionamento seguro numa arquitectura segura”
  56. 56. Ataques contra a aplicação injectar código hostil...
  57. 57. e se?....
  58. 58. e se?.... SELECT * FROM users usr WHERE usr.username = ‘admin’;--’ ANDusr.password=’bb21158c733229347bd4e681891e21 3d94c685be’
  59. 59. e se?....
  60. 60. qualquer input do utilizador pode serum vector de ataque
  61. 61. A1: Injecção• Risco? • Qualquer ponto de entrada da aplicação pode ser usada como vector para injectar conteúdo hostil para modificar o comportamento das mesmas• IMPORTANTE • Não afecta apenas o SQL • LDAP e XPath podem ser igualmente vulneráveis
  62. 62. A1: Injecção• CONTRA-MEDIDAS • Todas as entradas/input pode ser modificado do lado do cliente. É necessário validar: • Parâmetros das strings de query; • Campos dos formulários (incluindo os “hidden”) • Upload de Ficheiros: se se está à espera de uma imagem, é preciso ter a certeza que se recebe uma imagem!!!! • Cookies • HTTP Headers: todos os campos, incluindo o “referrer” são input do utilizador (e podem ser modificados)
  63. 63. A1: Injecção• CONTRA-MEDIDAS • NUNCA copiar o input do utilizador directamente para comandos de query (SQL, Xpath, LDAP, comandos do SO, etc.) • usar um modelo de ligação para parâmetros SQL: • se não existir um modelo de ligação, codificar o input antes de o usar: • usar aspas (“) no caso do SQL Server • pelicas com ‘’ (’) no caso do MySQL (no PHP, a função addslashes é bastante útil) • ...
  64. 64. A1: Injecção• CONTRA-MEDIDAS • escolher a melhor estratégia de validação • melhor: whitelist • quando todos os valores possíveis são conhecidos (enums, expressões if/else...if, expressões regulares, ...) • graylist • forçar as regras de negócio • tipo: string, numérico, byte, ... • intervalo: >0, <MaxInt, [a-z]{3,20} • mais fraco: blacklist if(input.IndexOf(“<script>”)>=0) // rejeitar
  65. 65. Ataques contra a aplicação brincar com identificadores óbvios...
  66. 66. e se?.... • um atacante repara que o parâmetro acct é 6065 ?acct=6065https://www.onlinebank.com/user?acct=6065 • modifica este valor para um valor próximo ?acct=6066 • atacante consegue ver a informação da conta da vítima
  67. 67. A4: Referências Directas a Objectos Inseguras• Qual é risco? • Todas as referências podem ser modificadas do lado do cliente. Um atacante pode conseguir obter acesso e/ou modificar informação confidencial• Quais as contra-medidas? • Nunca enviar referências internas para o browser: • Usar mapeamentos temporários e aleatórios (#0, #1, #2, #3, etc.) • OU combinar o acesso a referências com controlo de acesso: • SELECT * FROM item WHERE id = $id AND owner = $uID • UPDATE item … WHERE id = $id AND owner = $uid
  68. 68. Ataques contra a aplicaçãoquebrar os mecanismos de sessão e de autenticação
  69. 69. e se?....
  70. 70. e se?....
  71. 71. e se?....
  72. 72. 1 Utilizador envia credenciais Knowledge Mgmt Communication Administration Bus. Functions E-Commerce Transactions Accounts Finance www.site.com?JSESSIONID=9FA1DB9EA... Site usa URL rewriting 2 Custom Code (i.e., coloca sessão na URL) 3 Utilizador carrega num link para http://www.hacker.com num forum Hacker verificar os logs dos referers no www.hacker.com e encontra o JSESSIONID do utilizador 45 Hacker usa JSESSIONID e assume a identificação e a conta da vítima
  73. 73. A3: Quebra da Autenticação e da Gestão deSessões• Qual o risco? • o HTTP é um protocolo stateless. Cada pedido deve transmitir informação da sessão na rede • os mecanismos de autenticação são um dos alvos preferenciais dos atacantes, a vários níveis: formulários, tráfego, dados armazenados.• Quais as contra-medidas? • Usar mecanismos simples, normalizados e centralizados de sessões • usar atributos de segurança dos cookies (flag de segurança, flag HttpOnly, cifra e controlo de integridade) • validar os identificadores de sessão • o sessionID está a ser enviado do sítio certo?
  74. 74. A3: Quebra da Autenticação e da Gestão deSessões• Quais as contra-medidas? • ter a certeza que o ‘logout’ destrói efectivamente a sessão • prevenir ataques de força bruta, mas prevenir igualmente ataques de DoS em contas legítimas • forçar a recuperação segura de passwords • autenticar antes de efectuar o reset da password • rever, rever e rever manualmente o código da autenticação (e do logoff)
  75. 75. Ataques contra a aplicaçãoencontrar URLs “secretas” escondidas
  76. 76. e se?....
  77. 77. e se?....
  78. 78. e se?.... • um atacante repara que a URL indica qual o seu papel /user/getAccounts • modifica este valor para um papel diferente /admin/getAccounts /manager/getAccounts • atacante consegue ver mais contas do que a sua
  79. 79. A7: Falhas na Restrição de Acesso a URL• Qual o risco? • URLs que conduzem a recursos confidenciais podem ser facilmente enviadas, armazenadas (bookmarks), monitoradas (proxies, dispositivos de segurança) e algumas vezes adivinhadas• Quais as contra-medidas? • Desautorizar por completo o acesso certos tipos de ficheiros mais sensíveis • Validar TODOS os pedidos que chegam à aplicação • Autorização explicita • Não expor documentos físicos com URLs permanentes ou facilmente adivinháveis
  80. 80. Ataques contra os utilizadoresredireccionar os utilizadores para outro lado...
  81. 81. e se?....
  82. 82. Atacante envia um ataque para a vítima através de um email ou página Web From: Internal Revenue Service Subject: Your Unclaimed Tax Refund A aplicação Our records show you have an 3 redirecciona a vítima unclaimed federal tax refund. Please para o site do atacante click here to initiate your claim. Knowledge Mgmt Communication Administration Bus. Functions Vítima carrega no link que contém um parâmetro E-Commerce Transactions Accounts Finance 2 não validado Custom Code Pedido é enviado para um site vulnerável, incluindo o site de destino do atacante como parâmetro. O redireccionamento envia a vítima para o site do atacante. Evil Site O site do atacante instalahttp://www.irs.gov/taxrefund/claim.jsp? 4 malware ou tenta obter year=2006& … &dest=www.evilsite.com informação privada
  83. 83. A8: Redirecionamentos e Encaminhamentos não-Validados• Qual o risco? • Um atacante pode usar a reputação do seu site de Web como um vector para redireccionar utilizadores para um site de Web hostil• Quais as contra-medidas? • Nunca permitir o redireccionamento de URL absolutas • Se não for possível: • Usar whitelists de hosts válidos • Mostrar um aviso antes de redirecionar o utilizador • Se usar um “portal web”, tenha a certeza que as páginas de redirecionamento não incluem informação sensível na URL (a.k.a. informação de single-sign-on)
  84. 84. Evitar o A8• Existem diversas opções • Evitar usar redirecionamentos e encaminhamentos sempre que puder • Se usar, não envolva parâmetros (do utilizador) ao definir a URL alvo • Se tiver mesmo que usar parâmetros, então faça um dos seguintes: • valide cada parâmetro para garantir que é válido e autorizado para o utilizador actual, ou • (preferido) use um mapeamento do lado do servidor para traduzir a escolha realizada pelo utilizador na URL alvo • Defesa em profundidade: para redirecionamentos, valide a URL alvo, depois da mesma ser calculada, garantido que se refere a um site externo devidamente autorizado • ESAPI: pode fazer isto por si: • Ver: SecurityWrapperResponse.sendRedirect(  URL  ) • http://owasp-­‐esapi-­‐java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/SecurityWrapperResponse.html#sendRedirect(java.lang.String)
  85. 85. Ataques contra os utilizadores executar código hostil do cliente no site de web...
  86. 86. e se?....
  87. 87. e se?....
  88. 88. XSS 1 Atacante monta a armadilha – actualizando o seu perfil Aplicação com Atacante introduz um script malicioso numa vulnerabilidade XSS página web que armazenada armazena os dados no servidor Knowledge Mgmt Communication Administration Bus. Functions Vítima visualiza a página – visita o perfil E-Commerce Transactions 2 Accounts do atacante Finance Custom Code Script corre dentro do browser da vítima com acesso total ao DOM e aos cookies3 O script envia silenciosamente para o atacante o cookie de sessão da vítima
  89. 89. A2: Cross Site Scripting (XSS)• Qual o risco? • Um atacante pode injectar código hostil a partir do lado do cliente na aplicação web, que depois pode ser reenviado para uma vítima• Quais as contra-medidas? • Filtrar/Sanitizar o output. Codificar no formato de destino. • Para output em HTML, usar o HtmlEntities: • <div  id=“comment”>Here  is  my  <script>attack</script></div> • <div  id=“comment”>Here  is  my  &lt;script&gt;attack&lt;/script&gt;</div> • No caso do output XML, usar entidades pré-definidas: • <says>“here  is  my  <script>”</says>     <says><![CDATA[here  is  my  <script>]]></says> • <says>my  input  is  <script></says>   <says>my  input  is  &lt;script&gt;</says>
  90. 90. Ataques contra os utilizadores replicar e repetir pedidos previsíveis
  91. 91. e se?....
  92. 92. e se?....
  93. 93. Alice transferir 100€ para o Bob Bob através do bank.com POST  http://bank.com/transfer.do  HTTP/1.1 ... ... ... Content-­‐Length:  19; acct=BOB&amount=100 percebe que a mesma aplicação web do bank.com pode executar aMaria transferência usando uma URL com parâmetros. GET  http://bank.com/transfer.do?acct=BOB&amount=100  HTTP/1.1 vai tentar usar a Alice para tentar transferir 100.000€ para a sua própria conta http://bank.com/transfer.do?acct=MARIA&amount=100000 envia email HTML para a Alice com uma URL para carregar <a  href="http://bank.com/transfer.do? acct=MARIA&amount=100000">View  my  Pictures!</a> ou, envia email HTML para a Alice com uma imagem para esconder o ataque <img  src="http://bank.com/transfer.do?acct=MARIA&amount=100000"   width="1"  height="1"  border="0">Alice se Alice estiver autenticada no bank.com com uma sessão activa é feita a transferência (no segundo caso de forma escondida)
  94. 94. A5: Cross Site Request Forgery (CSRF)• Qual o risco? • Um atacante pode construir o seu próprio site de web e iniciar pedidos no browser do visitante• Quais as contra-medidas? • Implementar pedidos imprevisíveis para para todas as acções sensíveis • usar campos de controlo aleatórios invisíveis e temporários: • <input  type=”hidden”  name=”check”  value=”ab23b4a”> • ligar os formulários à sessão do utilizador: • if(!(Request.Form[“checker”]).Equals(SessionID))  //  return  error • Usar CAPTCHA • Usar verificações alternativas: • SMS/Chamada de Voz/Tokens criptográficos, etc.
  95. 95. Outros ataquesquebrar criptografia fraca...
  96. 96. A9: Armazenamento Criptográfico Inseguro• Qual o risco? • Um atacante pode não necessitar de tanto tempo como pode esperar para decifrar os seus dados • Se alguma das seguintes expressões são estranhas para si, então existe um risco: • cifra assimétrica e simétrica, cifra online, cifra offline, CBC, entropia de chaves, vector de inicialização, ECB, código de autenticação de mensagens (MAC), PBKDF2 (RFC2898), Rijndael, AES, 3DES, DSA, RSA, ECC, SHA, keyring, DPAPI, ...• Quais as contra-medidas? • Não faça criptografia por si próprio!!! • Usar APIs conhecidas • usar implementações open-source de referência (OpenSSL, Truecrypt, etc.) • usar librarias implementadas pela comunidade (OWASP ESAPI, ...) • Formação...
  97. 97. Evitar o A9• Verifique a sua arquitectura • identificar todos os dados sensíveis • identificar todos os pontos em que os dados são armazenados • assegurar modelo de ameaças para lidar com possíveis ataques • usar cifra para combater as ameaças => não se limitando apenas a “codificar” os dados• Proteger com os mecanismos apropriados • Cifra de ficheiros, Cifra de BD, Cifra de Elementos de dados (XML)• Usar os mecanismos correctamente • usar algoritmos fortes e standard • gerar, distribuir e proteger as chaves de forma adequada • estar preparado para mudar de chaves• Verificar a implementação • o algoritmo forte e standard está a ser usado e é o adequado para esta situação • todas as chaves, certificados e passwords estão devidamente armazenados e protegidos • estão criados os mecanismos correctos e seguros para a distribuição e alteração de chaves
  98. 98. Outros ataquesobservar o ambiente...
  99. 99. e se?....
  100. 100. A10: Protecção Insuficiente da Camada deTransporte• Qual é o risco? • Visualização do tráfego, devido a insuficiente protecção da camada de transporte• Quais as contra-medidas? • Requere links SSL cifrados • Usar certificados apropriados (assinados e válidos) • Impedir que os cookies possam sair dos links cifrados (flag “secure” activa)
  101. 101. Evitar o A10• Protecção com os mecanismos adequados • usar o TLS em todas as ligações com dados sensíveis • cifrar individualmente as mensagens antes do seu envio • ex., usar XML-Encryption • assinar digitalmente as mensagens antes do envio • ex., usar XML-Signature• Usar os mecanismos de forma adequada e correcta • usar algoritmos fortes e standard (desactivar alguns algoritmos antigos no SSL) • gerir as chaves e certificados correctamente • verificar os certificados SSL antes de os usar • usar mecanismos adequados e não sobrepostos • ex., SSL vs. XML-Encryption• Consultar: http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
  102. 102. OWASP Top 10
  103. 103. OWASP Top 10 (2010)• A1: Injecção• A2: Cross Site Scripting (XSS)• A3: Quebra de Autenticação e da Gestão de Sessões• A4: Referência Directa a Objectos Insegura• A5: Cross Site Request Forgery (CSRF)• A6: Configuração de Segurança Incorrecta• A7: Falhas na Restrição de Acesso a URL• A8: Redireccionamentos e Encaminhamentos não-Validados• A9: Armazenamento Criptográfico Inseguro• A10: Protecção Insuficiente da Camada de Transporte
  104. 104. Riscos no OWASP Top 10 RISCO Agentes        Vectores                      Fraquezas  Impactos Impactos de  Ameaça        de  Ataque                    de  Segurança      Técnicos Negócio Exploração Prevalência Detecção Impacto A1-­‐Injec=on FÁCIL COMUM MÉDIA SEVERO A2-­‐XSS MÉDIO MTO  ESPALHADO FÁCIL MODERADO A3-­‐Auth’n MÉDIO COMUM MÉDIA SEVERO A4-­‐DOR FÁCIL COMUM FÁCIL MODERADO A5-­‐CSRF MÉDIO ESPALHADO FÁCIL MODERADO A6-­‐Config FÁCIL COMUM FÁCIL MODERADO A7-­‐Crypto DIFÍCIL POUCO  COMUM DIFÍCIL SEVERO A8-­‐URL  Access FÁCIL POUCO  COMUM MÉDIA MODERADO A9-­‐Transport DIFÍCIL COMUM FÁCIL MODERADO A10-­‐Redirects MÉDIO POUCO  COMUM FÁCIL MODERADO
  105. 105. O “novo” Top 10 da OWASP (2010) http://www.owasp.org/index.php/Top_10
  106. 106. @pontocomcarlos.serrao@iscte.ptcarlos.j.serrao@iscte.pthttp://www.linkedin.com/in/carlosserrao
  107. 107. OWASP e o desenvolvimentoseguro de aplicações para a Web ISELTech’12 2012.05.11 Carlos Serrão

×