MobileConf2013 - Desenvolvimento Mobile Seguro
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

MobileConf2013 - Desenvolvimento Mobile Seguro

  • 955 views
Uploaded on

Apresentação realizada no evento MobileConf 2013 como tema: Desenvolvimento Mobile Seguro segundo a proposta da Owasp.

Apresentação realizada no evento MobileConf 2013 como tema: Desenvolvimento Mobile Seguro segundo a proposta da Owasp.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
955
On Slideshare
719
From Embeds
236
Number of Embeds
5

Actions

Shares
Downloads
28
Comments
4
Likes
2

Embeds 236

http://conteudoatual.com.br 226
https://www.linkedin.com 5
http://www.linkedin.com 2
https://conteudoatual.wordpress.com 2
http://www.google.com.br 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Fazer uma breve descrição profissional: Nome, profissão, onde trabalha, quanto tempo. <br /> - Objetivo da palestra é apresentar uma abordagem sobre desenvolvimento mobile seguro sob a visão da OWASP <br />
  • 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. <br /> 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. <br />
  • Falar da miscelânea de sistemas operacionais e fabricantes <br /> Falar do quanto este cenário torno um desafio desenvolver um produto que deve operar em mais de uma plataforma mobile <br />
  • - 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. <br /> - 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. <br />
  • 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. <br /> 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. <br /> 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 <br />
  • Falar da fragilidade dos discos externos. É uma área comum de acesso para todos os aplicativos. <br /> 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. <br /> 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!) <br /> Uma opção http://sqlcipher.net/design/ <br />
  • Falar do comportamento da opção android:exported. <br /> O mesmo comportamento para para Service- O seu produto pode ser utilizado por terceiros sem seu consentimento e/ou ciência. <br /> Falar rapidamento do package play <br /> proposta: Cuidado com o comportamento default do Android:exported <br />
  • -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. <br />
  • Explicar como era o comportamento nas versões anteriores a 17 do ADT (Março/2012) <br /> Como pode ser evitado o vazamento de informações sensíveis <br /> Proposta: Falar da utlização da configuração ApplicationInfo. <br />
  • Todo mundo sabe que se deve usar Https <br /> Falar apresentar o problema de validação de hostname. Falar da fonte Google (Android Developer) <br />
  • Falar do processo de handshake SSL (Encriptação dos dados e autenticação do hostname) <br /> o Socket SSL, por padrão, não faz a validação de hostname. Pode ser um caso de main-in-the-middle <br /> -Proposta: Falar da validação do HostName com o componente Http. <br /> Se for Self-signed o certificado deve ser importado em Bouncy Caslte (PKCS-12) <br />
  • Flexibilizar a remoção do aplicativo para o Sdcard pode não ser uma boa idéia. <br /> A propriedade intelectual estará exposta <br /> Ferramentas como o Dex2Jar podem decompilar o código java compilado para o Dalvik <br /> Falar da facilidade para o ofensor. Apenas inserindo uma dificuldade já é o bastante para desencorajar o meliante. <br /> Com a aplicação exposta no Sdcard, não é necessário o SO estar fragilidade para executar este cenário <br /> Como alternativa falar do ProGuard (não é apenas para android) <br />
  • 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) <br /> 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 <br /> Push Notificatio também não resolve, por ser uma troca de mensagens por Http <br /> Proposta: O e-mail nestes casos ainda é a melhor opção! <br />
  • O Account Manager não implementa nenhum mecanismo de segurança! <br /> Os dados são armazenados em uma base Sqlite na sandbox, porém em texto plano. <br /> Se deseja proteção você mesmo deverá prover <br /> Proposta: Falar da opção apresentada no Google I/O 2011 (Yaniv inbar) <br /> Falar da utilização de Criptografia com Salt utilizado no exemplo <br />
  • http://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided <br /> Explicar rapidamente o que é Compilação de mensagem e por que o código acima não resolve <br /> Explicar rapidamente o que é Brute Force e Ataque de Dicionário <br /> Explicar a importância do Salt e como deve ser este Salt (identificador único por usuário. Não deve ser fraco). <br /> Dar o exemplo de msisdn sendo o Salt (com a entrada no 9 dígito) <br /> O Salt você deve ter absoluto controle da formação, depender de terceitos pode acarretar problemas como o do nono dígito. <br />
  • Não adianta ter um controle de autenticação forte se o controle de autorização é fraco. <br /> Não deve ser permitido um usuário ter acesso aos dados de outros, como por query string por exemplo. <br /> Proposta: <br />
  • 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. <br /> Explicar que problemas inerentes a aplicações Web como Cross-site Scripting entre outros também podem afetar aplicações mobile. <br /> Proposta: <br />

Transcript

  • 1. Desenvolvimento Mobile Seguro Segundo a proposta da OWASP Augusto Marinho augustomarinho@conteudoatual.com.br
  • 2. Motivação
  • 3. Quais os problemas?
  • 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
  • 16. Captura de Sessão
  • 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.
  • 18. Obrigado! Augusto Marinho augustomarinho@conteudoatual.com.br