owasp mobile top 10

OWASP Mobile Top 10

[Principais Riscos no Desenvolvimento Seguro de Aplicações Móveis]

@pontocom

[email protected]@iscte.pt

http://www.linkedin.com/in/carlosserrao

Aplicação

Client-Side Client-Side

HardwarePlataforma

Rede

Server-Side

Servidor Datacenter

Cloud

Ameaças e Vulnerabilidades

Mobile Security ProjectComeçou no 3Q de 2010

Porquê?

Riscos de Segurança diferentes e únicos

Objectivo?

Envolver a segurança no ciclo de desenvolvimento de aplicações mobile

Threat Model

Dev. Guide

Training

Controls

Risks

Secure Libraries

Methodologies

Tools

Cheat Sheets

M1 - Weak Server-Side Controls

M3 - Insufficient Transport Layer Security

M5 - Poor Authorization and Authentication

M7 - Client Side Injection

M9 - Improper Session Handling

M2 - Insecure Data Storage

M6 - Broken Cryptography

M4 - Unintended Data Leakage

M8 - Security Decisions Via Untrusted Inputs

M10 - Lack of Binary Protections

Riscos do Top 10Independente da plataforma

Focada em áreas de risco do em vez de vulnerabilidades individuais

Definida usando a Metodologia de Risco da OWASP

Contribuido pela comunidade


Aplica-se aos serviços de backend

Não é específica para a plataforma mobile, mas é essencial

Não é possível confiar cegamente no cliente

Avaliar com cuidado os controlos de segurança implementados no backend

Impacto:

Perda de confidencialidade dos dados

Integridade dos dados


OWASP Top 10 OWASP Cloud Top 10

Prevenção:

Perceber os riscos adicionais que as aplicações móveis introduzem nas arquitecturas existentes

Usar o know-how existente na proteção destas plataformas

OWASP Web Top 10, Cloud Top 10, Web Services Top 10

Recorrer a “cheat sheets”, guias de desenvolvimento, ESAPI


Dados sensíveis que não são protegidos

Aplica-se a dados armazenados localmente e dados sincronizados com a cloud

Resultam de:

Não cifrar os dados

Efectuar cache de dados quando não se pretende usar a mesma para armazenamento a longo prazo

Permissões fracas ou globais

Não usar as melhores práticas aplicadas às comunidades


Impacto:

Confidencialidade e perda de dados

Credenciais comprometidas

Violações de privacidade

Não-compliance

Prevenção:

Armazenar APENAS aquilo que é absolutamente necessário

Nunca usar áreas de armazenamento públicas (SD Card)

Usar contentores seguros de informação e usar as APIs de segurança e cifra oferecidas pela plataforma

Não conceder permissões de leitura e de escrita demasiado permissivas (acesso para todos)


Falta de encriptação dos dados transmitidos

Dados em trânsito recorrendo a mecanismos de encriptação fracos

Usando criptografia forte mas que ignora avisos de segurança

Ignorar erros de validação de certificados

Usar transmissão em claro após detectar falhas

Impacto:

MITM

Alteração de dados em transito

Perda de confidencialidade de dados


Prevenção:

Assegurar que todos os dados sensíveis que deixam o dispositivos estão encriptados

Incluem-se todos os dados enviados através da rede do provedor de serviço, WiFi e até NFC

Quando ocorrem exceções de segurança é uma boa prática NÃO AS IGNORAR


Resulta da não desactivação de algumas funcionalidades da plataforma e algumas falhas de programação

Dados sensíveis que vão parar a sítios menos próprios:

Caches Web

Log de keystrokes

Screenshots (i.e. iOS background apps)

Logs (sistema, crash)

Directorias temporárias

Perceber o que fazem librarias de terceiros nas aplicações com os dados dos utilizadores, antes de as usar (rede de anúncios, analytics, etc.)

Impacto:

Retenção de dados de forma infinita

Violações de privacidade


Nunca guardar informação sensível em logs

Remover dados sensíveis de “screenshots”, desactivar logs de teclados, e utilizar directivas anti-cache para conteúdo web

Efectuar debug das aplicações antes de as lançar no mercado para perceber quais os ficheiros criados, escritos ou modificados ao longo da sua operação

Rever com cuidados todas as bibliotecas de terceiros usadas na aplicação

Testar a aplicação em múltiplas plataformas (o mais possível)


EM parte relacionada com a parte móvel, outra relacionada com a arquitectura

Algumas “apps” dependem em exclusivo de valores imutáveis e potencialmente comprometidos (IMEI, IMSI, UUID)

Alguns identificadores de hardware persistem mesmo depois de serem feitas limpezas ao dispositivo ou “factory resets”

É possível adicionar alguma informação contextual mas não é à prova e falhas

Impacto:

Escalar privilégios

Acesso não-autorizado


Prevenção:

A informação contextual pode ser usada para resolver esta situação, mas deve ser usada em conjunto com factores de múltipla autenticação

Nunca usar o ID do dispositivo ou ID de subscritor como único autenticador


Duas principais categorias

Más implementações usando bibliotecas criptográficas fortes

Cifras desenvolvidas “à medida”, mas facilmente quebráveis

Encoding, Ofuscação e Serialização != Encriptação

Impacto:

Perda da confidencialidade dos dados

Escalara privilégios

Ultrapassar a lógica de negócio


Armazenar a chave com os dados cifrados - não serve para nada

Preferir SEMPRE usar bibliotecas criptográficas testadas, do que escrever a sua própria biblioteca

Tirar partido daquilo que a plataforma já oferece!


Aplicações que usam bibliotecas de browsers

Web apps puras

Apps Web/Nativas híbridas

Ataques típicos:

XSS e HTML Injection

SQL Injection

Novos ataques:

Abusar do “phone dialer” + SMS

Abusar de pagamentos “in-app”

Impacto:

Compromisso do dispositivo



Prevenção:

“Sanitizar" e tratar dados “untrusted” antes de os mostrar ou executar

Usar “prepared statements” para chamadas a base de dados - não resolve todos os problemas mas limita alguns

Minimizar as capacidades nativas que estão relacionadas com a parte da funcionalidade Web


Podem ser usados para efectuar o “bypass” de permissões e modelos de segurança

Dependem da plataforma

iOS - Abusar dos URL Schemes

Android - Abusar dos Intents

Vários vectores de ataque:

Aplicações maliciosas

Client-side Injection

Impacto:

Consumir recursos pagos

Extração de dados



Prevenção:

Verificar as permissões de quem invoca e os input dos mesmos

Pedir mais permissões ao utilizador antes de permitir as chamadas

Quando as verificações de permissão não puderem ser realizadas, assegurar que têm que ser executados passos adicionais para realizar ações que possam ser sensíveis










M10 - Lack of Binary ProtectionsM9 - Improper Session Handling

As sessões nas aplicações móveis são geralmente muito mais longas

Porquê? Conveniência e por usabilidade

Aplicações mantém as sessões através de:

HTTP cookies

OAuth tokens

Serviços de autenticação SSO

Péssima ideia = usar um identificador do dispositivo como um token de sessão

Impacto:


Acesso não-autorizado

Ultrapassar licenciamentos e pagamentos


Prevenção:

Não ter medo de fazer os utilizadores autenticarem-se mais frequentemente

Assegurar que os tokens podem ser revogados rapidamente no caso do dispositivo ter sido perdido ou roubado

Usar entropia para gerar tokens seguros


Um adversário vai procurar efectuar “reverse engineering” do código da aplicação móvel, para a modificar e realizar alguma funcionalidade obscura.

Pode alguém desencriptar o código desta app (iOS)

Pode alguém efectuar reverse engineering da app (dex2jar, p.e.)

Pode alguém visualizar o fluxo ou pseudo-código da aplicação

Pode alguém modificar a layer de apresentação e tratar de injectar código Javascript na pp

Pode alguém modificar o binário da aplicação usando um editor e mesmo assim efectuar bypass do do controlo de segurança

Impacto:

Confidencialidade e privacidade

Roubo de propriedade intelectual

Comportamento malicioso da aplicação.


Prevenção:

Deteção de jailbreak, controlos de checksum, deteção de debuggers, etc.

Ter a certeza que vamos o binário não foi modificado e que as proteções da plataforma garantem a integridade do mesmo.


www.owasp.org

http://www.owasp.org

OWASP Mobile Top 10

[Principais Riscos no Desenvolvimento Seguro de Aplicações Móveis]

owasp mobile top 10

Software