MobileConf2013 - Desenvolvimento Mobile Seguro

1.399 visualizações

Publicada em

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

Publicada em: Tecnologia
4 comentários
2 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
1.399
No SlideShare
0
A partir de incorporações
0
Número de incorporações
431
Ações
Compartilhamentos
0
Downloads
32
Comentários
4
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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:
  • MobileConf2013 - Desenvolvimento Mobile Seguro

    1. 1. Desenvolvimento Mobile Seguro Segundo a proposta da OWASP Augusto Marinho augustomarinho@conteudoatual.com.br
    2. 2. Motivação
    3. 3. Quais os problemas?
    4. 4. Uma proposta... Owasp top ten mobile risks
    5. 5. Armazenamento inseguro dos dados /mnt/sdcard SQLITE_INSEGURO.db
    6. 6. Client Side Injection AndroidManifest.xml android:exported="true" Client side injection Aplicativo Package Play
    7. 7. Exposição de dados por terceiros
    8. 8. Exposição de dados por terceiros ... uma opção
    9. 9. Proteção ineficiente no transporte dos dados Vamos então ao socket SSL ....
    10. 10. Proteção ineficiente no transporte dos dados
    11. 11. Fornecimento de informações sensíveis
    12. 12. Dados sensíveis capturados por inputs inseguros
    13. 13. Controles de autorização e autenticação fracos /data/system/accounts.db
    14. 14. Criptografia Fraca Problema Isso não resolve!!!!! md5(sha1(password)) md5(md5(salt) + md5(password)) sha1(sha1(password))
    15. 15. Controles frágeis do lado servidor
    16. 16. Captura de Sessão
    17. 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. 18. Obrigado! Augusto Marinho augustomarinho@conteudoatual.com.br

    ×