Security
Saia do 7x0 com testes de segurança
Hello!
I am Luiz Lohn
QA Engineer
ValtechBrazil
@luizlohn
lohnluiz
Agenda
● Estatísticas e cases
● Segurança em Mobile
● Segurança na Web
● Lanche
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
Falha no MAC
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
OWASP Top 10
Mobile Security Project
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.
M2 - Dados armazenados sem segurança
Uso errado do armazenamento de dados assim
como seu vazamento
M3 - Comunicação insegura
Abrange problemas de comunicação como SSL,
troca de comunicação ou texto
M4 - Autenticação insegura
Implementação incorreta de protocolos de
autenticação permitindo capturas de sessões e
dados do usuário
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.
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.
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.
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.
M9 - Engenharia reversa
Tentar gerar do APK ou app instalado os
códigos binários do App
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.
“
OWASP Top 10
WEB Security Project
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.
http://example.com/app/accountView?id=’or'1'='1
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.
Descobrir a forma de decriptar o token e
manipular-lo
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.
Rouba cookie e reproduz em outra maquina
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.
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>
M5 – Quebra de controle de acesso
O atacante descobre esta falha e consegue
acessar funcionalidades e páginas que não tem
acesso
http://www.testesite.com.br/admin/users
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
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.
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.
M8 – Deserialização Insegura
Deserialização geralmente ocorre no server
site, porém quando itentificado o atacante
pode alterar e conseguir privilégios
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Troca de privilégio
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
M9 – Uso de componentes com
vulnerabilidades conhecidas
Utilizar, frameworks, bibliotecas
desatualizados e com vulnerabilidades
conhecidas, facilitam o atacante a explorar
estas falhas.
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...
O que você pode
fazer?
Thanks!
Any questions?
You can find me at:
◇ @luizlohn
◇ luiz.lohn@gmail.com

Saia do 7x0 com testes de segurança

  • 1.
    Security Saia do 7x0com testes de segurança
  • 2.
    Hello! I am LuizLohn QA Engineer ValtechBrazil @luizlohn lohnluiz
  • 3.
    Agenda ● Estatísticas ecases ● Segurança em Mobile ● Segurança na Web ● Lanche
  • 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
  • 5.
  • 6.
    Quanto valem seusdados? ? 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
  • 7.
    OWASP Top 10 MobileSecurity Project
  • 8.
    M1 - Usoimpró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 - Dadosarmazenados sem segurança Uso errado do armazenamento de dados assim como seu vazamento
  • 10.
    M3 - Comunicaçãoinsegura Abrange problemas de comunicação como SSL, troca de comunicação ou texto
  • 11.
    M4 - Autenticaçãoinsegura Implementação incorreta de protocolos de autenticação permitindo capturas de sessões e dados do usuário
  • 12.
    M5 - Criptografíainsuficiente Implementação incorreta de criptografia assim o app não encripta corretamente. Alguns protocolos como: MD4 ou MD5 devem ser evitados.
  • 13.
    M6 - Falhade 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 - Qualidadedo 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çãodo 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 - Engenhariareversa Tentar gerar do APK ou app instalado os códigos binários do App
  • 17.
    M10 - Funcionalidadesescondidas/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.
  • 18.
  • 19.
    OWASP Top 10 WEBSecurity Project
  • 20.
    M1 - Injection Asfalhas 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.
  • 21.
  • 22.
    M2 - Quebrade 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.
  • 23.
    Descobrir a formade decriptar o token e manipular-lo
  • 24.
    M3 - Exposiçãode 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.
  • 25.
    Rouba cookie ereproduz em outra maquina
  • 26.
    M4 - EntidadesExternas 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: Theattacker 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 – Quebrade controle de acesso O atacante descobre esta falha e consegue acessar funcionalidades e páginas que não tem acesso
  • 29.
  • 30.
    M6 – Configuraçãoincorreta 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çãovem 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-SiteScripting (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çãoInsegura Deserialização geralmente ocorre no server site, porém quando itentificado o atacante pode alterar e conseguir privilégios
  • 34.
  • 35.
    M9 – Usode componentes com vulnerabilidades conhecidas Utilizar, frameworks, bibliotecas desatualizados e com vulnerabilidades conhecidas, facilitam o atacante a explorar estas falhas.
  • 36.
    M10 – Loge monitoramento insuficientes Ambas se não implementadas ou insuficiente implementas, permitem que atacantes passem um bom tempo em seus servidores explorando dados, deletados dados...
  • 38.
    O que vocêpode fazer?
  • 39.
    Thanks! Any questions? You canfind me at: ◇ @luizlohn ◇ luiz.lohn@gmail.com

Notas do Editor

  • #5 GDPR Lei brasileira Checkin
  • #6 LATAM CHECK-IN
  • #16 adulteração de código
  • #18 adulteração de código
  • #21 Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
  • #26 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.
  • #27 Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
  • #29 Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
  • #32 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.
  • #33 Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam
  • #35 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.
  • #36 Os dados enganam a enginee e fazem eles mostrarem dados que nao podiam