O documento discute segurança em aplicativos móveis e na web. Ele apresenta estatísticas sobre segurança de dispositivos móveis no Brasil e lista as principais vulnerabilidades segundo o projeto OWASP, incluindo uso indevido de permissões, armazenamento inseguro de dados, injeção de código e falhas de autenticação. O documento também aborda técnicas comuns de ataques e medidas para melhorar a segurança.
4. Algumas estatísticas (2017)
● Brasil tem mais de 8,9 milhões de celulares roubados bloqueados.
● Android é alvo de nova ameaça a cada 10 segundo.
● Smartphones responderam por 59% dos acessos à Internet na América Latina.
● Aumento de 44% nos ataques aos smartphones no Brasil.
https://www.dubsolucoes.com/single-post/estatisticas-de-uso-de-aplicativos-no-Brasil
6. Quanto valem seus dados?
? R$ 12.000,00
Cartão de crédito, logins em serviços de pagamento, pontos de fidelidade, diplomas, carteira de motorista,
passaporte e outros dados comumente roubados valem em média
8. M1 - Uso impróprio da plataforma
Uso indevido de recursos do SO, falha no
controle de segurança da plataforma, uso
indevido de permissões, TouchID, chaves de
acesso ou outros controles de segurança da
plataforma.
9. M2 - Dados armazenados sem segurança
Uso errado do armazenamento de dados assim
como seu vazamento
10. M3 - Comunicação insegura
Abrange problemas de comunicação como SSL,
troca de comunicação ou texto
11. M4 - Autenticação insegura
Implementação incorreta de protocolos de
autenticação permitindo capturas de sessões e
dados do usuário
12. M5 - Criptografía insuficiente
Implementação incorreta de criptografia assim
o app não encripta corretamente. Alguns
protocolos como:
MD4 ou MD5 devem ser evitados.
13. M6 - Falha de autorização
Se o aplicativo não autenticar os usuários em
uma situação em que deveria (por exemplo,
conceder acesso anônimo a algum recurso ou
serviço quando autenticado e acesso
autorizado é necessário), então é uma falha de
autenticação não uma falha de autorização.
14. M7 - Qualidade do código do app
Isso capturaria coisas como transbordamentos
de buffer, vulnerabilidades de string de formato
e vários outros erros de nível de código, onde a
solução é reescrever algum código que esteja
sendo executado no dispositivo móvel.
15. M8 - Adulteração do código
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 os recursos do aplicativo.
16. M9 - Engenharia reversa
Tentar gerar do APK ou app instalado os
códigos binários do App
17. M10 - Funcionalidades escondidas/esquecidas
Por exemplo, um desenvolvedor pode
acidentalmente incluir uma senha como um
comentário em um aplicativo híbrido. Outro
exemplo inclui a desativação da autenticação
de dois fatores durante o teste.
20. M1 - Injection
As falhas de Injeção, tais como injeção de SQL,
de SO (Sistema Operacional) e de LDAP,
ocorrem quando dados não confiavéis são
enviados para um interpretador como parte de
um comando ou consulta. Os dados
manipulados pelo atacante podem iludir o
interpretador para que este execute comandos
indesejados ou permita o acesso a dados não
autorizados.
22. M2 - Quebra de autenticação
As funções da aplicação relacionadas com
autenticação e gerenciamento de sessão
geralmente são implementadas de forma
incorreta, permitindo que os atacantes
comprometam senhas, chaves e tokens de
sessão ou, ainda, explorem outra falha da
implementação para assumir a identidade de
outros usuários.
24. M3 - Exposição de Dados Sensíveis
Muitas aplicações web não protegem
devidamente os dados sensíveis, tais como
cartões de crédito, IDs fiscais e credenciais de
autenticação.
26. M4 - Entidades Externas XML (XXE)
As falhas de Injeção, tais como injeção de SQL,
de SO (Sistema Operacional) e de LDAP,
ocorrem quando dados não confiavéis são
enviados para um interpretador como parte de
um comando ou consulta. Os dados
manipulados pelo atacante podem iludir o
interpretador para que este execute comandos
indesejados ou permita o acesso a dados não
autorizados.
27. Scenario #1: The attacker attempts to extract data
from the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
28. M5 – Quebra de controle de acesso
O atacante descobre esta falha e consegue
acessar funcionalidades e páginas que não tem
acesso
30. M6 – Configuração incorreta de segurança
Uma boa segurança exige a definição de uma
configuração segura e implementada na
aplicação, frameworks, servidor de aplicação,
servidor web, banco de dados e plataforma
31. Servidor de aplicação vem com exemplos que
não são removidos do seu servidor de produção.
Aplicações de exemplo têm falhas de segurança
conhecidas que os atacantes podem usar para
comprometer o seu servidor.
32. M7 – Cross-Site Scripting (XSS)
Falhas XSS ocorrem sempre que uma aplicação
recebe dados não confiáveis e os envia ao
navegador sem validação ou filtro adequados.
33. M8 – Deserialização Insegura
Deserialização geralmente ocorre no server
site, porém quando itentificado o atacante
pode alterar e conseguir privilégios
35. M9 – Uso de componentes com
vulnerabilidades conhecidas
Utilizar, frameworks, bibliotecas
desatualizados e com vulnerabilidades
conhecidas, facilitam o atacante a explorar
estas falhas.
36. M10 – Log e monitoramento insuficientes
Ambas se não implementadas ou insuficiente
implementas, permitem que atacantes passem
um bom tempo em seus servidores explorando
dados, deletados dados...
Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
Um site simplesmente não usa SSL em todas as páginas autenticadas. O atacante simplesmente monitora o tráfego de rede (como uma rede wireless aberta), e rouba o cookie de sessão do usuário. O atacante então reproduz este cookie e sequestra a sessão do usuário, acessando dados privados do mesmo.
Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
Um site simplesmente não usa SSL em todas as páginas autenticadas. O atacante simplesmente monitora o tráfego de rede (como uma rede wireless aberta), e rouba o cookie de sessão do usuário. O atacante então reproduz este cookie e sequestra a sessão do usuário, acessando dados privados do mesmo.
Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
Um site simplesmente não usa SSL em todas as páginas autenticadas. O atacante simplesmente monitora o tráfego de rede (como uma rede wireless aberta), e rouba o cookie de sessão do usuário. O atacante então reproduz este cookie e sequestra a sessão do usuário, acessando dados privados do mesmo.
Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam