MobileConf2013 - Desenvolvimento Mobile Seguro

Notas do Editor

• #2: 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
• #3: 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.
• #4: 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
• #5: - 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.
• #6: 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
• #7: 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/
• #8: 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
• #9: -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.
• #10: 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.
• #11: Todo mundo sabe que se deve usar Https Falar apresentar o problema de validação de hostname. Falar da fonte Google (Android Developer)
• #12: 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)
• #13: 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)
• #14: 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!
• #15: 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
• #16: 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.
• #17: 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:
• #18: 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: