OWASP @ ISCTE-IUL, OWASP Top 10 2010

OWASP @ ISCTE-IUL Workshop de Segurança Aplicacional OWASP Top 10 (v.2010) ISCTE-‐IUL/DCTI Carlos Serrão Instituto Superior de Ciências do Trabalho e da Empresa carlos.serrao@iscte.pt Instituto Universitário de Lisboa carlos.j.serrao@gmail.com Departamento de Ciências e Tecnologias de Informação http://www.carlosserrao.net http://blog.carlosserrao.net http://www.linkedin.com/in/carlosserrao

O que é a Segurança em Aplicações Web? 2  Não é Segurança de Redes  Segurança do “código” criado para implementar a aplicação web  Segurança de bibliotecas  Segurança de sistemas de back-end  Segurança de servidores web e aplicacionais  Segurança de Redes ignora o conteúdo do tráfego de HTTP  Firewalls,SSL, Intrusion Detection Systems, Operating System Hardening, Database Hardening OWASP @ ISCTE-IUL Abril 2010

O código faz parte do perímetro de segurança 3 O seu perímetro de segurança possui buracos enormes na camada Application Layer Legacy Systems aplicacional Human Resrcs Web Services Directories Databases Billing Custom Developed Application Code APPLICATION ATTACK App Server Web Server Network Layer Hardened OS Firewall Firewall Não é possível usar protecção ao nível da camada de rede (firewall, SSL, IDS, hardening) para parar ou detectar ataques ao nível aplicacional OWASP @ ISCTE-IUL Abril 2010

Isto é preocupante? 4  Vamos lá pensar…  Qual a probabilidade de sucesso de um ataque contra uma aplicação web?  Probabilidade elevada  Fácil de explorar sem conhecimento e ferramentas especiais  Quase indetectável  Existem milhares de programadores web, pouco preocupados com segurança  Consequências?  Corrupção de dados ou destruição de BD  Acesso root a servidores web ou aplicacionais  Perda de autenticação e de controlo de acesso de utilizadores  Descaracterização (Defacement)  Ataques secundários a partir da própria aplicação web OWASP @ ISCTE-IUL Abril 2010

Isto é preocupante? 5 !"#$%&$'"()%*+,"-./0&10+23" Viva, daqui fala da Oh meu Deus - e ele O seu filho chama-se Bem, perdemos os escola do seu filho. estragou alguma coisa? mesmo registos dos estudantes Tivemos um pequeno Robert’); DROP TABLE deste ano. Espero que problema no De certa Students;-- ? esteja contente!!! computador. forma, sim... E eu espero que Sim, é verdade tenham chamamos-lhe o aprendido a Bobby Tables. filtrar os inputs da base de dados! OWASP @ ISCTE-IUL Abril 2010

Isto é preocupante? 6  A Segurança de Aplicações Web é tão importante como a Segurança de Redes  Porque é que grande parte do investimento em Segurança é canalizado para a segurança das redes? OWASP @ ISCTE-IUL Abril 2010

Segurança de Aplicações Web 7 !"#$%&'(&)*+,-.&.-/'&,) .,CF/&2'&*+,-* .$9,*+,-* 3/)D4,/*+,-AE#$,29,* !""#,9* !%=0,>* !"#$%&'()* .,/0$1)/* +,-* +,-* .,/0$1)/* :$%;*<29,/2,9*!""#$%&=)2* !"#$%&%$)2&#* .$#0,/B !?&7* 6/)78* #$C;9* @#&4;A +,-* !<:* 3&4,*1,* .,/0$')* +,-* 5&1)4* DEVE ser capaz de proteger contra um DEVE ser capaz de proteger contra uma UTILIZADOR WEB HOSTIL PÁGINA WEB HOSTIL OWASP @ ISCTE-IUL Abril 2010

Segurança de Aplicações Web 8 Tipos de Problemas Falhas típicas de Aplicações Web OWASP @ ISCTE-IUL Abril 2010

Segurança de Aplicações Web 8 Sistema Operativo 9% Injeção de SQL Cross-Site Scripting (XSS) 23% 38% Aplicação Revelação de Informação 30% Web 61% 8% Autorização Inclusão de Código 8% 23% Tipos de Problemas Falhas típicas de Aplicações Web OWASP @ ISCTE-IUL Abril 2010

Ataques 9  Ataques contra a infra-estrutura  Ataques contra a aplicação  Ataques contra os utilizadores  Outros ataques OWASP @ ISCTE-IUL Abril 2010

Ataques contra a infra-estrutura atacar a camada mais fraca OWASP @ ISCTE-IUL Abril 2010

OWASP @ ISCTE-IUL Abril 2010

Aplicação Web Servidor Aplicacional Servidor Web Sistema Operativo Dispositivos de Rede OWASP @ ISCTE-IUL Abril 2010

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? OWASP @ ISCTE-IUL Abril 2010

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 OWASP @ ISCTE-IUL Abril 2010

Aplicação Web Servidor Aplicacional Todos 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 OWASP @ ISCTE-IUL Abril 2010

Aplicação Web Todas as aplicações de demonstração foram removidas? Servidor Aplicacional Está o servidor actualizado? Está a parte de administração protegida de acesso externo? Servidor Web Indexação de directorias foi desactivada? Foram as passwords de defeito alteradas? Sistema Operativo Dispositivos de Rede OWASP @ ISCTE-IUL Abril 2010

E aqui???? Aplicação Web Servidor Aplicacional Servidor Web Sistema Operativo Dispositivos de Rede OWASP @ ISCTE-IUL Abril 2010

o seu sistema será tão seguro quanto a segurança do elo mais fraco... OWASP @ ISCTE-IUL !"#$%&'(")*++,-'./%" Abril 2010

A6: Configuração de Segurança Incorrecta 13  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” OWASP @ ISCTE-IUL Abril 2010

A6: Configuração de Segurança Incorrecta 14 As aplicações web dependem de uma fundação segura • Da rede e da plataforma • Não esquecer o ambiente de desenvolvimento É o seu código-fonte um segredo? • Pensar em todos os lugares onde o seu código-fonte anda • Segurança não deve depender do código-fonte ser secreto A Gestão de Configuração deve estender-se a todas as partes da aplicação • Todas as credenciais devem ser alteradas na entrada em produção Impacto típico • Instalar um backdoor através da falta de um patch no servidor ou rede • Exploits de XSS devido à falta de patches nas frameworks aplicacionais • Acesso não-autorizado a contas por defeito, funcionalidades ou dados aplicacionais por defeito, ou funcionalidades não-usadas mas acessíveis devido a má configuração do servidor OWASP @ ISCTE-IUL Abril 2010

Ataques contra a aplicação injectar código hostil... OWASP @ ISCTE-IUL Abril 2010

e se?.... OWASP @ ISCTE-IUL Abril 2010

e se?.... SELECT * FROM users usr WHERE usr.username = ‘admin’;--’ AND usr.password=’bb21158c733229347bd4e681891e213d94c685be’ OWASP @ ISCTE-IUL Abril 2010

OWASP @ ISCTE-IUL Abril 2010

qualquer input do utilizador pode ser um vector de ataque OWASP @ ISCTE-IUL Abril 2010

A1: Injecção 20  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 OWASP @ ISCTE-IUL Abril 2010

A1: Injecção 21  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) OWASP @ ISCTE-IUL Abril 2010

A1: Injecção 22  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)  ... OWASP @ ISCTE-IUL Abril 2010

A1: Injecção 23  CONTRA-MEDIDAS  escolhera 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 OWASP @ ISCTE-IUL Abril 2010

A1: Injecção 24 Injecção significa... • Enganar uma aplicação escondendo comandos “não esperados” nos dados enviados ao interpretador Interpretadores... • Pegam em cadeias de caracteres (strings) e interpretam-nas como comandos • SQL, Shell SO, LDAP, XPath, Hibernate, ... Injecção de SQL ainda é muito comum • Ainda existem muitas aplicações susceptíveis (não se percebe bem porquê) • Apesar de ser bastante simples de evitar Impacto típico • Impacto severo. Uma BD inteira pode ser lida ou modificada • Pode permitir o acesso à definição (esquema) da BD, acesso a algumas contas, ou acesso ao nível do SO OWASP @ ISCTE-IUL Abril 2010

Ataques contra a aplicação brincar com identificadores óbvios... OWASP @ ISCTE-IUL Abril 2010

e se?.... • um atacante repara que o parâmetro https://www.onlinebank.com/user?acct=6065 acct é 6065 ?acct=6065 • modifica este valor para um valor próximo ?acct=6066 • atacante consegue ver a informação da conta da vítima OWASP @ ISCTE-IUL Abril 2010

A4: Referências Directas a Objectos Inseguras 27  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 OWASP @ ISCTE-IUL Abril 2010

A4: Referências Directas a Objectos Inseguras 28 Como proteger o acesso aos seus dados? • Isto é parte de forçar a “autorização” apropriada em conjunto com o A7: Falhas na Restrição de Acesso a URL Um erro comum... • Apenas listar os objectos “autorizados” para o utilizador actual, ou • Esconder as referências a objectos em campos hidden • ... e depois não forçar estas mesmas restrições do lado do servidor • Isto designa-se por controlo de acesso na camada de apresentação, e não funciona • O atacante pode modificar os valores dos parâmetros Impacto típico • Os utilizadores podem aceder a ficheiros e dados para os quais não estão autorizados OWASP @ ISCTE-IUL Abril 2010

Ataques contra a aplicação quebrar os mecanismos de sessão e de autenticação OWASP @ ISCTE-IUL Abril 2010

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 4 5 Hacker usa JSESSIONID e assume a identificação e a conta da vítima OWASP @ ISCTE-IUL Abril 2010

A3: Quebra da Autenticação e da Gestão de Sessões 34  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? OWASP @ ISCTE-IUL Abril 2010

A3: Quebra da Autenticação e da Gestão de Sessões 35  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) OWASP @ ISCTE-IUL Abril 2010

A3: Quebra da Autenticação e da Gestão de Sessões 36 HTTP é um protocolo “stateless” • Significa que as credenciais têm que ir com cada pedido • Deve-se usar o SSL para tudo o que necessite autenticação Falhas na Gestão de Sessões • SESSION ID é usado para acompanhar o estado uma vez o HTTP não o faz • e é tão útil como as credenciais para um atacante • SESSION ID é tipicamente exposto na rede, no browser, em logs... Cuidado com as portas do lado... • Alterar a minha password, Lembrar a minha password, Esqueci a minha password, Pergunta secreta, Logout, Endereço de email, ... Impacto típico • Contas dos utilizadores comprometidas e “desvio/rapto” de sessões OWASP @ ISCTE-IUL Abril 2010

Ataques contra a aplicação encontrar URLs “secretas” escondidas OWASP @ ISCTE-IUL Abril 2010

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 OWASP @ ISCTE-IUL Abril 2010

A7: Falhas na Restrição de Acesso a URL 41  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 OWASP @ ISCTE-IUL Abril 2010

A7: Falhas na Restrição de Acesso a URL 42 Como proteger o acesso a URLs (páginas) • É importante forçar “autorização” apropriada, tal como em A4: Referências Directas a Objectos Inseguras Um erro comum... • Mostrar apenas os links e as escolhas de menu autorizados • Designa-se por controlo de acesso da camada de apresentação e não funciona! • O atacante simplesmente forja o acesso directo a páginas não-autorizadas Impacto típico • Atacantes invocam funções e serviços para os quais não possuem autorização • Acedem a contas e dados de outros utilizadores • Realizam acções privilegiadas OWASP @ ISCTE-IUL Abril 2010

Ataques contra os utilizadores redireccionar os utilizadores para outro lado... OWASP @ ISCTE-IUL Abril 2010

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 instala http://www.irs.gov/taxrefund/claim.jsp? 4 malware ou tenta obter year=2006& … &dest=www.evilsite.com informação privada OWASP @ ISCTE-IUL Abril 2010

A8: Redirecionamentos e Encaminhamentos não- Validados 46  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) OWASP @ ISCTE-IUL Abril 2010

Evitar o A8 47  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) OWASP @ ISCTE-IUL Abril 2010

A8: Redirecionamentos e Encaminhamentos não- Validados 48 Os redirecionamentos em WebApp são muito comuns • É importante forçar “autorização” apropriada, tal como em A4: Referências Directas a Objectos Inseguras Encaminhamentos (a.k.a. Transfer .NET) são igualmente comuns • Mostrar apenas os links e as escolhas de menu autorizados • Designa-se por controlo de acesso da camada de apresentação e não funciona! • O atacante simplesmente forja o acesso directo a páginas não-autorizadas Impacto típico • Atacantes invocam funções e serviços para os quais não possuem autorização • Acedem a contas e dados de outros utilizadores • Realizam acções privilegiadas OWASP @ ISCTE-IUL Abril 2010

Ataques contra os utilizadores executar código hostil do cliente no site de web... OWASP @ ISCTE-IUL Abril 2010

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 cookies 3 O script envia silenciosamente para o atacante o cookie de sessão da vítima OWASP @ ISCTE-IUL Abril 2010

A2: Cross Site Scripting (XSS) 53  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 <script>attack</script></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 <script></says> OWASP @ ISCTE-IUL Abril 2010

A2: Cross Site Scripting (XSS) 54 Ocorre em qualquer altura... • Dados em bruto (raw) de um atacante são enviados para o browser de um utilizador Dados em bruto (raw)... • Armazenados numa BD • Reflectidos a partir de entradas web (campo num form, campo hidden, URL, etc) • Enviado directamente a partir de um cliente Javascript Virtualmente todas as aplicações web sofrem... • Experimentar no browser: javascript:alert(document.cookie) Impacto típico • Roubar sessão do utilizador, roubar dados sensíveis, re-escrever página web, redireccionar o utilizador para site de phishing ou distribuição de malware • Mais severo: instalar proxy XSS que permite que um atacante observe e direccione o comportamento do utilizador no site vulnerável e o force a usar outros sites OWASP @ ISCTE-IUL Abril 2010

Ataques contra os utilizadores replicar e repetir pedidos previsíveis OWASP @ ISCTE-IUL Abril 2010

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 a Maria 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) OWASP @ ISCTE-IUL Abril 2010

A5: Cross Site Request Forgery (CSRF) 59  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. OWASP @ ISCTE-IUL Abril 2010

A5: Cross Site Request Forgery (CSRF) 60 Cross Site Request Forgery • Um ataque em que o browser da vítima é enganado a partir de comandos enviados a partir de uma aplicação web vulnerável • A vulnerabilidade é causada pelo facto dos browsers incluírem dados de autenticação de utilizadores de forma automática (session ID, endereço IP, credenciais de domínios Windows, ...) em cada pedido Imagine... • Se um atacante pudesse guiar o seu rato e fazer com que clicasse em links específicos na sua conta bancária on-line? • O que poderiam forçá-lo a fazer? Impacto típico • Iniciar transações (transferir fundos, logout de utilizadores, fechar contas) • Aceder a dados sensíveis • Alterar detalhes da conta OWASP @ ISCTE-IUL Abril 2010

Outros ataques quebrar criptografia fraca... OWASP @ ISCTE-IUL Abril 2010

A9: Armazenamento Criptográfico Inseguro 62  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... OWASP @ ISCTE-IUL Abril 2010

Evitar o A9 63  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  analisar o código de cifra à procura de vulnerabilidades comuns OWASP @ ISCTE-IUL Abril 2010

A9: Armazenamento Criptográfico Inseguro 64 Armazenamento inseguro de dados sensíveis • Falhar na identificação de todos os dados sensíveis • Falhar na identificação de todos os locais em que estes dados sensíveis são armazenados • BD, ficheiros, directorias, ficheiros de log, backups, etc. • Falhar na protecção correcta destes dados em todos os locais Impacto típico • Atacantes podem aceder ou modificar informação privada e confidencial • cartões de crédito, registos médicos, dados financeiros (seus e dos seus clientes) • Atacantes podem extrair segredos para lançar mais ataques • Má imagem da empresa, insatisfação de clientes, perda de confiança • Despesas de “limpeza” do incidente, tais como trabalho forense, enviar cartas de pedidos de desculpa, re-imitir milhares de cartões de crédito, oferecer seguros de roubo de identidade, etc. • Empresa processada ou multada OWASP @ ISCTE-IUL Abril 2010

Outros ataques observar o ambiente... OWASP @ ISCTE-IUL Abril 2010

A10: Protecção Insuficiente da Camada de Transporte 67  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) OWASP @ ISCTE-IUL Abril 2010

Evitar o A10 68  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 OWASP @ ISCTE-IUL Abril 2010

A10: Protecção Insuficiente da Camada de Transporte 69 Transmissão insegura de dados sensíveis • Falha na identificação de todos os dados sensíveis • Falha na identificação de todos os sítios em que estes dados sensíveis são enviados • na web, para BD de backend, para parceiros de negócio, comunicações internas • Falha na protecção apropriada destes dados em todos os sítios Impacto típico • Atacantes podem aceder ou modificar informação privada e confidencial • ex: cartões de crédito, registos médicos, dados financeiros (seus ou dos seus clientes) • Atacantes podem extrair segredos para lançar mais ataques • Má imagem da empresa, insatisfação dos clientes, ou perda de confiança • Despesas da “limpeza” do incidente • Negócios serem processados ou multados OWASP @ ISCTE-IUL Abril 2010

OWASP Top 10 (2007) 70  A1: Cross Site Scripting (XSS)  A2: Falhas de Injecção  A3: Execução de Ficheiros Maliciosos  A4: Referência Directa a Objectos Insegura  A5: Cross Site Request Forgery (CSRF)  A6: Perda de Informação e Tratamento Incorrecto de Erros  A7: Quebra de Autenticação e da Gestão de Sessões  A8: Armazenamento Criptográfico Inseguro  A9: Comunicações Inseguras  A10: Falhas na Restrição de Acesso a URL OWASP @ ISCTE-IUL Abril 2010

OWASP Top 10 (2010) 71  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 OWASP @ ISCTE-IUL Abril 2010

O que mudou 2010? 72 É sobre Riscos e não apenas sobre Vulnerabilidades • O novo título é: “Os 10 Riscos mais críticos de Segurança em Aplicações Web ” Metodologia de definição de Risco da OWASP • Baseado na metodologia de definição de risco da OWASP para classificar o Top10 2 novos Riscos acrescentados, 2 removidos • Acrescentado: A6: Configuração de Segurança Incorrecta • Era o A10 na versão de 2004: Gestão de Configuração Insegura • Acrescentado: A8: Redirecionamentos e Encaminhamentos Não-validados • Falha comum e perigosa que não é muito conhecida • Removido: A3: Execução de Ficheiros Maliciosos • Principalmente uma falha do PHP que está a desaparecer • Removido: A6 - Perda da Informação e Tratamento Incorrecto de Erros • Uma falha persistente, mas que (normalmente) não introduz muito risco OWASP @ ISCTE-IUL Abril 2010

Diferenças entre Top10 2007 e 2010 73 = = + + - - OWASP @ ISCTE-IUL Abril 2010

Metodologia de determinação de Risco do OWASP Top10 74 Agentes de Vectores de Prevalência da Detecção da Impacto de Impacto Técnico Ameaça Ataque Fraqueza Fraqueza Negócio 1 Fácil Alargado Fácil Severo ? 2 Médio Comum Médio Moderado ? 3 Dificil Pouco Comum Dificil Menor 2 1 1 2 Exemplo do XSS 1.3 * 2 OWASP @ ISCTE-IUL 2.6 avaliação do peso do risco Abril 2010

Riscos no OWASP Top 10 75 Impactos RISCO Vectores de Ataque Fraquezas de Segurança Impactos Técnicos Negócio Agentes de Ameaça 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-‐Conﬁg 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 OWASP @ ISCTE-IUL Abril 2010

O “novo” Top 10 da OWASP (2010) 76 http://www.owasp.org/index.php/Top_10 OWASP @ ISCTE-IUL Abril 2010

... em resumo 77 OWASP @ ISCTE-IUL Abril 2010

referências 78  Fabio Cerullo, OWASP Ireland, “OWASP Top 10 - 2010 rc1”, IBWAS’09, Madrid, Spain, 2009  Antonio Fontes, OWASP Geneva Chapter Leader, “OWASP Top 10 - 2010 rc1”, Confoo Conference, Montreal, Canada, 2010  OWASP, “OWASP Top 10 2010”, http://www.owasp.org/ index.php/OWASP_Top_Ten_Project  OWASP, “Cross-site Scripting (XSS)”, http://www.owasp.org/ index.php/Cross-site_Scripting_(XSS)  OWASP, “Cross-Site Request Forgery (CSRF)”, http:// www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)  OWASP, “OWASP Application Security FAQ”, http:// www.owasp.org/index.php/OWASP_AppSec_FAQ OWASP @ ISCTE-IUL Abril 2010

OWASP @ ISCTE-IUL Workshop de Segurança Aplicacional OWASP Top 10 (v.2010) ISCTE-‐IUL/DCTI Carlos Serrão Instituto Superior de Ciências do Trabalho e da Empresa carlos.serrao@iscte.pt Instituto Universitário de Lisboa carlos.j.serrao@gmail.com Departamento de Ciências e Tecnologias de Informação http://www.carlosserrao.net http://blog.carlosserrao.net http://www.linkedin.com/in/carlosserrao

OWASP @ ISCTE-IUL, OWASP Top 10 2010

by Carlos Serrão

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 239

Statistics