Skip to content

Commit

Permalink
Merge pull request #450 from mpolastro/master
Browse files Browse the repository at this point in the history
Translate to brazilian portuguese-issue #449
  • Loading branch information
commjoen authored May 26, 2020
2 parents 5e44616 + e0dfbfe commit 77436c0
Show file tree
Hide file tree
Showing 29 changed files with 931 additions and 0 deletions.
25 changes: 25 additions & 0 deletions Document-ptbr/0x01-Foreword.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Prefácio

Por Bernhard Mueller, OWASP Projeto para Dispositivos Móveis

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 essas 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 pequenos 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, não? Mas não funciona dessa 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 é tecnicamente 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 que, por exemplo, 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, anotaçõ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 malware 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 esses eles gerenciam, armazenam e protegem informações sensíveis. Embora os sistemas operacionais 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 corretamente para serem efetivos. O armazenamento de dados, a comunicação entre aplicativos, 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.

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 os _SSL certificate pining_? Não implementá-lo não resultaria em uma vulnerabilidade? Isso deveria ser um requisito se o aplicativos móvel trata dados sensíveis ou isso seria contraproducente? Deveríamos cifrar 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. The 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 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 são sempre disponíveis nos diferentes dispositivos. Uma forma de se minimizar o problema é implementar medidas de proteção baseadas em software - mas, infelizmente, não há padrões ou processos de teste para verificar esse tipo 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 obfuscaçã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 obfuscaçã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 defesa (MASVS-L2) e proteções contra as ameaças no lado do cliente (MASVS-R). O MASVS busca:
- Prover requisitos para arquitetos e desenvolvedores de software que buscam o desenvolvimento de 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 recom,endado para diferentes casos de uso.

Nós estamos conscientes de que é impossível alcançar um consenso de 100% na indústria. Contudo, esperamos que o MASVS seja útil para fornecer orientação nas fases de desnvolvimento 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.
55 changes: 55 additions & 0 deletions Document-ptbr/0x02-Frontispiece.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# About the Standard

<img src="images/OWASP_logo.png" title="OWASP LOGO" />

Welcome to the Mobile Application Security Verification Standard (MASVS) 1.2. The MASVS is a community effort to establish a framework of security requirements needed to design, develop and test secure mobile apps on iOS and Android.

The MASVS is a culmination of community effort and industry feedback. We expect this standard to evolve over time and welcome feedback from the community.

The best way to get in contact with us is via the OWASP Mobile Project Slack channel: <https://owasp.slack.com/messages/project-mobile_omtg/details/> .

Accounts can be created at the following URL: [https://owasp-slack.herokuapp.com/](https://owasp-slack.herokuapp.com/).

## Copyright and License

[<img src="images/CC-license.png" title="License" width="200px" height="45px" />](https://creativecommons.org/licenses/by-sa/4.0/)

Copyright © 2020 The OWASP Foundation.This work is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). For any reuse or distribution, you must make clear to others the license terms of this work.

<!-- \pagebreak -->

## Acknowledgements

| Project Lead | Lead Author | Contributors and Reviewers
| ------- | --- | ----------------- |
| Sven Schleier, Jeroen Willemsen and Carlos Holguera | Bernhard Mueller | Alexander Antukh, Mesheryakov Aleksey, Bachevsky Artem, Jeroen Beckers, Vladislav Chelnokov, Ben Cheney, Peter Chi, Lex Chien, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, Tereshin Dmitry, Christian Dong, Oprya Egor, Ben Gardiner, Rocco Gränitz, Henry Hu, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, Gall Maxim, Eugen Martynov, Riotaro Okada, Abhinav Sejpal, Stefaan Seys, Yogesh Sharma, Prabhant Singh, Sven Schleier, Nikhil Soni, Anant Shrivastava, Francesco Stillavato, Romuald Szkudlarek, Abderrahmane Aftahi, Abdessamad Temmar, Koki Takeyama, Chelnokov Vladislav, Leo Wang |

<br/>

| Language | Translators & Reviewers |
| --- | ------------------------------ |
| Chinese (Traditonal) | Peter Chi, and Lex Chien, Henry Hu, Leo Wang |
| Chinese (Simplified) | Bob Peng, Harold Zang, Jack S |
| French | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) |
| German | Rocco Gränitz, Sven Schleier (Review) |
| Japanese | Koki Takeyama, Riotaro Okada (Review) |
| Korean | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung |
| Persian | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari |
| Russian | Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Review), Oprya Egor (Review), Tereshin Dmitry (Review) |
| Spanish | Martin Marsicano, Carlos Holguera |

This document started as a fork of the OWASP Application Security Verification Standard written by Jim Manico.

## Sponsors

While both the MASVS and the MSTG are created and maintained by the community on a voluntary basis, sometimes a little bit of outside help is required. We therefore thank our sponsors for providing the funds to be able to hire technical editors. Note that their sponsorship does not influence the content of the MASVS or MSTG in any way. The sponsorship packages are described on the [OWASP Project Wiki](https://owasp.org/www-project-mobile-security-testing-guide/#div-sponsorship "OWASP Mobile Security Testing Guide Sponsorship Packages").

### Honourable Benefactor

[<img src="images/NowSecure_logo.png" title="NowSecure" width="200px" height="58px" />](https://www.nowsecure.com/ "NowSecure")

### Good Samaritan Benefactor

[<img src="images/Randorisec_logo.png" title="Randorisec" width="200px" height="58px" />](https://www.randorisec.fr/ "RandoriSec")

Next, we would like to thank the OWASP Bay Area Chapter for their sponsorship. Last, we would like to thank everybody that bought the book from Leanpub and sponsored us that way.
85 changes: 85 additions & 0 deletions Document-ptbr/0x03-Using_the_MASVS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
# O Padrão de Análise de Segurança de Aplicativos para Dispositivos 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 objetivos:

- Utilize 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 Desenvolvimento e Teste de aplicativos para dispositivos móveis.
- Utilize no processo de aquisição - Para fornecer uma linha de base para a análise de segurança dos aplicativos móveis.

## Modelo de Aplicação de Segurança Mobile

O MASVS define dois níveis de verificação de segurança (MASVS-L1 and MASVS-L2), assim como um conjunto de requisitos de resiliência de 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 aplicativos que manipulam dados altamente confidenciais. O MASVS-R abrange controlees de proteção adicionais quee podem ser aplicados se um dos objetivos do projeto desenvolvido for a prevenção de ameaças do lado do usuário.

Cumprir os requisitos do MASVS-L1 resulta em uma aplicação segura que segue as melhores práticas recomendadas de segurança e não sofre com vulnerabilidades mais comuns. O MASVS-L2 adiciona mais controles de defesa em profundidade como SSL Pinning, resultando em um aplicativo resistente a ataques mais complexos, assumindo que os controles de seguran'da 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 os requisitos ou subconjuntos de proteção de software no MASVS-R ajuda a mitigar ameaças específicas do cliente em que o usuário final é malicioso e/ou o sistema operacional móvel esteja comprometido.

**I: Although we recommend implementing MASVS-L1 controls in every app, implementing a control or not should ultimately be a risk-based decision, which is taken/communicated with the business owners.**

**II: Note that the software protection controls listed in MASVS-R and described in the OWASP Mobile Security Testing Guide can ultimately be bypassed and must never be used as a replacement for security controls. Instead, they are intended to add additional threat-specific, protective controls to apps that also fulfill the MASVS requirements in MASVS-L1 or MASVS-L2.**

<img src="images/masvs-levels-new.jpg" title="Verification Levels" width="600px" height="253px" />

### Document Structure

The first part of the MASVS contains a description of the security model and available verification levels, followed by recommendations on how to use the standard in practice. The detailed security requirements, along with a mapping to the verification levels, are listed in the second part. The requirements have been grouped into eight categories (V1 to V8) based on technical objective / scope. The following nomenclature is used throughout the MASVS and MSTG:

- *Requirement category:* MASVS-Vx, e.g. MASVS-V2: Data Storage and Privacy
- *Requirement:* MASVS-Vx.y, e.g. MASVS-V2.2: "No sensitive data is written to application logs."

### Verification Levels in Detail

#### MASVS-L1: Standard Security

A mobile app that achieves MASVS-L1 adheres to mobile application security best practices. It fulfills basic requirements in terms of code quality, handling of sensitive data, and interaction with the mobile environment. A testing process must be in place to verify the security controls. This level is appropriate for all mobile applications.

#### MASVS-L2: Defense-in-Depth

MASVS-L2 introduces advanced security controls that go beyond the standard requirements. To fulfill MASVS-L2, a threat model must exist, and security must be an integral part of the app's architecture and design. Based on the threat model, the right MASVS-L2 controls should have been selected and implemented successfully. This level is appropriate for apps that handle highly sensitive data, such as mobile banking apps.

#### MASVS-R: Resiliency Against Reverse Engineering and Tampering

The app has state-of-the-art security, and is also resilient against specific, clearly defined client-side attacks, such as tampering, modding, or reverse engineering to extract sensitive code or data. Such an app either leverages hardware security features or sufficiently strong and verifiable software protection techniques. MASVS-R is applicable to apps that handle highly sensitive data and may serve as a means of protecting intellectual property or tamper-proofing an app.

### Recommended Use

Apps can be verified against MASVS L1 or L2 based on prior risk assessment and overall level of security required. L1 is applicable to all mobile apps, while L2 is generally recommended for apps that handle more sensitive data and/or functionality. MASVS-R (or parts of it) can be applied to verify resiliency against specific threats, such as repackaging or extraction of sensitive data, *in addition* to proper security verification.

In summary, the following verification types are available:

- MASVS-L1
- MASVS-L1+R
- MASVS-L2
- MASVS-L2+R

The different combinations reflect different grades of security and resiliency. The goal is to allow for flexibility: For example, a mobile game might not warrant adding MASVS-L2 security controls such as 2-factor authentication for usability reasons, but have a strong business need for tamper prevention.

#### Which Verification Type to Choose

Implementing the requirements of MASVS L2 increases security, while at the same time increasing cost of development and potentially worsening the end user experience (the classical trade-off). In general, L2 should be used for apps whenever it makes sense from a risk vs. cost perspective (i.e., where the potential loss caused by a compromise of confidentiality or integrity is higher than the cost incurred by the additional security controls). A risk assessment should be the first step before applying the MASVS.

##### Examples

###### MASVS-L1

- All mobile apps. MASVS-L1 lists security best practices that can be followed with a reasonable impact on development cost and user experience. Apply the requirements in MASVS-L1 for any app that don't qualify for one of the higher levels.

<!-- \pagebreak -->

###### MASVS-L2

- Health-Care Industry: Mobile apps that store personally identifiable information that can be used for identity theft, fraudulent payments, or a variety of fraud schemes. For the US healthcare sector, compliance considerations include the Health Insurance Portability and Accountability Act (HIPAA) Privacy, Security, Breach Notification Rules and Patient Safety Rule.

- Financial Industry: Apps that enable access to highly sensitive information like credit card numbers, personal information, or allow the user to move funds. These apps warrant additional security controls to prevent fraud. Financial apps need to ensure compliance to the Payment Card Industry Data Security Standard (PCI DSS), Gramm Leech Bliley Act and Sarbanes-Oxley Act (SOX).

###### MASVS L1+R

- Mobile apps where Intellectual Property (IP) protection is a business goal. The resiliency controls listed in MASVS-R can be used to increase the effort needed to obtain the original source code and to impede tampering / cracking.

- Gaming Industry: Games with an essential need to prevent modding and cheating, such as competitive online games. Cheating is an important issue in online games, as a large amount of cheaters leads to a disgruntled player base and can ultimately cause a game to fail. MASVS-R provides basic anti-tampering controls to help increase the effort for cheaters.

###### MASVS L2+R

- Financial Industry: Online banking apps that allow the user to move funds, where techniques such as code injection and instrumentation on compromised devices pose a risk. In this case, controls from MASVS-R can be used to impede tampering, raising the bar for malware authors.

- All mobile apps that, by design, need to store sensitive data on the mobile device, and at the same time must support a wide range of devices and operating system versions. In this case, resiliency controls can be used as a defense-in-depth measure to increase the effort for attackers aiming to extract the sensitive data.

- Apps with in-app purchases should ideally use server-side and MASVS-L2 controls to protect paid content. However, there may be cases where there is no possibility to use server-side protection. In those cases, MASVS-R controls should be additionally applied in order to increase the reversing and/or tampering effort.
Loading

0 comments on commit 77436c0

Please sign in to comment.