OWASP top 10 mobile risks
•Télécharger en tant que PPT, PDF•
2 j'aime•2,044 vues
Apresentação realizada no evento MobileConf 2013 como tema: Desenvolvimento Mobile Seguro segundo a proposta da Owasp.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à OWASP top 10 mobile risks
Similaire à OWASP top 10 mobile risks (20)
OWASP top 10 mobile risks
- 1. Desenvolvimento Mobile Seguro Segundo a proposta da OWASP Augusto Marinho augustomarinho@conteudoatual.com.br
- 2. Motivação
- 4. Uma proposta... Owasp top ten mobile risks
- 5. Armazenamento inseguro dos dados /mnt/sdcard SQLITE_INSEGURO.db
- 6. Client Side Injection AndroidManifest.xml android:exported="true" Client side injection Aplicativo Package Play
- 7. Exposição de dados por terceiros
- 8. Exposição de dados por terceiros ... uma opção
- 9. Proteção ineficiente no transporte dos dados Vamos então ao socket SSL ....
- 10. Proteção ineficiente no transporte dos dados
- 11. Fornecimento de informações sensíveis
- 12. Dados sensíveis capturados por inputs inseguros
- 13. Controles de autorização e autenticação fracos /data/system/accounts.db
- 14. Criptografia Fraca Problema Isso não resolve!!!!! md5(sha1(password)) md5(md5(salt) + md5(password)) sha1(sha1(password))
- 15. Controles frágeis do lado servidor
- 17. Para finalizar Para desenvolver um aplicativo seguro, não basta utilizar as melhores tecnologias; não basta ser excelente tecnicamente se você não estiver conectado ao negócio e entender quais os impactos negativos para imagem do seu produto, caso uma vulnerabilidade seja explorada com sucesso.
Notes de l'éditeur
- Fazer uma breve descrição profissional: Nome, profissão, onde trabalha, quanto tempo. - Objetivo da palestra é apresentar uma abordagem sobre desenvolvimento mobile seguro sob a visão da OWASP
- O celular evoluiu. No início o pouco que se tinha de software era embarcado, o ambiente era extremamente controlado. O protagonista não era o software e sim estreitar a comunicação. Hoje o celular evoluiu para os smartphones, temos sistemas operacionais para mobile viabilizando o desenvolvimento de produtos para agregar valor ao equipamento. O celular não é mais um mero meio de comunicação telefônica.
- Falar da miscelânea de sistemas operacionais e fabricantes Falar do quanto este cenário torno um desafio desenvolver um produto que deve operar em mais de uma plataforma mobile
- - A Owasp éuma organização internacional de profissionais de TI que conduzem uma série de trabalhos com o objetivos de disseminar melhores práticas para criar soluções de TI mais seguras. - A Owasp tem trabalhos voltados para segurança nas mais diversas áreas de TI, como: desenvolvimento (Top Tem Mobile, Web, Cloud, testes de software), infraestrutura (apache, mod_proxy) etc.
- O top ten mobile risks é um documento que elenca os dez principais pontos de controle a serem aplicados durante o desenvolvimento de um software mobile seguro. O intuito do documento é ser agnóstico e não estar voltado especificamente para nenhuma plataforma mobile específica. Por isso, adaptações nas formas de controlar determinados pontos podem, e muitas vezes são, diferentes em plataformas mobile diferentes. O ponto principal do documento e entender os pontos de controle e identificar como é possível aplicá-los na plataforma mobile em que está sendo desenvolvida uma solução
- Falar da fragilidade dos discos externos. É uma área comum de acesso para todos os aplicativos. Para armazenar dados no SDCard tem que ter uma justificativa bastante forte (compensadora) para retirar a proteção nativa da sandbox do oferecida pelo sistema operacional. Em alguns casos, a repercução negativa de uma dado não tão sensível exposto pode ser o suficiente para destruir a confiabilidade do produto. (Importante!) Uma opção http://sqlcipher.net/design/
- Falar do comportamento da opção android:exported. O mesmo comportamento para para Service- O seu produto pode ser utilizado por terceiros sem seu consentimento e/ou ciência. Falar rapidamento do package play proposta: Cuidado com o comportamento default do Android:exported
- -Log.i() não é retirado quando um aplicativo é submetido ao Google Play. Basta alguém estar conectado com um dispositivo ao LogCat e os dados poderão ser exibidos.
- Explicar como era o comportamento nas versões anteriores a 17 do ADT (Março/2012) Como pode ser evitado o vazamento de informações sensíveis Proposta: Falar da utlização da configuração ApplicationInfo.
- Todo mundo sabe que se deve usar Https Falar apresentar o problema de validação de hostname. Falar da fonte Google (Android Developer)
- Falar do processo de handshake SSL (Encriptação dos dados e autenticação do hostname) o Socket SSL, por padrão, não faz a validação de hostname. Pode ser um caso de main-in-the-middle -Proposta: Falar da validação do HostName com o componente Http. Se for Self-signed o certificado deve ser importado em Bouncy Caslte (PKCS-12)
- Flexibilizar a remoção do aplicativo para o Sdcard pode não ser uma boa idéia. A propriedade intelectual estará exposta Ferramentas como o Dex2Jar podem decompilar o código java compilado para o Dalvik Falar da facilidade para o ofensor. Apenas inserindo uma dificuldade já é o bastante para desencorajar o meliante. Com a aplicação exposta no Sdcard, não é necessário o SO estar fragilidade para executar este cenário Como alternativa falar do ProGuard (não é apenas para android)
- A caixa de SMS´s do celular não é um ponto seguro para enviar ou receber informações sensíveis (sms de texto ou binário) Basta ter uma outra aplicação com a permissão de leitura da caixa de mensagens aceita pelo usuário para ter a confidencialidade do seu dado comprometida Push Notificatio também não resolve, por ser uma troca de mensagens por Http Proposta: O e-mail nestes casos ainda é a melhor opção!
- O Account Manager não implementa nenhum mecanismo de segurança! Os dados são armazenados em uma base Sqlite na sandbox, porém em texto plano. Se deseja proteção você mesmo deverá prover Proposta: Falar da opção apresentada no Google I/O 2011 (Yaniv inbar) Falar da utilização de Criptografia com Salt utilizado no exemplo
- http://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided Explicar rapidamente o que é Compilação de mensagem e por que o código acima não resolve Explicar rapidamente o que é Brute Force e Ataque de Dicionário Explicar a importância do Salt e como deve ser este Salt (identificador único por usuário. Não deve ser fraco). Dar o exemplo de msisdn sendo o Salt (com a entrada no 9 dígito) O Salt você deve ter absoluto controle da formação, depender de terceitos pode acarretar problemas como o do nono dígito.
- Não adianta ter um controle de autenticação forte se o controle de autorização é fraco. Não deve ser permitido um usuário ter acesso aos dados de outros, como por query string por exemplo. Proposta:
- Não é aconselhado utilizar como identificadores de sessão dados do dispositivo, como MSISDN, IMEI, ICCID. É fácil simular um número válido e tentar capturar a sessão de algum usuário ativo. Explicar que problemas inerentes a aplicações Web como Cross-site Scripting entre outros também podem afetar aplicações mobile. Proposta: