OWASP - MASVS-v1 4 2-ptbr

(Brazilian Portuguese Translation)
Version v1.4.2
OWASP Mobile Application Security Verification Standard
Version v1.4.2 January 20, 2022

OWASP Mobile Application Security Verification Standard v1.4.2
Índice
Prefácio 5
Sobre o Padrão 8
Direitos de Uso e Licença . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Patrocinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
O Padrão de Verificação de Segurança de Aplicativos Móveis 12

Modelo de Segurança para um Aplicativo Móvel . . . . . . . . . . . . . . . . . 12
Avaliação e Certificação 17
Posição da OWASP sobre Certificações e Marcas de Confiança do MASVS . . . . 17
Orientação para Certificação de Aplicativos Móveis . . . . . . . . . . . . . . . 17
Outros Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
V1: Requisitos de Arquitetura, Design e Modelagem de Ameaças 20

Objetivo do Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Requisitos de Verificação de Segurança . . . . . . . . . . . . . . . . . . . . . 20
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
V2: Requisitos de Armazenamento de Dados e Privacidade 23

Requerimentos de Verificação de Segurança . . . . . . . . . . . . . . . . . . . 23
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
V3: Requisitos de Criptografia 27

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
V4: Requisitos de Autenticação e Gerenciamento de Sessão 29

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
V5: Requisitos de Comunicação de Rede 32

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
V6: Requisitos de Interação com a Plataforma 34

Objetivo de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
V7: Requisitos de Qualidade de Código e Configuração do Compilador 37

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
V8: Requisitos de Resiliência 40

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Apêndice A: Glossário 44
Apêndice B: Referências 47
Controle de Alterações 48
V1.3 - 13 May 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
V1.2 - 7 de Março de 2020 - Versão Internacional . . . . . . . . . . . . . . . . 48
V1.2-RC - 5 de Outubro de 2019 - Pré-versão (apenas Inglês) . . . . . . . . . . 48
V1.1.4 - 4 de Julho de 2019 - Edição Summit . . . . . . . . . . . . . . . . . . . 49
V1.1.3 - 9 de Janeiro de 2019 - Correções Menores . . . . . . . . . . . . . . . 49
V1.1.2 - 3 de Janeiro de 2019 - Patrocínio e Internacionalização . . . . . . . . . 50
V1.1.0 - 14 de Julho de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
V1.0 - 12 de Janeiro de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4
Prefácio
Revoluções tecnológicas podem acontecer rapidamente. Há menos de uma década,

smartphones eram dispositivos desajeitados com pequenos teclados - brinquedos caros
para usuários empresariais com conhecimento em tecnologia. Hoje, os smartphones são
uma parte essencial de nossas vidas. Passamos a confiar neles para obter informações,
navegação e comunicação, e estão presentes tanto nos negócios quanto em nossa vida
social.
Toda nova tecnologia introduz novos riscos de segurança, e manter-se em dia com es-
sas mudanças é um dos principais desafios que a indústria de segurança enfrenta. O
lado defensivo está sempre alguns passos atrás. Por exemplo, a consequência padrão
para muitos foi aplicar velhas formas de fazer as coisas: smartphones são como pe-
quenos computadores e os aplicativos móveis são como programas de computadores
clássicos, então, certamente, os requisitos de segurança são similares? Mas não fun-
ciona desta forma. Os sistemas operacionais dos smartphones são diferentes dos de
computadores de mesa, e os aplicativos móveis são diferentes dos aplicativos web. Por
exemplo, o método clássico de escaneamento de vírus baseado em assinaturas não faz
sentido nos sistemas operacionais para dispositivos móveis modernos: não somente são
incompatíveis com o modelo de distribuição de aplicativos móveis, mas também é tecni-
camente impossível devido às restrições de isolamento de execução de aplicativos. Além
disso, algumas classes de vulnerabilidades, como estouro de buffer e problemas de XSS,
são menos relevantes no contexto padrão de aplicativos móveis do que, por exemplo,
para aplicativos para computadores e para web (com exceções).
Ao longo do tempo, nossa indústria tem conseguido um melhor controle no cenário de

ameaças aos dispositivos móveis. Como se vê, a segurança móvel tem tudo a ver com
proteção de dados: aplicativos armazenam informações pessoais, fotos, gravações, ano-
tações, dados de contas, informações de negócios, localização e muito mais. Elas atuam
como clientes, que nos conectam a serviços que utilizamos diariamente, e como centros
de comunicação que processam todas, e cada uma das mensagens que trocamos com
outras pessoas. Comprometer o smartphone de uma pessoa é obter acesso ilimitado à
sua vida. Quando consideramos que dispositivos móveis são perdidos e roubados mais
facilmente, e que os malwares para eles estão aumentando, a necessidade de proteção
de dados se torna ainda mais evidente.
Um padrão de segurança para aplicativos móveis deve, portanto, focar em como eles
gerenciam, armazenam e protegem informações sensíveis. Embora os sistemas opera-
cionais móveis modernos, como iOS e Android, ofereçam boas APIs para armazenamento
seguro de dados e comunicação, eles precisam ser implementados e usados correta-
mente para serem efetivos. O armazenamento de dados, a comunicação entre aplica-
tivos, o uso correto de APIs criptográficas e a comunicação segura pela rede são apenas
alguns dos aspectos que requerem uma cuidadosa consideração.
5
Uma importante questão, que requer o consenso da indústria, é até que ponto se deve ir
para proteger a confidencialidade e a integridade dos dados. Por exemplo, a maioria de
nós concorda que um aplicativo móvel deveria verificar o certificado do servidor em uma
conexão TLS. Mas e o SSL certificate pining? Não implementá-lo não resultaria em uma
vulnerabilidade? Isso deveria ser um requisito se o aplicativo móvel trata dados sensíveis
ou isso seria contraproducente? Deveríamos criptografar os dados armazenados em
banco de dados SQLite, mesmo que o sistema operacional execute o aplicativo de forma
isolada? O que é apropriado para um aplicativo móvel pode não ser realista para outro.
O MASVS é uma tentativa de padronizar esses requisitos usando níveis de verificação
que se ajustam aos diferentes cenários de ameaça.
Além disso, o surgimento de malware de root e ferramentas de administração remota

criou consciência de que os próprios sistemas operacionais móveis têm falhas, portanto
as estratégias de isolamento de execução são cada vez mais utilizadas como um esforço
adicional de proteção a dados sensíveis e de prevenção de manipulação de dados no lado
do cliente. E é aí que as coisas complicam. As características de segurança por hardware
e as soluções de isolamento em nível de sistema operacional, como o Android for Work e
Samsung Knox, existem, mas não estão sempre disponíveis nos diferentes dispositivos.
Uma forma de minimizar o problema é implementar medidas de proteção baseadas em
software - mas, infelizmente, não há padrões ou processos de teste para verificar esses
tipos de proteção.
Como resultado, os relatórios de testes de segurança de aplicativos móveis estão por

toda parte: por exemplo, alguns relatam falta de ofuscação ou de detecção de root em
um aplicativo Android como uma “falha de segurança”. Por outro lado, medidas como
cifragem de strings, detecção de depuradores ou ofuscação de fluxo de controle não são
consideradas obrigatórias. Entretanto, essa maneira binária de olhar para as coisas não
faz sentido porque a resiliência não é uma proposta automática: depende das ameaças
específicas que pretende-se defender no lado do cliente.
O objetivo geral do MASVS é oferecer uma linha base para segurança de aplicativos
móveis (MASVS-L1), enquanto também permite a inclusão de medidas profundas de de-
fesa (MASVS-L2) e proteções contra as ameaças no lado do cliente (MASVS-R). O MASVS
visa a atingir o seguinte:
• Prover requisitos para arquitetos e desenvolvedores de software que buscam desen-

volver aplicativos móveis seguros;
• Oferecer um padrão da indústria que poderá ser usado nas revisões de segurança
de aplicativos móveis;
• Esclarecer o papel dos mecanismos de proteção de software e fornecer requisitos
para verificar sua eficácia;
• Fornecer recomendações específicas com relação ao nível de segurança recomen-
dado para diferentes casos de uso.
6
Nós estamos conscientes de que é impossível alcançar um consenso de 100% na in-

dústria. Contudo, esperamos que o MASVS seja útil para fornecer orientação nas fases
de desenvolvimento e testes de aplicativos móveis. Como padrão de código aberto, o
MASVS evoluirá com o tempo e nós agradecemos qualquer contribuição e sugestão.
Por Bernhard Mueller
7
Sobre o Padrão
Bem-vindo ao Padrão de Verificação de Segurança de Aplicativos Móveis (MASVS). O

MASVS é um esforço comunitário para estabelecer um framework de requisitos de se-
gurança necessários para projetar, desenvolver e testar aplicativos móveis seguros no
iOS e Android.
O MASVS é o resultado de esforços da comunidade e do retorno da indústria. Esperamos

que esse padrão evolua com o tempo e recebamos retorno da comunidade.
A melhor forma de entrar em contato com a gente é por meio do canal OWASP para
Dispositivos Móveis: https://owasp.slack.com/messages/project-mobile_omtg/details/.
Contas podem ser criadas a partir da seguinte URL: https://owasp.slack.com/join/share

d_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/.
Direitos de Uso e Licença
Copyright © 2021 The OWASP Foundation. Este documento é licenciado sob a licença
Creative Commons Attribution-ShareAlike 4.0 International License. Para qualquer reuso
ou redistribuição, você deve deixar claro os termos de licença deste trabalho.
Agradecimentos
8
Líderes de Projeto Autor Colaboradores e Revisores

Principal
Sven Schleier and Bernhard Alexander Antukh, Mesheryakov Aleksey, Elderov Ali,
Carlos Holguera Mueller, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de
Sven Boer, Damien Clochard, Ben Cheney, Will Chilcutt,
Schleier, Stephen Corbiaux, Manuel Delgado, Ratchenko
Jeroen Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner,
Willem- Anton Glezman, Josh Grossman, Sjoerd Langkemper,
sen and Vinícius Henrique Marangoni, Martin Marsicano,
Carlos Roberto Martelloni, @PierrickV, Julia Potapenko,
Holguera Andrew Orobator, Mehrad Rafii, Javier Ruiz, Abhinav
Sejpal, Stefaan Seys, Yogesh Sharma, Prabhant
Singh, Nikhil Soni, Anant Shrivastava, Francesco
Stillavato, Abdessamad Temmar, Pauchard Thomas,
Lukasz Wierzbicki
Linguagem Tradutores e Revisores
Alemão Rocco Gränitz, Sven Schleier (Revisão)
Chinês Bob Peng, Harold Zang, Jack S

(Simplificado)
Chinês Peter Chi, and Lex Chien, Henry Hu, Leo Wang
(Tradicional)
Coreano Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung
Espanhol Martin Marsicano, Carlos Holguera
Francês Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Revisão)
Hindi Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra
Kumar Sinha, Vikrant Shah
Japonês Koki Takeyama, Riotaro Okada (Revisão)
Persa Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari,

Mahsa Omidvar, Alireza Mazhari
Português Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia
Dias
9
Linguagem Tradutores e Revisores
Português Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza,

(Brasileiro) Fernando Galves
Russo Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Revisão), Oprya

Egor (Revisão), Tereshin Dmitry (Revisão)
Este documento começou como um fork do Padrão de Verificação de Segurança de Aplica-

tivos Móveis da OWASP escrito por Jim Manico.
Patrocinadores
Ainda que tanto o MASVS quanto o MSTG tenham sido criados e mantidos pela comu-
nidade de forma voluntária, às vezes é necessária uma pequena ajuda externa. Nós, por-
tanto, agradecemos nossos patrocinadores por proverem fundos para poder contratar
editores técnicos. Ressalta-se que esses patrocínios não influenciam no conteúdo do
MASVS ou MSTG de maneira alguma. Os pacotes de patrocínio estão descritos em OWASP
Project Wiki.
God Mode
OWASP MSTG
OWASP Bay Area Chapter
Honorable Benefactor
OWASP MSTG
OWASP MSTG
Good Samaritan
OWASP MSTG
10
Também gostaríamos de agradecer o Capítulo OWASP da Bay Area por seu patrocínio.
Por fim, gostaríamos de agradecer a todos que compraram o livro no Leanpub e nos
patrocinaram dessa maneira.
11
O Padrão de Verificação de Segurança de

Aplicativos Móveis
O MASVS pode ser utilizado para estabelecer um nível de confiança na segurança de

aplicativos móveis. Os requisitos foram desenvolvidos com base nos seguintes obje-
tivos:
• Utilize como uma métrica - Para fornecer um padrão de segurança que possa facilitar
o comparativo entre aplicativos móveis atuais por desenvolvedores e proprietários
de aplicativos.
• Utilize como orientação - Para fornecer orientação durante todas as fases do desen-
volvimento e teste de aplicativos para dispositivos móveis.
• Utilize no processo de aquisição - Para fornecer uma linha de base para a verificação
de segurança dos aplicativos móveis.
Modelo de Segurança para um Aplicativo Móvel
O MASVS define dois níveis de verificação de segurança (MASVS-L1 e MASVS-L2), as-

sim como um conjunto de requisitos de resiliência a engenharia reversa (MASVS-R). O
MASVS-L1 contém requisitos básicos de segurança recomendados para todos os tipos de
aplicativos para dispositivos móveis, enquanto o MASVS-L2 deve ser utilizado em aplica-
tivos que manipulam dados altamente confidenciais. O MASVS-R abrange controles de
proteção adicionais que podem ser aplicados se um dos objetivos do projeto for a pre-
venção de ameaças do lado do usuário.
Cumprir os requisitos do MASVS-L1 resulta em uma aplicação segura que segue as mel-
hores práticas de segurança recomendadas e não sofre com vulnerabilidades mais co-
muns. O MASVS-L2 adiciona mais controles de defesa em profundidade como SSL Pin-
ning, resultando em um aplicativo resistente a ataques mais complexos, assumindo que
os controles de segurança do sistema operacional móvel estejam intactos e que o usuário
não seja visto como um atacante em potencial. O cumprimento de todos ou de um sub-
conjunto dos requisitos de proteção de software no MASVS-R ajuda a mitigar ameaças
específicas no lado do cliente quando o usuário final é malicioso e/ou o sistema opera-
cional móvel esteja comprometido.
I: Embora seja recomendado implementar controles MASVS-L1 em todos os

aplicativos, a implementação ou não de um controle deve, em última opção,
ser uma decisão tomada baseada em riscos e comunicada aos proprietários da
empresa.
II: Observe que os controles de proteção de software listados no MASVS-R e de-

scritos no OWASP Mobile Security Testing Guide podem ser ignorados e nunca
12
devem ser usados como substitutos de controles adicionais de proteção e es-

pecíficos para ameaças a aplicativos que também atendem aos requisitos do
MASVS no MASVS-L1 ou MASVS-L2.
Estrutura do Documento
A primeira parte do MASVS contém uma descrição do modelo de segurança e os níveis

de verificação disponíveis, seguidos de indicações sobre como usar o padrão na prática.
Os requisitos de segurança detalhados, juntamente com um mapeamento para os níveis
de verificação, estão listados na segunda parte. Os requisitos foram agrupados em oito
categorias (V1 a V8) com base no objetivo/escopo técnico. A nomenclatura a seguir é
usada em todo o MASVS e MSTG:
• Categoria de Requisito: MASVS-Vx, ex. MASVS-V2: Armazenamento de Dados e

Privacidade.
• Requisito: MASVS-Vx.y, e.g. MASVS-V2.2: “Nenhum dado sensível é escrito nos logs
da aplicação.”.
Níveis de Verificação Detalhados
MASVS-L1: Padrão de Segurança
Um aplicativo móvel que alcança o MASVS-L1 adere às práticas recomendadas de segu-

rança de aplicativos móveis. Ele preenche requisitos básicos em termos de qualidade de
código, manuseio de dados confidenciais e interação com o ambiente móvel. Um pro-
cesso de teste deve estar em vigor para verificar os controles de segurança. Este nível
é apropriado para todas as aplicações móveis.
13
MASVS-L2: Defesa em Profundidade
O MASVS-L2 introduz controles avançados de segurança que vão além do requisito

padrão. Para cumprir o MASVS-L2, um modelo de ameaça deve existir e a segurança
deve ser parte integrante da arquitetura e do design do aplicativo. Com base no modelo
de ameaça, os controles adequados do MASVS-L2 deveriam ter sido selecionados e
implementados com sucesso. Este nível é apropriado para aplicativos que lidam com
dados altamente sensíveis, como aplicativos bancários para dispositivos móveis.
MASVS-R: Resiliência contra Engenharia Reversa e Adulteração
O aplicativo tem segurança de última geração e também é resistente contra ataques

específicos e claramente definidos do lado do usuário como adulteração, modificação ou
engenharia reversa utilizados para extrair códigos ou dados confidenciais. Tal aplicativo
aproveita dos recursos de segurança de hardware ou técnicas de proteção de software
suficientemente fortes e verificáveis. O MASVS-R é aplicável a aplicativos que lidam com
dados altamente confidenciais e pode servir como um meio de proteger a propriedade
intelectual ou dificultar a adulteração de um aplicativo.
Uso Recomendado
O nível de aderência dos aplicativos pode ser verificado no MASVS L1 ou L2 com base na
avaliação prévia de risco e no nível total de segurança necessário. L1 é aplicável a to-
dos os aplicativos móveis, enquanto L2 é geralmente recomendado para aplicativos que
lidam com dados e/ou funcionalidades mais sensíveis. O MASVS-R (ou partes dele) pode
ser aplicado para verificar a resiliência contra ameaças específicas como repackaging ou
extração de dados confidenciais, além de uma verificação de segurança adequada.
Em resumo, os seguintes tipos de verificação estão disponíveis:
• MASVS-L1
• MASVS-L1+R
• MASVS-L2
• MASVS-L2+R
As diferentes combinações refletem diferentes graus de segurança e resiliência. O obje-

tivo é permitir flexibilidade: por exemplo, um jogo desenvolvido para dispositivo móvel
pode não justificar a inclusão de controles de segurança MASVS-L2 como autenticação
de 2 fatores por razões de usabilidade, mas tem uma forte necessidade de negócios para
prevenção de adulteração.
Qual Tipo de Verificação Escolher
14
A implementação dos requisitos do MASVS L2 aumenta a segurança, ao mesmo tempo

em que aumenta o custo de desenvolvimento e potencialmente piora a experiência do
usuário final (o trade-off clássico). Em geral, o L2 deve ser usado para aplicativos sempre
que fizer sentido a partir de uma perspectiva de risco versus custo (ou seja, onde a perda
potencial causada por um compromisso de confidencialidade ou integridade é maior do
que o custo incorrido pelos controles de segurança adicionais). Uma avaliação de risco
deve ser o primeiro passo antes da aplicação do MASVS.
Exemplos
MASVS-L1
• Todos os aplicativos móveis. O MASVS-L1 lista práticas recomendadas de segurança

que podem ser seguidas com um impacto razoável no custo de desenvolvimento e
na experiência do usuário. Aplique os requisitos no MASVS-L1 para qualquer aplica-
tivo que não se qualifique para um dos níveis mais altos.
MASVS-L2
• Indústria de Saúde: Aplicativos móveis que armazenam informações pessoais identi-

ficáveis que podem ser usadas para roubo de identidade, pagamentos fraudulentos
ou uma variedade de esquemas de fraude. Para o setor de saúde dos EUA, as con-
siderações de conformidade incluem a Lei de Portabilidade e Responsabilização de
Seguros de Saúde (HIPAA, em inglês), Privacidade, Segurança, Regras de Notificação
de Violações e Regra de Segurança do Paciente.
• Indústria Financeira: Aplicativos que permitem o acesso a informações altamente

sensíveis como números de cartão de crédito, informações pessoais ou permitem
que o usuário mova fundos. Esses aplicativos garantem controles adicionais de se-
gurança para evitar fraudes. Os aplicativos financeiros precisam garantir a conformi-
dade com o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento
(PCI DSS), atos Gramm Leech Bliley e Sarbanes-Oxley (SOX).
MASVS L1+R
• Aplicativos móveis onde a proteção da Propriedade Intelectual (IP) é um objetivo

comercial. Os controles de resiliência listados no MASVS-R podem ser usados para
aumentar o esforço necessário para obter o código fonte original e para impedir a
adultareão / cracking.
• Indústria de Jogos: Jogos com uma necessidade essencial para evitar modificações
e trapaças, como jogos online competitivos. Trapacear é uma questão importante
nos jogos online, já que uma grande quantidade de usuários trapaceiros leva a uma
base de jogadores descontentes e pode, em última instância, fazer com que um
jogo perca usuários e acabe perdendo popularidade. O MASVS-R fornece controles
15
básicos contra adulteração para ajudar a aumentar o esforço que os trapaceiros

terão.
MASVS L2+R
• Indústria Financeira: Aplicativos bancários online que permitem ao usuário movi-

mentar fundos, onde técnicas como injeção de código e instrumentação em dispos-
itivos comprometidos representam um risco. Nesse caso, os controles do MASVS-R
podem ser usados para impedir a adulteração, aumentando a complexidade para
desenvolvedores de malware.
• Todos os aplicativos móveis que por design precisam armazenar dados confidenciais
no dispositivo móvel e, ao mesmo tempo, devem suportar uma ampla gama de dis-
positivos e versões do sistema operacional. Nesse caso, os controles de resiliência
podem ser usados como uma medida de defesa em profundidade para aumentar o
esforço dos atacantes com o objetivo de extrair os dados confidenciais.
• Aplicativos que possuem compras no neles devem usar os controles do lado do servi-
dor e do MASVS-L2 para proteger o conteúdo pago. No entanto, pode haver casos
em que não há possibilidade de usar proteção do lado do servidor. Nesses casos,
os controles MASVS-R devem ser aplicados adicionalmente, a fim de aumentar a
dificuldade de realizar engenharia reversa e/ou adulteração.
16
Avaliação e Certificação
Posição da OWASP sobre Certificações e Marcas de Confiança do

MASVS
A OWASP, como uma organização neutra e sem fins lucrativos, não certifica nenhum
fornecedor, testador ou software.
Todas essas afirmações de garantia, marcas de confiança ou certificações não são oficial-
mente examinadas, registradas ou certificadas pela OWASP. Portanto, uma organização
que dependa de tal visão precisa ser cautelosa com a confiança depositada em qualquer
órgão terceirizado ou certificado de confiança (M)ASVS.
Isso não deve dificultar as organizações de oferecer tais serviços de garantia, desde que
não reivindiquem a certificação Oficial OWASP.
Orientação para Certificação de Aplicativos Móveis
A maneira recomendada de verificar a conformidade de um aplicativo móvel com o

MASVS é realizando uma revisão do tipo “open book”, o que significa que os testadores
têm acesso a recursos-chave, como arquitetos e desenvolvedores do aplicativo, docu-
mentação do projeto, código-fonte e acesso autenticado a terminais, incluindo acesso a
pelo menos uma conta de usuário para cada função.
É importante notar que o MASVS abrange apenas a segurança do aplicativo móvel (lado
do cliente) e a comunicação de rede entre o aplicativo e seus terminais remotos, bem
como alguns requisitos básicos e genéricos relacionados à autenticação do usuário e
gerenciamento de sessões. Ele não contém requisitos específicos para os serviços remo-
tos (por exemplo, serviços web) associados ao aplicativo, além de um conjunto limitado
de requisitos genéricos relativos à autorização, autenticação, verificação de controle e
gerenciamento de sessões. No entanto, o MASVS V1 especifica que os serviços remotos
devem estar seguros usando o modelo global de ameaças e devem ser analisados em
relação à utilização dos padrões apropriados como o OWASP ASVS.
Uma organização certificadora deve incluir em qualquer relatório o escopo da verificação

(particularmente se um componente-chave estiver fora do escopo), um resumo dos resul-
tados de verificação, incluindo testes aprovados e reprovados, com indicações claras de
como corrigir os testes em que houve falha. Manter documentação detalhada, captura
de tela ou vídeo, scripts para explorar de forma confiável e repetidamente um problema
e registros eletrônicos de testes, como interceptar registros de logs de um proxy e no-
tas associadas, como uma lista de limpeza, é considerada prática padrão do setor. Não
basta simplesmente executar uma ferramenta e relatar as falhas; isso não fornece ev-
idências suficientes de que todas as questões em nível de certificação foram testadas e
17
testadas minuciosamente. Em caso de contestação, deve haver evidências suficientes

para demonstrar que todos os requisitos verificados foram de fato testados.
Usando o Guia de Testes de Segurança Móvel (MSTG) da OWASP
O OWASP MSTG é um manual para testar a segurança dos aplicativos móveis. Descreve
os processos técnicos para verificar os requisitos listados no MASVS. O MSTG inclui uma
lista de casos de teste, cada um dos quais mapeia para um requisito no MASVS. Embora
os requisitos do MASVS sejam de alto nível e genéricos, o MSTG fornece recomendações
e procedimentos de teste em profundidade por sistema operacional móvel.
O papel das Ferramentas Automatizadas de Teste de Segurança
O uso de escâneres de código-fonte e ferramentas de teste de caixa preta é incentivado a

fim de aumentar a eficiência, sempre que possível. No entanto, não é possível concluir a
verificação do MASVS usando apenas ferramentas automatizadas: cada aplicativo móvel
é diferente e entender a arquitetura geral, a lógica de negócios e os artifícios técnicos das
tecnologias e frameworks específicos que estão sendo usados é um requisito obrigatório
para verificar a segurança do aplicativo.
Outros Usos
Como Orientação Detalhada da Arquitetura de Segurança
Um dos usos mais comuns para o Padrão de Verificação de Segurança de Aplicativos

Móveis é a utilização como um recurso para arquitetos de segurança. As duas princi-
pais estruturas de arquitetura de segurança, SABSA ou TOGAF, carecem de uma grande
quantidade de informações necessárias para concluir as avaliações de arquitetura de se-
gurança de aplicativos móveis. O MASVS pode ser usado para preencher essas lacunas,
permitindo que arquitetos de segurança escolham melhores controles para problemas
comuns em aplicativos móveis.
Como Substituto para Checklists de Desenvolvimento Seguro de Aplicativos

Móveis
Muitas organizações podem se beneficiar da adoção do MASVS, escolhendo um dos dois

níveis, ou fazendo seu próprio fork do MASVS e alterando o que for necessário para
o contexto e o nível de risco de cada aplicativo. Nós estimulamos esse tipo de fork
enquanto a rastreabilidade for mantida, de modo que se um aplicativo cumprir o requisito
4.1, o mesmo ocorra nos forks do padrão à medida que ele evolui.
18
Como Base para Metodologias de Testes de Segurança
Uma boa metodologia de teste de segurança de aplicativos móveis deve cobrir todos
os requisitos listados no MASVS. O Guia de Teste de Segurança Móvel OWASP (MSTG)
descreve os casos de teste de caixa preta e caixa branca para cada requisito de verifi-
cação.
Como Guia para Testes Automatizados de Unidade e Integração
O MASVS foi projetado para ser altamente testável, com a única exceção dos requisitos
de arquitetura. Os testes automatizados unitários, integração e aceitação com base nos
requisitos do MASVS podem ser integrados ao ciclo de vida de desenvolvimento contínuo.
Isso não só aumenta a consciência de segurança do desenvolvedor, mas também mel-
hora a qualidade geral dos aplicativos resultantes e reduz a quantidade de descobertas
durante os testes de segurança na fase prévia ao release.
Para Treinamento de Desenvolvimento Seguro
O MASVS também pode ser usado para definir características de aplicativos móveis se-
guros. Muitos cursos de “desenvolvimento seguro” são simplesmente cursos de ethical
hacking com poucas dicas de codificação segura. Isso não ajuda os desenvolvedores.
Em vez disso, cursos de desenvolvimento seguro podem usar o MASVS, com um forte
foco nos controles proativos documentados no MASVS, em vez de, por exemplo, os 10
principais problemas de segurança de desenvolvimento.
19
V1: Requisitos de Arquitetura, Design e

Modelagem de Ameaças
Objetivo do Controle
Em um mundo perfeito, a segurança seria considerada em todas as fases do desenvolvi-

mento. Na realidade, porém, a segurança geralmente é apenas uma consideração em
uma fase tardia no SDLC. Além dos controles técnicos, o MASVS exige que os processos
estejam em um local que garanta que a segurança tenha sido explicitamente abordada
ao planejar a arquitetura do aplicativo móvel e que as funções funcionais e de segu-
rança, de todos os componentes, sejam conhecidas. Como a maioria dos aplicativos
móveis atua como clientes de serviços remotos, deve-se assegurar que os padrões de
segurança adequados também são aplicadas a esses serviços, não bastando testar o
aplicativo móvel isoladamente.
A categoria “V1” lista os requisitos referentes à arquitetura e design do aplicativo. Como

tal, esta é a única categoria que não é mapeada para casos de testes técnicos no OWASP
Mobile Testing Guide. Para cobrir tópicos como modelagem de ameaças, SDLC seguro
ou gerenciamento de chaves; os usuários do MASVS devem consultar os respectivos
projetos da OWASP e/ou outros padrões, como os relacionados abaixo.
Requisitos de Verificação de Segurança
Os requisitos para MASVS-L1 e MASVS-L2 estão listados abaixo.
# MSTG-ID Descrição L1 L2
1.1 MSTG-ARCH-1 Todos os componentes do aplicativo são x x

identificados e conhecidos como necessários.
1.2 MSTG-ARCH-2 Os controles de segurança nunca são aplicados x x

apenas no lado do cliente, mas nos respectivos
terminais remotos.
1.3 MSTG-ARCH-3 Uma arquitetura de alto nível para o aplicativo x x

móvel e todos os serviços remotos conectados
foi definida e a segurança foi abordada nessa
arquitetura.
1.4 MSTG-ARCH-4 Os dados considerados confidenciais no x x

contexto do aplicativo móvel são claramente
identificados.
20
1.5 MSTG-ARCH-5 Todos os componentes do aplicativo são x

definidos em termos das funções de negócios
e/ou funções de segurança que eles fornecem.
1.6 MSTG-ARCH-6 Foram produzidos um modelo de ameaça para o x

aplicativo móvel e os serviços remotos
associados, que identificam possíveis ameaças
e contramedidas.
1.7 MSTG-ARCH-7 Todos os controles de segurança têm uma x

implementação centralizada.
1.8 MSTG-ARCH-8 Há uma política explícita sobre como as chaves x

criptográficas (se houver) são gerenciadas e
como o ciclo de vida das chaves criptográficas é
imposto. Idealmente, segue um padrão de
gerenciamento de chaves como o NIST SP
800-57.
1.9 MSTG-ARCH-9 Existe um mecanismo para aplicar atualizações x

do aplicativo móvel.
1.10 MSTG-ARCH-10 A segurança é abordada em todas as partes do x

ciclo de vida de desenvolvimento de software.
1.11 MSTG-ARCH-11 Uma responsável política de divulgação está em x

vigor e é efetivamente aplicada.
1.12 MSTG-ARCH-12 O aplicativo deve estar em conformidade com x x

as leis e regulamentos de privacidade.
Referências
Para mais informações, consulte também (em inglês):
• OWASP Mobile Top 10: M10 (Extraneous Functionality) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m10-extraneous-functionality
• OWASP Security Architecture cheat sheet - https://www.owasp.org/index.php/Appl
ication_Security_Architecture_Cheat_Sheet
• OWASP Threat modelling - https://www.owasp.org/index.php/Application_Threat_M
21
odeling
• OWASP Secure SDLC Cheat Sheet - https://www.owasp.org/index.php/Secure_SDL
C_Cheat_Sheet
• Microsoft SDL - https://www.microsoft.com/en-us/sdl/
• NIST SP 800-57 - https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-
5/final
• security.txt - https://securitytxt.org/
22
V2: Requisitos de Armazenamento de Dados e

Privacidade
A proteção de dados sensíveis, como credenciais de usuário e informações pessoais, é

um foco chave na segurança de dispositivos móveis. Primeiramente, dados sensíveis
podem ser expostos de forma não-intencional a outros aplicativos rodando no mesmo
dispositivo se os mecanismos do sistema operacional como o IPC estiverem sendo usa-
dos de forma incorreta. Os dados também podem ser vazados não-intencionalmente no
armazenamento em nuvem, backups ou no cache do teclado. Além disso, dispositivos
móveis podem ser perdidos ou roubados de forma mais comum que outros tipos de dis-
positivos, então um atacante conseguindo acesso físico ao equipamento é um cenário
mais possível. Nesse caso, proteções adicionais podem ser implementadas para tornar
a recuperação de dados sensíveis mais difícil.
Note que, como o MASVS é centrado no aplicativo, ele não cobre políticas a nível de dis-
positivo, como aquelas aplicadas por soluções MDM. Nós encorajamos a utilização dessas
políticas em contexto corporativo para melhorar ainda mais a segurança dos dados.
Definição de Dados Sensíveis
Dados sensíveis no contexto do MASVS incluem tanto as credenciais do usuário quanto

quaisquer outros dados considerados sensíveis em contextos particulares, por exem-
plo:
• Informação de Identificação Pessoal (Personally Identifiable Information - PII) que

possa ser utilizada para roubo de identidade: números de seguro social, números
de cartão de crédito, dados de conta bancária, informações de saúde;
• Dados altamente sensíveis que podem causar danos à reputação e/ou custos fi-
nanceiros se comprometidos: informações de contrato, informações protegidas por
acordos de não divulgação (NDA), informações gerenciais;
• Quaisquer dados que sejam protegidos por lei ou regulações de conformidade.
Requerimentos de Verificação de Segurança
A ampla maioria dos problemas de vazamento de dados podem ser prevenidos seguindo
regras simples. A maior parte dos controles listados neste capítulo são mandatórios para
todos os níveis de verificação.
23
2.1 MSTG-STORAGE-1 Recursos de armazenamento de credenciais do x x

sistema devem ser utilizados para armazenar
dados sensíveis, como dados pessoais (PII),
credenciais de usuário ou chaves criptográficas.
2.2 MSTG-STORAGE-2 Dados sensíveis não devem ser armazenados x x

fora do contêiner do aplicativo ou de recursos
de armazenamento de credenciais do sistema.
2.3 MSTG-STORAGE-3 Dados sensíveis não podem aparecer nos logs x x

de aplicação.
2.4 MSTG-STORAGE-4 Dados sensíveis não devem ser compartilhados x x

com terceiros exceto se for uma parte
necessária da arquitetura.
2.5 MSTG-STORAGE-5 O cache do teclado deve estar desabilitado nas x x

entradas de usuário que processam dados
sensíveis.
2.6 MSTG-STORAGE-6 Dados sensíveis não devem ser expostos x x

através de mecanismos IPC.
2.7 MSTG-STORAGE-7 Dados sensíveis, como senhas ou PINs, não x x

devem ser expostos através da interface de
usuário.
2.8 MSTG-STORAGE-8 Dados sensíveis não devem ser incluídos nos x

backups gerados pelo sistema operacional
móvel.
2.9 MSTG-STORAGE-9 O aplicativo deve remover dados sensíveis da x

visualização quando ficar em segundo plano.
2.10 MSTG-STORAGE-10 O aplicativo não deve manter dados sensíveis x

em memória mais tempo do que o necessário, e
a memória deve ser completamente limpa
depois do uso.
24
2.11 MSTG-STORAGE-11 O aplicativo deve reforçar o uso de políticas x

mínimas de segurança no acesso ao dispositivo,
como pedir que o usuário defina um código de
acesso ao dispositivo.
2.12 MSTG-STORAGE-12 O aplicativo deve ensinar o usuário sobre os x x

tipos de Informação de Identificação Pessoal
(PII) que são processadas, assim como melhores
práticas de segurança que o usuário deve
seguir quando utilizar o aplicativo.
2.13 MSTG-STORAGE-13 Dados sensíveis não devem ser armazenados x

localmente no dispositivo móvel. Em vez disso,
os dados devem ser recuperados de um
terminal remoto quando necessário e mantidos
apenas em memória.
2.14 MSTG-STORAGE-14 Se ainda assim for necessário armazenar dados x

pessoais localmente, eles devem ser cifrados
utilizando uma chave derivada do
armazenamento suportado pelo hardware que
requeira autenticação.
2.15 MSTG-STORAGE-15 O armazenamento local do aplicativo deve ser x

completamente apagado (wipe) após um
número excessivo de tentativas de autenticação
sem sucesso.
Referências
O Guia de Teste de Segurança de Aplicações Móveis da OWASP provê instruções detal-

hadas para verificar os requerimentos listados nesta seção (em inglês).
• Android: Testing Data Storage - https://github.com/OWASP/owasp-mstg/blob/mast

er/Document/0x05d-Testing-Data-Storage.md
• iOS: Testing Data Storage - https://github.com/OWASP/owasp-mstg/blob/master/D
ocument/0x06d-Testing-Data-Storage.md
Para mais informações, veja também (em inglês):
25
• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m1-improper-platform-usage
• OWASP Mobile Top 10: M2 (Insecure Data Storage) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m2-insecure-data-storage
• CWE 117 (Improper Output Neutralization for Logs) - https://cwe.mitre.org/data/def
initions/117.html
• CWE 200 (Information Exposure) - https://cwe.mitre.org/data/definitions/200.html
• CWE 276 (Incorrect Default Permissions) - https://cwe.mitre.org/data/definitions/2
76.html
• CWE 311 (Missing Encryption of Sensitive Data) - https://cwe.mitre.org/data/definit
ions/311.html
• CWE 312 (Cleartext Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/312.html
• CWE 316 (Cleartext Storage of Sensitive Information in Memory) - https://cwe.mitr
e.org/data/definitions/316.html
• CWE 359 (Exposure of Private Information (‘Privacy Violation’)) - https://cwe.mitre.
org/data/definitions/359.html
• CWE 522 (Insufficiently Protected Credentials) - https://cwe.mitre.org/data/definitio
ns/522.html
• CWE 524 (Information Exposure Through Caching) - https://cwe.mitre.org/data/def
initions/524.html
• CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - https://cwe.
mitre.org/data/definitions/530.html
• CWE 532 (Information Exposure Through Log Files) - https://cwe.mitre.org/data/def
initions/532.html
• CWE 534 (Information Exposure Through Debug Log Files) - https://cwe.mitre.org/
data/definitions/534.html
• CWE 634 (Weaknesses that Affect System Processes) - https://cwe.mitre.org/data/d
efinitions/634.html
• CWE 798 (Use of Hard-coded Credentials) - https://cwe.mitre.org/data/definitions/7
98.html
• CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - https:
//cwe.mitre.org/data/definitions/921.html
• CWE 922 (Insecure Storage of Sensitive Information) - https://cwe.mitre.org/data/d
efinitions/922.html
26
V3: Requisitos de Criptografia
A criptografia é um componente essencial quando se trata da proteção dos dados ar-

mazenados em dispositivos móveis. É também uma categoria em que as coisas podem
dar muito errado, especialmente quando as convenções e padrões não são seguidos. O
objetivo dos controles neste capítulo é garantir que o aplicativo verificado use a crip-
tografia de acordo com as melhores práticas do setor, incluindo:
• Uso de bibliotecas criptográficas comprovadas;

• Escolha e configuração adequada das primitivas criptográficas;
• Uso de um gerador de números aleatórios adequado sempre que a aleatoriedade
for necessária.
3.1 MSTG-CRYPTO-1 O aplicativo não se baseia em criptografia x x

simétrica com chaves fixas no código fonte
como único método de criptografia.
3.2 MSTG-CRYPTO-2 O aplicativo usa implementações comprovadas x x

de primitivas criptográficas.
3.3 MSTG-CRYPTO-3 O aplicativo usa primitivas criptográficas que x x

são apropriadas para o caso de uso em questão,
configurado com parâmetros que são aderentes
às melhores práticas da indústria.
3.4 MSTG-CRYPTO-4 O aplicativo não utiliza protocolos criptográficos x x

ou algoritmos que são considerados
amplamente obsoletos para uso em segurança.
3.5 MSTG-CRYPTO-5 O aplicativo não reutiliza a mesma chave x x

criptográfica para vários fins.
3.6 MSTG-CRYPTO-6 Todos os valores aleatórios são gerados usando x x

um gerador de números aleatórios
suficientemente seguro.
27
Referências
O Guia de Teste de Segurança de Aplicações Móveis da OWASP fornece instruções detal-

hadas para verificar os requisitos listados nesta seção (em inglês).
• Android: Testing Cryptography - https://github.com/OWASP/owasp-mstg/blob/mast

er/Document/0x05e-Testing-Cryptography.md
• iOS: Testing Cryptography - https://github.com/OWASP/owasp-mstg/blob/master/D
ocument/0x06e-Testing-Cryptography.md
• OWASP Mobile Top 10: M5 (Insufficient Cryptography) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m5-insufficient-cryptography
• CWE 310 (Cryptographic Issues) - https://cwe.mitre.org/data/definitions/310.html
• CWE 321 (Use of Hard-coded Cryptographic Key) - https://cwe.mitre.org/data/defin
itions/321.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
g/data/definitions/327.html
• CWE 329 (Not Using a Random IV with CBC Mode) - https://cwe.mitre.org/data/def
initions/329.html
• CWE 330 (Use of Insufficiently Random Values) - https://cwe.mitre.org/data/definit
ions/330.html
• CWE 337 (Predictable Seed in PRNG) - https://cwe.mitre.org/data/definitions/337.h
tml
• CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator
(PRNG)) - https://cwe.mitre.org/data/definitions/338.html
28
V4: Requisitos de Autenticação e Gerenciamento

de Sessão
Na maioria dos casos, o login de usuários a um serviço remoto é parte integrante da ar-
quitetura global das aplicações móveis. Embora a maior parte da lógica aconteça no ter-
minal, o MASVS define alguns requisitos básicos sobre a forma como as contas e sessões
dos usuários devem ser gerenciadas.
4.1 MSTG-AUTH-1 Se o aplicativo fornecer aos usuários acesso a x x

um serviço remoto, alguma forma de
autenticação, como autenticação de nome de
usuário e senha, será executada no terminal
remoto.
4.2 MSTG-AUTH-2 Se o gerenciamento de sessão com estado for x x

usado (stateful session management), o
terminal remoto usará identificadores de sessão
gerados aleatoriamente para autenticar as
solicitações de clientes, sem que as credenciais
do usuário sejam enviadas.
4.3 MSTG-AUTH-3 Se a autenticação baseada em token sem x x

estado for usada (stateless token-based
authentication), o servidor fornecerá um token
que foi assinado usando um algoritmo seguro.
4.4 MSTG-AUTH-4 O endpoint remoto termina a sessão existente x x

quando o usuário efetuar logout.
4.5 MSTG-AUTH-5 Uma política de senha existe e é imposta no x x

terminal remoto.
4.6 MSTG-AUTH-6 O terminal remoto implementa um mecanismo x x

para proteger contra o envio de credenciais em
um número excessivo.
29
4.7 MSTG-AUTH-7 As sessões são invalidadas pelo terminal x x

remoto após um período predefinido de
inatividade e os tokens de acessos expiram.
4.8 MSTG-AUTH-8 A autenticação biométrica, se houver, não é x

vinculada a eventos (ou seja, usando uma API
que simplesmente retorna “verdadeiro” ou
“falso”). Em vez disso, é baseado no
desbloqueio do keychain/keystore
(armazenamento seguro).
4.9 MSTG-AUTH-9 Existe um segundo fator de autenticação no x

terminal remoto e o requisito de 2FA é aplicado
de maneira consistente.
4.10 MSTG-AUTH-10 Transações confidenciais requerem x

autenticação adicional.
4.11 MSTG-AUTH-11 O aplicativo informa o usuário de todas as x

atividades confidenciais com a sua conta. Os
usuários podem visualizar uma lista de
dispositivos, exibir informações contextuais
(endereço IP, local etc.) e é capaz de bloquear
dispositivos específicos.
4.12 MSTG-AUTH-12 Os modelos de autorização devem ser definidos x x

e aplicados no terminal remoto.
Referências
O Guia de Teste de Segurança de Aplicações Móveis da OWASP fornece instruções detal-

hadas para verificar os requisitos listados nesta seção (em inglês).
• General: Authentication and Session Management - https://github.com/OWASP/o

wasp-mstg/blob/master/Document/0x04e-Testing-Authentication-and-Session-
Management.md
• Android: Testing Local Authentication - https://github.com/OWASP/owasp-mstg/blo
b/master/Document/0x05f-Testing-Local-Authentication.md
• iOS: Testing Local Authentication - https://github.com/OWASP/owasp-mstg/blob/ma
ster/Document/0x06f-Testing-Local-Authentication.md
30
• OWASP Mobile Top 10: M4 (Insecure Authentication) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m4-insecure-authentication
• OWASP Mobile Top 10: M6 (Insecure Authorization) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m6-insecure-authorization
• CWE 287 (Improper Authentication) - https://cwe.mitre.org/data/definitions/287.h
tml
• CWE 307 (Improper Restriction of Excessive Authentication Attempts) - https://cwe.
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 521 (Weak Password Requirements) - https://cwe.mitre.org/data/definitions/5
21.html
• CWE 604 (Use of Client-Side Authentication) - https://cwe.mitre.org/data/definitions
/604.html
• CWE 613 (Insufficient Session Expiration) - https://cwe.mitre.org/data/definitions/6
13.html
31
V5: Requisitos de Comunicação de Rede
O propósito dos controles listados nessa seção é garantir a confidencialidade e integri-

dade das informações trocadas entre o aplicativo móvel e os terminais de serviço remoto.
Um aplicativo móvel deve, pelo menos, criar um canal seguro e criptografado para comu-
nicação de rede utilizando o protocolo TLS com as configurações apropriadas. O Nível 2
lista medidas adicionais de defesa em profundidade, como fixação de SSL (SSL Pinning).
5.1 MSTG-NETWORK-1 Os dados são criptografados na rede utilizando x x

TLS. O canal seguro é utilizado de forma
consistente através do aplicativo.
5.2 MSTG-NETWORK-2 As configurações do TLS estão alinhadas com as x x

melhores práticas atuais, ou o mais próximas
possível se o sistema operacional móvel não
oferece suporte aos padrões recomendados.
5.3 MSTG-NETWORK-3 O aplicativo verifica o certificado X.509 do x x

terminal remoto quando o canal seguro é
estabelecido. Apenas certificados assinados por
uma CA confiável são aceitos.
5.4 MSTG-NETWORK-4 O aplicativo utiliza seu próprio armazenamento x

de certificados, ou define um certificado ou
chave pública do terminal e, posteriormente,
não estabelece conexões com terminais que
ofereçam um certificado ou chave diferente,
mesmo que assinados por uma CA confiável.
5.5 MSTG-NETWORK-5 O aplicativo não confia em um único canal de x

comunicações inseguro (email ou SMS) para
operações críticas, como registros/cadastros ou
recuperação de conta.
5.6 MSTG-NETWORK-6 O aplicativo depende de conectividade e x

bibliotecas de segurança atualizadas.
32
Referências
O Guia de Teste de Segurança de Aplicações Móveis da OWASP provê instruções detal-

hadas para verificar os requerimentos listados nesta seção (em inglês).
• General: Testing Network Communication - https://github.com/OWASP/owasp-

mstg/blob/master/Document/0x04f-Testing-Network-Communication.md
• Android: Testing Network Communication - https://github.com/OWASP/owasp-
mstg/blob/master/Document/0x05g-Testing-Network-Communication.md
• iOS: Testing Network Communication - https://github.com/OWASP/owasp-mstg/blo
b/master/Document/0x06g-Testing-Network-Communication.md
• OWASP Mobile Top 10: M3 (Insecure Communication) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m3-insecure-communication
• CWE 295 (Improper Certificate Validation) - https://cwe.mitre.org/data/definitions/2
95.html
• CWE 296 (Improper Following of a Certificate’s Chain of Trust) - https://cwe.mitre.or
• CWE 297 (Improper Validation of Certificate with Host Mismatch) - https://cwe.mitr
e.org/data/definitions/297.html
• CWE 298 (Improper Validation of Certificate Expiration) - https://cwe.mitre.org/data
/definitions/298.html
• CWE 308 (Use of Single-factor Authentication) - https://cwe.mitre.org/data/definitio
ns/308.html
• CWE 319 (Cleartext Transmission of Sensitive Information) - https://cwe.mitre.org/
data/definitions/319.html
• CWE 326 (Inadequate Encryption Strength) - https://cwe.mitre.org/data/definitions
/326.html
• CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - https://cwe.mitre.or
• CWE 780 (Use of RSA Algorithm without OAEP) - https://cwe.mitre.org/data/definit
ions/780.html
• CWE 940 (Improper Verification of Source of a Communication Channel) - https:
• CWE 941 (Incorrectly Specified Destination in a Communication Channel) - https:
33
V6: Requisitos de Interação com a Plataforma
Objetivo de Controle
Os controles deste grupo garantem que o aplicativo use APIs da plataforma e compo-
nentes padrão de forma segura. Além disso, os controles cobrem a comunicação entre
aplicativos (IPC).
6.1 MSTG-PLATFORM-1 O aplicativo só solicita o conjunto mínimo de x x

permissões necessárias.
6.2 MSTG-PLATFORM-2 Todas as entradas de fontes externas e do x x

usuário são validadas e, se necessário,
sanitizadas. Isso inclui dados recebidos através
da UI, mecanismos de IPC como intenções, URLs
personalizados e origens pela rede.
6.3 MSTG-PLATFORM-3 O aplicativo não exporta funcionalidades x x

sensíveis através de esquemas de URL
personalizado, a menos que esses mecanismos
estejam devidamente protegidos.
6.4 MSTG-PLATFORM-4 O aplicativo não exporta funcionalidades x x

sensíveis através do IPC, a menos que esses
mecanismos estejam devidamente protegidos.
6.5 MSTG-PLATFORM-5 Código JavaScript é desativado nos WebViews, a x x

menos que explicitamente necessário.
6.6 MSTG-PLATFORM-6 O WebViews está configurado para permitir x x

apenas o conjunto mínimo de manipuladores de
protocolo necessários (preferencialmente,
apenas https). Manipuladores potencialmente
perigosos, como um arquivo, tel e app-id estão
desabilitados.
34
6.7 MSTG-PLATFORM-7 Se os métodos nativos do aplicativo forem x x

expostos a um WebView, verifique se o
WebView só renderiza o código JavaScript
contido no pacote do aplicativo.
6.8 MSTG-PLATFORM-8 A desserialização de objetos, se houver, é x x

implementada usando APIs de serialização
seguras.
6.9 MSTG-PLATFORM-9 O aplicativo se protege contra ataques de x

sobreposição de tela. (somente para Android)
6.10 MSTG-PLATFORM-10 O cache, o armazenamento e os recursos x

carregados (JavaScript, etc.) devem ser
eliminados antes que o WebView seja destruído.
6.11 MSTG-PLATFORM-11 Verifique se o aplicativo impede o uso de x

teclados de terceiros personalizados sempre
que dados confidenciais são inseridos.
(somente para iOS)
References
O Guia de Teste de Segurança Móvel da OWASP fornece instruções detalhadas para veri-
ficar os requisitos listados nesta seção (em inglês).
• Android: Testing Platform Interaction - https://github.com/OWASP/owasp-mstg/blo

b/master/Document/0x05h-Testing-Platform-Interaction.md
• iOS: Testing Platform Interaction - https://github.com/OWASP/owasp-mstg/blob/ma
ster/Document/0x06h-Testing-Platform-Interaction.md
Para mais informações, veja (em inglês):
• OWASP Mobile Top 10: M1 (Improper Platform Usage) - https://owasp.org/www-

project-mobile-top-10/2016-risks/m1-improper-platform-usage
• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 79 (Improper Neutralization of Input During Web Page Generation) - https:
35
• CWE 200 (Information Leak / Disclosure) - https://cwe.mitre.org/data/definitions/2

00.html
• CWE 250 (Execution with Unnecessary Privileges) - https://cwe.mitre.org/data/defin
itions/250.html
• CWE 672 (Operation on a Resource after Expiration or Release) - https://cwe.mitre.
• CWE 749 (Exposed Dangerous Method or Function) - https://cwe.mitre.org/data/def
initions/749.html
• CWE 772 (Missing Release of Resource after Effective Lifetime) - https://cwe.mitre.
• CWE 920 (Improper Restriction of Power Consumption) - https://cwe.mitre.org/data
/definitions/920.html
• CWE 925 (Improper Verification of Intent by Broadcast Receiver) - https://cwe.mitre.
• CWE 926 (Improper Export of Android Application Components) - https://cwe.mitre.
• CWE 927 (Use of Implicit Intent for Sensitive Communication) - https://cwe.mitre.or
• CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - https://cwe.
36
V7: Requisitos de Qualidade de Código e

Configuração do Compilador
O objetivo deste controle é garantir que práticas básicas de codificação segura são
seguidas no desenvolvimento do aplicativo móvel e que as funcionalidades de segurança
“gratuitas” do compilador estão habilitadas.
7.1 MSTG-CODE-1 O aplicativo é assinado e disponibilizado com x x

um certificado válido e cuja chave privada está
devidamente protegida.
7.2 MSTG-CODE-2 O aplicativo foi criado em modo de release e x x

com as configurações apropriadas para ela (ex.:
non-debuggable).
7.3 MSTG-CODE-3 Os símbolos de depuração foram removidos dos x x

binários nativos.
7.4 MSTG-CODE-4 Todo código de depuração e de assistência ao x x

desenvolvedor (ex.: código de teste, backdoors,
configurações ocultas) deve ser eliminado. O
aplicativo não tem logs detalhados de erros e
nem mensagens de depuração.
7.5 MSTG-CODE-5 Todos componentes de terceiros utilizados pelo x x

aplicativo móvel, como blibliotecas e
frameworks, são identificados e revisados
quanto às vulnerabilidades conhecidas.
7.6 MSTG-CODE-6 O aplicativo captura e trata devidamente as x x

possíveis exceções.
7.7 MSTG-CODE-7 Os controles de segurança não permitem x x

acesso por padrão no tratamento de erros.
37
7.8 MSTG-CODE-8 No código não gerenciado a memória é alocada, x x

liberada e usada com segurança.
7.9 MSTG-CODE-9 As funcionalidades de segurança gratuitas das x x

ferramentas, tais como minificação do
byte-code, proteção de pilha, suporte PIE e
contagem automática de referência, devem
estar habilitadas.
Referências
O Guia de Teste de Segurança de Dispositivos Móveis do OWASP disponibiliza instruções

detalhadas para verificar os requisitos listados nesta seção (em inglês).
• Android: Testing Code Quality and Build Settings - https://github.com/OWASP/owasp-

mstg/blob/master/Document/0x05i-Testing-Code-Quality-and-Build-Settings.md
• iOS: Testing Code Quality and Build Settings - https://github.com/OWASP/owasp-
mstg/blob/master/Document/0x06i-Testing-Code-Quality-and-Build-Settings.md
• OWASP Mobile Top 10: M7 (Poor Code Quality) - https://owasp.org/www-project-

mobile-top-10/2016-risks/m7-client-code-quality
• CWE 20 (Improper Input Validation) - https://cwe.mitre.org/data/definitions/20.html
• CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) -
https://cwe.mitre.org/data/definitions/89.html
• CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval
Injection’)) - https://cwe.mitre.org/data/definitions/95.html
• CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
- https://cwe.mitre.org/data/definitions/119.html
• CWE 215 (Information Exposure through Debug Information) - https://cwe.mitre.or
• CWE 388 (7PK - Errors) - https://cwe.mitre.org/data/definitions/388.html
• CWE 489 (Leftover Debug Code) - https://cwe.mitre.org/data/definitions/489.html
• CWE 502 (Deserialization of Untrusted Data) - https://cwe.mitre.org/data/definitio
ns/502.html
• CWE 511 (Logic/Time Bomb) - https://cwe.mitre.org/data/definitions/511.html
• CWE 656 (Reliance on Security through Obscurity) - https://cwe.mitre.org/data/def
initions/656.html
38
• CWE 676 (Use of Potentially Dangerous Function) - https://cwe.mitre.org/data/defin

itions/676.html
• CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vul-
nerabilities) - https://cwe.mitre.org/data/definitions/937.html
39
V8: Requisitos de Resiliência
Esta seção cobre as medidas de proteção recomendadas para aplicativos móveis que pro-
cessam, ou dão acesso para, dados ou funcionalidades sensíveis. A falta de qualquer um
desses controles não causa uma vulnerabilidade. Em vez disso, eles destinam-se a au-
mentar a resiliência do aplicativo móvel contra engenharia reversa e ataques específicos
do lado do cliente.
Os controles desta seção devem ser aplicados conforme necessário, com base em uma
avaliação dos riscos causados por manipulação não autorizada do aplicativo móvel e/ou
engenharia reversa do código. Sugerimos que sejam consultados os documentos “Tech-
nical Risks of Reverse Engineering and Unauthorized Code Modification” e “Reverse Engi-
neering and Code Modification Prevention” do OWASP (veja referência abaixo) para uma
lista dos riscos de negócio, assim como as ameaças técnicas associadas.
Para que qualquer controle da lista abaixo ser efetivo, o aplicativo móvel deve cumprir
pelo menos todas as MASVS-L1 (ou seja, devem existir controles sólidos de segurança),
assim como todos os requisitos de número inferior no V8. Por exemplo, os controles de
ofuscação listados em “impedir a compreensão” devem ser combinados com “impedir a
análise dinâmica e a manipulação” e “vinculação ao dispositivo”.
**Perceba que as proteções de software nunca devem ser usadas como substitutas dos
controles de segurança. Os controles listados no MASVR-R buscam adicionar controles
específicos contra ameaças aos aplicativos móveis que também atendem aos requisitos
de segurança do MASVS.
As seguintes considerações se aplicam:
1. Um modelo de ameaça deve ser definido para descrever de forma clara as ameaças
que devem ser defendidas no lado do cliente. Além disso, deve ser especificado o
grau de proteção que o esquema deve fornecer. Por exemplo, um objetivo poderia
ser obrigar os autores do malware que querem se utilizar do aplicativo móvel a
terem que se esforçar bastante para realizar a engenharia reversa.
2. O modelo de ameaça deve ser crível e relevante. Por exemplo, esconder a chave
criptográfica em uma implementação caixa branca pode ser redundante se um ata-
cante puder simplesmente utilizar a aplicação móvel como um todo.
3. A efetividade da proteção deve sempre ser verificada por um especialista com ex-
periência em testar tipos particulares de prevenção de manipulação e ofuscação
usados (veja também os capítulos “reverse engineering” e “assessing software pro-
tections” no Guia de Teste de Segurança de Dispositivos Móveis).
40
Impedir Análise Dinâmica e Manipulação
# MSTG-ID Descrição R
8.1 MSTG-RESILIENCE-1 O aplicativo detecta e responde para a presença x

de um dispositivo com root ou jailbreak alertando
o usuário ou fechando o aplicativo.
8.2 MSTG-RESILIENCE-2 O aplicativo previne a depuração e/ou detecta e x

reponde a ela. Todos os protocolos de depuração
disponíveis devem ser cobertos.
8.3 MSTG-RESILIENCE-3 O aplicativo detecta e responde para a x

manipulação de executáveis e dados críticos do
próprio aplicativo.
8.4 MSTG-RESILIENCE-4 O aplicativo detecta e responde para a presença x

no dispositivo de ferramentas de engenharia
reversa e frameworks amplamente utilizados.
8.5 MSTG-RESILIENCE-5 O aplicativo detecta e responde para quando x

executada em um emulador.
8.6 MSTG-RESILIENCE-6 O aplicativo detecta e responde para x

manipulação de código e dados em seu espaço
de memória.
8.7 MSTG-RESILIENCE-7 O aplicativo implementa múltiplos mecanismos x

em cada categoria de defesa (8.1 a 8.6). Observe
que quanto maior a quantidade e diversidade de
mecanismos usados, maior será a resiliência.
8.8 MSTG-RESILIENCE-8 Os mecanismos de detecção provocam x

diferentes tipos de respostas, inclusive respostas
tardias e silenciosas.
8.9 MSTG-RESILIENCE-9 A ofuscação é aplicada às defesas do programa x

que, por sua vez, impede a desofuscação por
meio de análise dinâmica.
Vinculação ao Dispositivo
41
8.10 MSTG-RESILIENCE-10 O aplicativo implementa uma funcionalidade de x

‘vinculação ao dispositivo’ usando um
identificador único derivado de múltiplas
propriedades únicas do dispositivo.
Impedir a Compreensão
8.11 MSTG-RESILIENCE-11 Todos os arquivos executáveis e bibliotecas x

pertencentes ao aplicativo devem ser cifrados
e/ou códigos importantes e segmentos de dados
dentro dos executáveis devem ser cifrados ou
empacotados. Assim, uma análise estática trivial
não revelará importantes trechos de código e
dados.
8.12 MSTG-RESILIENCE-12 Se o objetivo da ofuscação é proteger códigos x

relevantes, deverá ser utilizado um esquema de
ofuscação apropriado para essa tarefa particular
e robusto para contra métodos de desofuscação
manual e automatizada, considerando as
pesquisas atualmente publicadas. A efetividade
do esquema de ofuscação deve ser verificada
com testes manuais. Observe que, sempre que
possível, as funcionalidades de isolamento
baseadas em hardware são preferíveis à
ofuscação.
Impedir o Eavesdropping
42
8.13 MSTG-RESILIENCE-13 Como defesa mais forte, além de ter um sólido x

fortalecimento das partes que se comunicam,
pode ser implementada a criptografia de dados
em nível de aplicativo como uma medida
adicional contra ataques eavesdropping.
Referências
O Guia de Teste de Segurança de Dispositivos Móveis do OWASP disponibiliza instruções

detalhadas para verificar os requisitos listados nesta seção (em inglês).
• Android: Testing Resiliency Against Reverse Engineering - https://github.com/OWA

SP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-
Engineering.md
• iOS: Testing Resiliency Against Reverse Engineering - https://github.com/OWASP
/owasp-mstg/blob/master/Document/0x06j-Testing-Resiliency-Against-Reverse-
Engineering.md
Para mais informação, veja também (em inglês):
• OWASP Mobile Top 10: M8 (Code Tampering) - https://owasp.org/www- project-

mobile-top-10/2016-risks/m8-code-tampering
• OWASP Mobile Top 10: M9 (Reverse Engineering) - https://owasp.org/www-project-
mobile-top-10/2016-risks/m9-reverse-engineering
• OWASP Reverse Engineering Threats - https://wiki.owasp.org/index.php/Technical
_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification
• OWASP Reverse Engineering and Code Modification Prevention - https://wiki.owasp
.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_P
roject
43
Apêndice A: Glossário
• Arquitetura de Segurança - Uma abstração do planejamento da aplicação que

identifica e descreve onde e como os controles de segurança são usados, e tam-
bém identifica e descreve a localização e sensibilidade dos dados do usuário e da
aplicação.
• Autenticação SSO - Autenticação Única (Single Sign-On - SSO) ocorre quando um
usuário se autentica em um Cliente e então é autenticado em outros Clientes au-
tomaticamente, independente da plataforma, tecnologia ou domínio que o usuário
está utilizando. Por exemplo, quando você se autentica no Google você será auten-
ticado automaticamente no YouTube, Docs e serviço de email.
• Autenticação - A verificação da identidade reclamada por um usuário da aplicação.
• Bytecode Java - Bytecode Java é um grupo de instruções da Máquina Virtual Java
(JVM). Cada bytecode é composto por um, ou em alguns casos dois, bytes que rep-
resentam uma instrução (opcode), junto com zero ou mais bytes para passagem de
parâmetros.
• Certificado X.509 - Um certificado X.509 é um certificado digital que utiliza o
padrão globalmente reconhecido X.509 de Infraestrutura de Chave Pública (PKI)
para verificar que uma chave pública pertence a um usuário, computador ou serviço
identificado no certificado.
• Chaves Hardcoded - Chaves criptográficas que são armazenadas no próprio dis-
positivo.
• Código Malicioso - Código introduzido dentro da aplicação durante o seu desen-
volvimento sem o consentimento do dono da aplicação, o qual contorna a política
de segurança pretendida pela aplicação. Não é a mesma coisa que malware, vírus
ou worm!
• Componente - Uma unidade de código autônoma, associada a um disco e a inter-
faces de rede que comunicam com outros componentes.
• Comunicação entre Processos (IPC) - EM IPC os processos se comunicam uns
com os outros e com o kernel para coordenar suas atividades.
• Configuração de Segurança - A configuração de execução de uma aplicação que
afeta como os controles de segurança são utilizados.
• Controle de Segurança - Uma função ou componente que executa uma checagem
de segurança (por exemplo, uma checagem de controle de acesso) ou quando
chamado tem resultados com efeitos na segurança (por exemplo gerar um registro
de auditoria).
• Cross-Site Scripting (XSS) - Uma vulnerabilidade de segurança tipicamente en-
contrada em aplicações web, permitindo a injeção de scripts no conteúdo do lado
do cliente.
• CWE - CWE é uma lista desenvolvida de forma comunitária para falhas comuns de
segurança. Ela serve como uma linguagem única, uma medida para ferramentas de
44
segurança de software e como embasamento para identificação de falhas e esforços

de mitigação e prevenção.
• Executável de Posição Independente (Position Independent Executable -
PIE) - O PIE é um corpo de código de máquina que, sendo colocado em algum
lugar da memória primária, executa corretamente independente do seu endereço
absoluto.
• Identificador Único Global (GUID) - Um número único de referência utilizado
como identificador em um software.
• Informação de Identificação Pessoal (Personally Identifiable Information -
PII) - PII são informações que podem ser utilizadas sozinhas ou em conjunto com
outras informações para identificar, contatar ou localizar uma pessoa específica, ou
para identificar um único indivíduo dentro de determinado contexto.
• Infraestrutura de Chave Pública (PKI) - Uma PKI é um arranjo que liga chaves
públicas com as respectivas identidades de entidades. A ligação é estabelecida
através de um processo de registro e emissão de certificados em e por uma Autori-
dade Certificadora (CA).
• Injeção de SQL (SQLi) - Uma técnica de injeção de código usada para atacar apli-
cações orientadas a dados nas quais declarações SQL maliciosas são inseridas em
um ponto de entrada.
• Lista Branca (Whitelist) - Uma lista de dados ou operações permitidas, por ex-
emplo uma lista de caracteres que são aceitos em uma validação de entradas de
usuário.
• Malware - Código executável que é introduzido em uma aplicação em execução
sem o conhecimento do usuário ou administrador da aplicação.
• Modelagem de Ameaças (Threat Modeling) - Técnica que consiste em de-
senvolver arquiteturas de segurança cada vez mais refinadas a fim de identificar
agentes de ameaça, zonas e controles de segurança, técnicas importantes e ativos
de negócio.
• Módulo Criptográfico - Hardware, software e/ou firmware que implementa algo-
ritmos criptográficos e/ou gera chaves criptográficas.
• Projeto Aberto de Segurança de Aplicações Web (Open Web Application
Security Project - OWASP) - A OWASP é uma comunidade mundial livre e aberta
focada na melhoria da segurança de aplicações de software. Nossa missão é tornar
a segurança de aplicações “visível”, então as pessoas e organizações poderão tomar
decisões conscientes sobre os riscos de segurança de aplicações. Veja mais: https:
//www.owasp.org/.
• Protocolo de Transferência de Hipertexto (HTTP) - Um protocolo de aplicação
para sistemas distribuídos, colaborativos e de informação de hipermídia. Ele é o
fundamento para comunicação de dados na Rede Mundial (World Wide Web - WWW).
• Randomização de Layout de Espaço de Endereço (Address Space Layout
Randomization - ASLR) – Uma técnica para tornar mais difícil a exploração de
45
erros de corrupção da memória.

• Relatório de Verificação da Segurança de Aplicações - Um relatório que docu-
menta os resultados gerais e dá suporte a análises produzidas pelo verificador para
uma aplicação em particular.
• SDLC - Sigla para Ciclo de Desenvolvimento de software (Software Development
Life Cycle).
• Segurança de Aplicações - Segurança em nível de aplicação foca na análise de
componentes que fazem parte da camada de aplicação no Modelo de Referência de
Interconexão de Sistemas Abertos (Modelo OSI), em vez de focar, por exemplo, no
sistema operacional subjacente ou nas redes conectadas.
• Segurança de Camada de Transporte (Transport Layer Security - TLS) - Pro-
tocolos criptográficos que oferecem comunicação segura através da Internet.
• Teste Caixa Preta - É o método de teste de software que examina a funcionalidade
de uma aplicação sem levar em conta suas estruturas ou funcionamentos internos.
• Teste de Aceitação de Usuário (UAT) - Tradicionalmente um ambiente de testes
que se comporta como o ambiente produtivo onde todos os testes de software são
realizados antes de irem para produção.
• Teste Dinâmico de Segurança de Aplicações (DAST) - Tecnologias DAST são
desenhadas para detectar indicativos de condições para uma vulnerabilidade de
segurança ocorrer em uma aplicação no seu estado funcional.
• Teste Estático de Segurança de Aplicações (SAST) - SAST é um grupo de tec-
nologias planejadas para analisar o código fonte, bytecode e binários de uma apli-
cação para identificar condições de codificação e planejamento que sejam indica-
tivos de vulnerabilidades de segurança. Soluções SAST analisam a aplicação “de
dentro para fora” em um estado de não-execução.
• URI e URL - Identificador de Recurso Uniforme (Uniform Resource Identifier - URI)
é uma string de caracteres usada para identificar um nome ou recurso web. Um
Localizador de Recurso Uniforme (Uniform Resource Locator - URL) é normalmente
utilizado como uma referência a um recurso.
• Validação de Entradas - A sanitização e validação de entradas de usuário não-
confiáveis.
• Verificação Automatizada - O uso de ferramentas automatizadas (tanto ferramen-
tas de análise dinâmica, ferramentas de análise estática, quanto ambas) que usam
assinaturas de vulnerabilidade para identificar problemas.
• Verificação de Segurança de Aplicações - Avaliação técnica de uma aplicação
do ponto de vista do OWASP MASVS.
• Verificação Dinâmica - O uso de ferramentas automatizadas que usam assinat-
uras de vulnerabilidades para identificar problemas durante a execução de uma
aplicação.
• Verificador - Pessoa ou time que está revisando uma aplicação de acordo com os
requisitos OWASP MASVS.
46
Apêndice B: Referências
Os projetos da OWASP a seguir são provavelmente os mais úteis para usuários e

seguidores desse padrão (links em inglês):
• Projeto OWASP de Segurança em Dispositivos Móveis - https://owasp.org/www-

project-mobile-security/
• Guia OWASP de Teste de Segurança em Dispositivos Móveis - https://owasp.org/ww
w-project-mobile-security-testing-guide/
• OWASP Top 10 Riscos em Dispositivos Móveis - https://owasp.org/www-project-
mobile-top-10/
• Projeto OWASP de Prevenção à Engenharia Reversa e Modificação de Código - https:
//wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_P
revention_Project
De forma similar, os sites a seguir devem ser úteis aos usuários e seguidores desse
padrão:
• Enumeração de Vulnerabilidades Comuns da MITRE (em inglês) - http://cwe.mitre.

org/
• Conselho PCI de Padrões de Segurança (em português) - https://pt.pcisecuritystan
dards.org/
• Padrão PCI de Segurança de Dados (PCI-DSS) v3.2.1 Requisitos e Procedimentos de
Avaliação de Segurança (em português) - https://pt.pcisecuritystandards.org/onelink/pcisecurit
2-1_PT-BR.PDF
47
Controle de Alterações
V1.3 - 13 May 2021
We are proud to announce the introduction of a new document build pipeline, which is
a major milestone for our project. The build pipeline is based on Pandocker and Github
Actions. This significantly reduces the time spent on creating new releases and will also
be the foundation for the OWASP MSTG and will be made available for the OWASP ASVS
project.
Changes
• 4 more translations are available, which are Hindi, Farsi, Portuguese and Brazilian
Portuguese
• Added requirement MSTG-PLATFORM-11
Special Thanks
• Jeroen Willemsen for kick-starting this initiative last year!

• Damien Clochard and Dalibo for supporting and professionalizing the build pipeline.
• All our Hindi, Farsi, Portuguese and Brazilian Portuguese collaborators for the excel-
lent translation work.
V1.2 - 7 de Março de 2020 - Versão Internacional
As seguintes alterações fazem parte da versão 1.2:
• Disponibilização da tradução do MASVS em Chinês simplificado.

• Alteração de título na capa do livro do MASVS.
• Removidos o Top 10 Riscos de Dispositivos Móveis e CWE do MSTG e colocados como
referências existentes no MASVS.
V1.2-RC - 5 de Outubro de 2019 - Pré-versão (apenas Inglês)
As seguintes alterações fazem parte da pré-versão 1.2:
• Promovido ao estado Principal.

• Mudança em requisito: MSTG-STORAGE-1 “precisa ser utilizado”.
• Requisitos MSTG-STORAGE-13, MSTG-STORAGE-14 e MSTG-STORAGE-15 foram adi-
cionados com foco em proteção de dados.
48
• Requisito MSTG-AUTH-11 foi atualizado para preservar informações contextuais.

• Requisito MSTG-CODE-4 foi atualizado para cobrir mais do que apenas debug.
• Requisito MSTG-PLATFORM-10 foi adicionado para futuro uso seguro de WebViews.
• Requisito MSTG-AUTH-12 foi adicionado para lembrar os desenvolvedores de imple-
mentarem autorização, especialmente em caso de aplicativos multi-usuário.
• Adicionados alguns detalhes na descrição de como o MASVS deve ser utilizado para
uma avaliação de riscos.
• Adicionados alguns detalhes na descrição de conteúdos pagos.
• Requisito MSTG-ARCH-11 foi adicionado para incluir uma política de Divulgação Re-
sponsável para aplicações L2.
• Requisito MSTG-ARCH-12 foi adicionado para mostrar aos desenvolvedores de apli-
cações que leis internacionais de privacidade relevantes devem ser seguidas.
• Criado um estilo consistente para todas as referências na versão em Inglês.
• Requisito MSTG-PLATFORM-11 foi adicionado para contra-espionagem através de
teclados terceiros.
• Requisito MSTG-RESILIENCE-13 foi adicionado para impedir espionagem (eavesdrop-
ping) em uma aplicação.
V1.1.4 - 4 de Julho de 2019 - Edição Summit
As seguintes alterações fazem parte da versão 1.1.4:
• Corrigidos todos os problemas de remarcação.

• Atualizações nas traduções para Francês e Espanhol.
• Controle de Alterações traduzido para o Chinês (ZHTW) e Japonês.
• Verificação automática da sintaxe de remarcações e acessibilidade das URLs.
• Adicionados códigos de identificação dos requisitos, que serão incluídos na futura
versão do MSTG a fim de encontrar de forma mais fácil as recomendações e casos
de teste.
• Redução do tamanho do repositório e adição do Generated ao .gitignore.
• Adicionados um Código de Conduta e Orientações para Contribuição.
• Adicionado um modelo para Pull-Requests.
• Atualização da sincroniza com o repositório em uso para hospedar o site do Gitbook.
• Atualizados os scripts para gerar o XML/JSON/CSV de todas as traduções.
• Tradução do Prefácio para o Chinês (ZHTW).
V1.1.3 - 9 de Janeiro de 2019 - Correções Menores
• Corrige problema de tradução no requisito 7.1 na versão em Espanhol.

• Novo setup para tradutores nos agradecimentos.
49
V1.1.2 - 3 de Janeiro de 2019 - Patrocínio e Internacionalização
As seguintes alterações fazem parte da versão 1.1.2:
• Adicionada nota de agradecimento para compradores do e-book.

• Adicionado link de autenticação faltante e atualizado link de autenticação quebrado
na V4.
• Corrigida troca na 4.7 e 4.8 em Inglês.
• Primeira versão internacional!
– Correções na tradução do Espanhol. Tradução agora está sincronizada com o

Inglês (1.1.2).
– Correções na tradução do Russo. Tradução agora está sincronizada com o Inglês
(1.1.2).
– Adicionada a primeira versão em Chinês (ZHTW), Francês, Alemão e Japonês!
• Documento simplificado para facilitar a tradução.

• Adicionadas instruções para versões automáticas.
V1.1.0 - 14 de Julho de 2018
• Requisito 2.6 Remoção de “A área de transferência é desativada em campos de texto

que possam conter dados sensíveis”.
• Requisito 2.2 Adição de “Dados sensíveis não devem ser armazenados fora do con-
têiner do aplicativo ou de recursos de armazenamento de credenciais do sistema”.
• Requisito 2.1 foi reescrito para “Recursos de armazenamento de credenciais do sis-
tema devem ser utilizados para armazenar dados sensíveis, como Dados de Identi-
ficação Pessoal (PII), credenciais de usuário ou chaves criptográficas.”
V1.0 - 12 de Janeiro de 2018
• Deletado item 8.9 por ser o mesmo que o 8.12.

• Item 4.6 tornado mais genérico.
• Correções menores (erros de digitação, etc.).
50

OWASP - MASVS-v1 4 2-ptbr

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OWASP - MASVS-v1 4 2-ptbr

Enviado por

Direitos autorais:

Formatos disponíveis

(Brazilian Portuguese Translation)

Version v1.4.2 January 20, 2022

O Padrão de Veriﬁcação de Segurança de Aplicativos Móveis 12

V1: Requisitos de Arquitetura, Design e Modelagem de Ameaças 20

V2: Requisitos de Armazenamento de Dados e Privacidade 23

V3: Requisitos de Criptograﬁa 27

V4: Requisitos de Autenticação e Gerenciamento de Sessão 29

V5: Requisitos de Comunicação de Rede 32

V6: Requisitos de Interação com a Plataforma 34

Requisitos de Veriﬁcação de Segurança . . . . . . . . . . . . . . . . . . . . . 34

V7: Requisitos de Qualidade de Código e Conﬁguração do Compilador 37

V8: Requisitos de Resiliência 40

Revoluções tecnológicas podem acontecer rapidamente. Há menos de uma década,

Ao longo do tempo, nossa indústria tem conseguido um melhor controle no cenário de

Além disso, o surgimento de malware de root e ferramentas de administração remota

Como resultado, os relatórios de testes de segurança de aplicativos móveis estão por

• Prover requisitos para arquitetos e desenvolvedores de software que buscam desen-

Nós estamos conscientes de que é impossível alcançar um consenso de 100% na in-

Por Bernhard Mueller

Bem-vindo ao Padrão de Veriﬁcação de Segurança de Aplicativos Móveis (MASVS). O

O MASVS é o resultado de esforços da comunidade e do retorno da indústria. Esperamos

Contas podem ser criadas a partir da seguinte URL: https://owasp.slack.com/join/share

Direitos de Uso e Licença

Líderes de Projeto Autor Colaboradores e Revisores

Linguagem Tradutores e Revisores

Alemão Rocco Gränitz, Sven Schleier (Revisão)

Chinês Bob Peng, Harold Zang, Jack S

Coreano Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung

Espanhol Martin Marsicano, Carlos Holguera

Francês Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Revisão)

Japonês Koki Takeyama, Riotaro Okada (Revisão)

Persa Hamed Salimian, Ramin Ateﬁnia, Dorna Azhirak, Bardiya Akbari,

Linguagem Tradutores e Revisores

Português Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza,

Russo Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Revisão), Oprya

Este documento começou como um fork do Padrão de Veriﬁcação de Segurança de Aplica-

OWASP Bay Area Chapter

O Padrão de Veriﬁcação de Segurança de

O MASVS pode ser utilizado para estabelecer um nível de conﬁança na segurança de

Modelo de Segurança para um Aplicativo Móvel

O MASVS deﬁne dois níveis de veriﬁcação de segurança (MASVS-L1 e MASVS-L2), as-

I: Embora seja recomendado implementar controles MASVS-L1 em todos os

II: Observe que os controles de proteção de software listados no MASVS-R e de-

devem ser usados como substitutos de controles adicionais de proteção e es-

A primeira parte do MASVS contém uma descrição do modelo de segurança e os níveis

• Categoria de Requisito: MASVS-Vx, ex. MASVS-V2: Armazenamento de Dados e

Níveis de Veriﬁcação Detalhados

MASVS-L1: Padrão de Segurança

Um aplicativo móvel que alcança o MASVS-L1 adere às práticas recomendadas de segu-

MASVS-L2: Defesa em Profundidade

O MASVS-L2 introduz controles avançados de segurança que vão além do requisito

MASVS-R: Resiliência contra Engenharia Reversa e Adulteração

O aplicativo tem segurança de última geração e também é resistente contra ataques

Em resumo, os seguintes tipos de veriﬁcação estão disponíveis:

As diferentes combinações reﬂetem diferentes graus de segurança e resiliência. O obje-

Qual Tipo de Veriﬁcação Escolher

A implementação dos requisitos do MASVS L2 aumenta a segurança, ao mesmo tempo

• Todos os aplicativos móveis. O MASVS-L1 lista práticas recomendadas de segurança

• Indústria de Saúde: Aplicativos móveis que armazenam informações pessoais identi-

• Indústria Financeira: Aplicativos que permitem o acesso a informações altamente

• Aplicativos móveis onde a proteção da Propriedade Intelectual (IP) é um objetivo

básicos contra adulteração para ajudar a aumentar o esforço que os trapaceiros

• Indústria Financeira: Aplicativos bancários online que permitem ao usuário movi-