OWASP Mobile Top 10 2016 List:
Esta categoria abrange uso indevido de um recurso de plataforma ou falha no uso de controles de segurança da plataforma. Pode incluir intenções Android, permissões de plataforma, uso indevido de touchid, chaveiro ou algum outro controle de segurança que faz parte do sistema operacional móvel. Existem várias maneiras pelas quais os aplicativos móveis podem experimentar esse risco.
Esta nova categoria é uma combinação de M2 + M4 do Mobile Top Ten 2014. Isso abrange armazenamento de dados inseguro e vazamento de dados não intencionais.
Isso abrange um handshaking ruim, versões SSL incorretas, negociação fraca, comunicação clara de texto de ativos sensíveis, etc.
Esta categoria captura noções de autenticação do usuário final ou gerenciamento de sessão ruim. Isso pode incluir:
O código aplica criptografia a um ativo de informações confidenciais. No entanto, a criptografia é insuficiente de alguma forma. Observe que tudo e qualquer coisa relacionada ao TLS ou SSL entram em M3. Além disso, se o aplicativo não usar a criptografia quando deveria, isso provavelmente pertence ao M2. Esta categoria é para questões em que a criptografia foi tentada, mas não foi feito corretamente.
Esta é uma categoria para capturar quaisquer falhas na autorização (por exemplo, decisões de autorização no lado do cliente, navegação forçada etc.). É distinto dos problemas de autenticação (por exemplo, inscrição no dispositivo, identificação do usuário, etc.).
Se o aplicativo não autenticar usuários em uma situação em que deve (por exemplo, conceder acesso anônimo a algum recurso ou serviço quando é necessário acesso autenticado e autorizado), essa é uma falha de autenticação e não uma falha de autorização.
Essas foram as "decisões de segurança por meio de entradas não confiáveis", uma de nossas categorias menos usadas. Este seria o problema para problemas de implementação no nível do código no cliente móvel. Isso é distinto dos erros de codificação do lado do servidor. Isso capturaria coisas como transbordamentos de buffer, vulnerabilidades de string de formato e vários outros erros no nível de código, onde a solução é reescrever algum código que está em execução no dispositivo móvel.
Esta categoria abrange patches binários, modificação de recursos locais, conexão de método, swizzling de método e modificação de memória dinâmica.
Depois que o aplicativo é entregue ao dispositivo móvel, os recursos de código e dados são residentes lá. Um invasor pode modificar diretamente o código, alterar o conteúdo da memória dinamicamente, alterar ou substituir as APIs do sistema que o aplicativo usa ou modificar os dados e recursos do aplicativo. Isso pode fornecer ao invasor um método direto de subverter o uso pretendido do software para ganho pessoal ou monetário.
Essa categoria inclui a análise do binário central final para determinar seu código -fonte, bibliotecas, algoritmos e outros ativos. Software como IDA Pro, Hopper, Otool e outras ferramentas de inspeção binária fornecem ao invasor uma visão do funcionamento interno do aplicativo. Isso pode ser usado para explorar outras vulnerabilidades nascentes no aplicativo, além de revelar informações sobre servidores de back -end, constantes criptográficas e cifras e propriedade intelectual.
Freqüentemente, os desenvolvedores incluem funcionalidade oculta de backdoor ou outros controles de segurança de desenvolvimento interno que não se destinam a ser liberados em um ambiente de produção. Por exemplo, um desenvolvedor pode incluir acidentalmente uma senha como um comentário em um aplicativo híbrido. Outro exemplo inclui desativar a autenticação de 2 fatores durante o teste.