diff --git a/.github/workflows/codeql-analysis.yml b/.github/workflows/codeql-analysis.yml index 5760dc6fd..e42780faf 100644 --- a/.github/workflows/codeql-analysis.yml +++ b/.github/workflows/codeql-analysis.yml @@ -38,7 +38,7 @@ jobs: steps: - name: Checkout repository - uses: actions/checkout@v2 + uses: actions/checkout@v3 # Initializes the CodeQL tools for scanning. - name: Initialize CodeQL diff --git a/.github/workflows/config/.markdownlint.json b/.github/workflows/config/.markdownlint.json deleted file mode 100644 index 6f424bebd..000000000 --- a/.github/workflows/config/.markdownlint.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "MD004": {"style": "dash"}, - "MD013": false, - "MD014": false, - "MD024": false, - "MD033": {"allowed_elements": ["img", "br", "div"]}, - "MD036": { - "punctuation": ".,;:!。" - }, - "MD041": false -} \ No newline at end of file diff --git a/.github/workflows/config/mlc_config.json b/.github/workflows/config/mlc_config.json deleted file mode 100644 index 12b2a308a..000000000 --- a/.github/workflows/config/mlc_config.json +++ /dev/null @@ -1,18 +0,0 @@ -{ - "ignorePatterns": [ - { - "pattern": "https://github.com/Your_Github_Handle/owasp-masvs" - },{ - "pattern": "changelog" - } - - ], - "replacementPatterns": [ - { - "pattern": "^.attachments", - "replacement": "file://some/conventional/folder/.attachments" - } - ], - "see":" https://github.com/tcort/markdown-link-check#config-file-format" -} - diff --git a/.markdownlinkcheck.json b/.github/workflows/config/url-checker-config.json similarity index 85% rename from .markdownlinkcheck.json rename to .github/workflows/config/url-checker-config.json index 52b5ed7e0..1e427990b 100644 --- a/.markdownlinkcheck.json +++ b/.github/workflows/config/url-checker-config.json @@ -1,7 +1,7 @@ { "ignorePatterns": [ { - "pattern": "https://www.microsoft.com/en-us/securityengineering/sdl/" + "pattern": "changelog" } ], "httpHeaders": [ diff --git a/.github/workflows/doc-gen-reusable.yml b/.github/workflows/doc-gen-reusable.yml deleted file mode 100644 index 9f501c4ea..000000000 --- a/.github/workflows/doc-gen-reusable.yml +++ /dev/null @@ -1,45 +0,0 @@ -# https://docs.github.com/en/actions/learn-github-actions/reusing-workflows - -on: - workflow_call: - inputs: - language: # English, German, Spanish, etc. - required: true - type: string - lang: # en, de, es , etc. - required: true - type: string - folder: - required: true - type: string - pandocker-tag: - required: false - type: string - pandocker-template: - required: false - type: string - - -jobs: - doc-gen-reusable: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v2 - with: - fetch-depth: 1 - - - name: Set VERSION to env - run: echo "VERSION=$(curl -s https://api.github.com/repos/OWASP/owasp-masvs/tags | jq '.[0].name' | sed 's/\"//g')" >> $GITHUB_ENV - - - name: Set DEV VERSION if it's not a tag - if: ${{ !startsWith(github.ref, 'refs/tags/') }} - run: echo "VERSION=${{env.VERSION}}-$(git rev-parse --short HEAD)" >> $GITHUB_ENV - - - name: Generate ${{ inputs.language }} PDF - run: ${{ inputs.pandocker-tag }} ${{ inputs.pandocker-template }} ./tools/docker/pandoc_makedocs.sh ${{ inputs.folder }} ${{ env.VERSION }} - - - name: Upload Artifacts - uses: actions/upload-artifact@v2 - with: - name: OWASP_MASVS-${{ env.VERSION }}-${{ inputs.lang }} - path: OWASP_MASVS-${{ env.VERSION }}-${{ inputs.lang }}* diff --git a/.github/workflows/docgenerator.yml b/.github/workflows/docgenerator.yml index 3f0eb7630..539717335 100644 --- a/.github/workflows/docgenerator.yml +++ b/.github/workflows/docgenerator.yml @@ -8,129 +8,13 @@ jobs: ## Use `pandocker-tag: TAG=latest-ubuntu-full` for langs that require the special fonts (Russian, Chinese, etc.) ## - en: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document - language: English - lang: en - - de: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-de - language: German - lang: de - - es: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-es - language: Spanish - lang: es - - fr: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-fr - language: French - lang: fr - - ptbr: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-ptbr - language: Brazilian Portuguese - lang: ptbr - - ptpt: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-ptpt - language: Portugal Portuguese - lang: ptpt - - tr: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-tr - language: Turkish - lang: tr - pandocker-tag: TAG=latest-ubuntu-full - - gr: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-gr - language: Hindi - lang: gr - pandocker-tag: TAG=latest-ubuntu-full - - hi: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-hi - language: Hindi - lang: hi - pandocker-tag: TAG=latest-ubuntu-full - - ja: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-ja - language: Japanese - lang: ja - pandocker-tag: TAG=latest-ubuntu-full - - ko: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-ko - language: Korean - lang: ko - pandocker-tag: TAG=latest-ubuntu-full - - ru: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-ru - language: Russian - lang: ru - pandocker-tag: TAG=latest-ubuntu-full - - fa: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-fa - language: Persian - lang: fa - pandocker-tag: TAG=latest-ubuntu-full - - zhcn: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-zhcn - language: Simplified Chinese - lang: zhcn - pandocker-tag: TAG=latest-ubuntu-full - - zhtw: - uses: OWASP/owasp-masvs/.github/workflows/doc-gen-reusable.yml@master - with: - folder: Document-zhtw - language: Traditional Chinese - lang: zhtw - pandocker-tag: TAG=latest-ubuntu-full - - export: + Generate-MASVS-Documents: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v3 with: fetch-depth: 1 - # tag name with the latest tag - # and the abbreviated hash of the most recent commit - name: Set VERSION to env run: echo "VERSION=$(curl -s https://api.github.com/repos/OWASP/owasp-masvs/tags | jq '.[0].name' | sed 's/\"//g')" >> $GITHUB_ENV @@ -138,48 +22,43 @@ jobs: if: ${{ !startsWith(github.ref, 'refs/tags/') }} run: echo "VERSION=${{env.VERSION}}-$(git rev-parse --short HEAD)" >> $GITHUB_ENV - - name: Install pyyaml - run: pip3 install pyyaml + - name: Generate MASVS yaml + run: python3 ./tools/generate_masvs_yaml.py -v ${{ env.VERSION }} - - name: Generate CSV - run: cd tools && python3 export.py --format csv --lang en > OWASP_MASVS-${{env.VERSION}}.csv - - name: Generate JSON - run: cd tools && python3 export.py --format json --lang en > OWASP_MASVS-${{env.VERSION}}.json - - name: Generate XML - run: cd tools && python3 export.py --format xml --lang en > OWASP_MASVS-${{env.VERSION}}.xml - - name: Generate MASVS YAML - run: cd tools && python3 export.py --format yaml --lang en > OWASP_MASVS-${{env.VERSION}}.yaml + - name: Populate MASVS Categories Markdown Files + run: python3 ./tools/populate_masvs_categories_md.py - - name: Upload CSV - uses: actions/upload-artifact@v2 - with: - name: OWASP_MASVS-${{env.VERSION}}.csv - path: tools/OWASP_MASVS-${{env.VERSION}}.csv - - name: Upload JSON - uses: actions/upload-artifact@v2 - with: - name: OWASP_MASVS-${{env.VERSION}}.json - path: tools/OWASP_MASVS-${{env.VERSION}}.json - - name: Upload XML - uses: actions/upload-artifact@v2 + - name: Generate PDF + run: ./tools/docker/pandoc_makedocs.sh Document ${{ env.VERSION }} + + - name: Upload Artifacts + uses: actions/upload-artifact@v3 with: - name: OWASP_MASVS-${{env.VERSION}}.xml - path: tools/OWASP_MASVS-${{env.VERSION}}.xml + name: OWASP_MASVS + path: OWASP_MASVS* + - name: Upload YAML - uses: actions/upload-artifact@v2 + uses: actions/upload-artifact@v3 with: - name: OWASP_MASVS-${{env.VERSION}}.yaml - path: tools/OWASP_MASVS-${{env.VERSION}}.yaml + name: OWASP_MASVS.yaml + path: masvs.yaml release: runs-on: ubuntu-latest - needs: [en, de, fa, es, fr, hi, ja, ko, ptbr, ptpt, ru, zhcn, zhtw, export] + needs: [Generate-MASVS-Documents] if: startsWith(github.ref, 'refs/tags/') && (github.actor == 'cpholguera' || github.actor == 'sushi2k') steps: - uses: actions/download-artifact@v2 + - name: List Downloaded document (sampling of download-artifact) + run: ls -l OWASP_MASVS* + + - name: print working directory + run: pwd + - name: Listing of root directory + run: ls -l - - name: Move all translations (pdf, epub and docx) to root - run: mv OWASP_MASVS-*-*/* . + - name: Move all translations (pdf, and epub) to root + run: mv OWASP_MASVS*/* . - name: Release uses: softprops/action-gh-release@v1 with: @@ -188,11 +67,8 @@ jobs: generate_release_notes: true discussion_category_name: Announcements files: | - OWASP_MASVS-*.pdf - OWASP_MASVS-*.epub - OWASP_MASVS-*.docx - OWASP_MASVS-*.csv/OWASP_MASVS-*.csv - OWASP_MASVS-*.json/OWASP_MASVS-*.json - OWASP_MASVS-*.xml/OWASP_MASVS-*.xml + OWASP_MASVS.pdf + OWASP_MASVS.epub + OWASP_MASVS.yaml/OWASP_MASVS.yaml env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/checkLint.yml b/.github/workflows/markdown-linter.yml similarity index 77% rename from .github/workflows/checkLint.yml rename to .github/workflows/markdown-linter.yml index 7f40683d4..c06e9bf52 100644 --- a/.github/workflows/checkLint.yml +++ b/.github/workflows/markdown-linter.yml @@ -7,12 +7,12 @@ jobs: runs-on: ubuntu-latest steps: - name: Checkout - uses: actions/checkout@v2 + uses: actions/checkout@v3 with: fetch-depth: 1 - name: markdownlint-cli uses: nosborn/github-action-markdown-cli@v2.0.0 with: files: './Document*' - config_file: ".github/workflows/config/.markdownlint.json" + config_file: ".markdownlint.jsonc" ignore_files: "tools, node_modules" diff --git a/.github/workflows/codespell.yml b/.github/workflows/spell-checker.yml similarity index 53% rename from .github/workflows/codespell.yml rename to .github/workflows/spell-checker.yml index a55000012..5d1aec270 100644 --- a/.github/workflows/codespell.yml +++ b/.github/workflows/spell-checker.yml @@ -1,11 +1,11 @@ -name: codespell +name: Spell Checker on: [pull_request, push] jobs: - codespell: + spell-check: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v2 + - uses: actions/checkout@v3 - uses: codespell-project/actions-codespell@master with: path: ./Document - ignore_words_list: ba,compliancy,firt,ist,keypair,ligh,ser,synopsys,zuser + ignore_words_list: OWASP,MASVS,MASTG diff --git a/.github/workflows/url-checker-pr.yml b/.github/workflows/url-checker-pr.yml new file mode 100644 index 000000000..146a655fe --- /dev/null +++ b/.github/workflows/url-checker-pr.yml @@ -0,0 +1,21 @@ +name: URL Checker (PR) + +on: + pull_request: + +jobs: + markdown-link-check: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v3 + with: + fetch-depth: 1 + - name: link-check + uses: gaurav-nelson/github-action-markdown-link-check@v1 + with: + use-quiet-mode: 'yes' + use-verbose-mode: 'yes' + config-file: '.github/workflows/config/url-checker-config.json' + folder-path: '.' + check-modified-files-only: 'yes' diff --git a/.github/workflows/checkLinks.yml b/.github/workflows/url-checker.yml similarity index 69% rename from .github/workflows/checkLinks.yml rename to .github/workflows/url-checker.yml index 378b1b894..8299adc52 100644 --- a/.github/workflows/checkLinks.yml +++ b/.github/workflows/url-checker.yml @@ -1,19 +1,17 @@ -name: URLs Checker +name: URL Checker on: + workflow_dispatch: push: branches: - master - pull_request: - branches: - - master jobs: markdown-link-check: runs-on: ubuntu-latest steps: - name: Checkout - uses: actions/checkout@v2 + uses: actions/checkout@v3 with: fetch-depth: 1 - name: link-check @@ -21,5 +19,5 @@ jobs: with: use-quiet-mode: 'yes' use-verbose-mode: 'yes' - config-file: '.github/workflows/config/mlc_config.json' + config-file: '.github/workflows/config/url-checker-config.json' folder-path: '.' diff --git a/.markdownlint.json b/.markdownlint.json deleted file mode 100644 index 6f424bebd..000000000 --- a/.markdownlint.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "MD004": {"style": "dash"}, - "MD013": false, - "MD014": false, - "MD024": false, - "MD033": {"allowed_elements": ["img", "br", "div"]}, - "MD036": { - "punctuation": ".,;:!。" - }, - "MD041": false -} \ No newline at end of file diff --git a/.markdownlint.jsonc b/.markdownlint.jsonc new file mode 100644 index 000000000..89e6b4dd1 --- /dev/null +++ b/.markdownlint.jsonc @@ -0,0 +1,16 @@ +{ + // https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md + + "MD004": {"style": "dash"}, // ul-style + "MD013": false, // line-length + "MD024": {"allow_different_nesting": true}, // no-duplicate-header + "MD026": {"punctuation": ".,;:"}, // no-trailing-punctuation (allows !?) + "MD033": false, // no-inline-html + "MD035": {"style": "---"}, // hr-style + "MD036": {"punctuation": ".,;:!。"}, // no-emphasis-as-header + "MD041": false, // first-line-h1 + "MD046": {"style": "fenced"} , // code-block-style + "MD049": {"style": "underscore"}, // emphasis-style + "MD050": {"style": "asterisk"} // strong-style + +} \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4975f83c3..049264b44 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,3 +1,3 @@ # Contributing -Learn how you can contribute to the OWASP Mobile Application Security project [here](https://github.com/OWASP/owasp-mastg/blob/master/docs/contributing/1_How_Can_You_Contribute.md). +Learn how you can contribute to the OWASP Mobile Application Security project [here](https://mas.owasp.org/contributing/). diff --git a/Document-de/0x01-Foreword.md b/Document-de/0x01-Foreword.md deleted file mode 100644 index b002ff885..000000000 --- a/Document-de/0x01-Foreword.md +++ /dev/null @@ -1,30 +0,0 @@ -# Vorwort - -Technologierevolutionen können sehr schnell gehen. Noch vor 10 Jahren waren Smartphones klobige Geräte mit kleinen Tastaturen - teure Spielgeräte für technikverliebte Geschäftsleute. Heute sind Smartphones ein wesentlicher Bestandteil unseres Lebens. Wir hängen inzwischen von ihnen ab und nutzen sie zur Information, Navigation und Kommunikation. Sie sind allgegenwärtig - in der Geschäftswelt und im privaten Umfeld. - -Jede neue Technologie bringt neue Sicherheitsrisiken mit sich. Eine der größten Herausforderungen für alle, die im Sicherheitsumfeld arbeiten, ist Schritt zu halten mit der fortlaufenden Weiterentwicklung. Das blaue Team (Verteidigerseite) liegt dabei immer einige Schritte hinter dem roten Team (Angreiferseite) zurück. Viele unterlagen deshalb zu Beginn dem Trugschluss, altbekannte Vorgehensweisen direkt auf das mobile Umfeld anzuwenden im Sinne von: "Smartphones sind im Prinzip nur kleine PCs und mobile Apps sind wie klassische Software - folglich gelten die gleichen Sicherheitsanforderungen". Jedoch funktioniert das so nicht. -Mobile Betriebssysteme unterscheiden sich von Desktop-Betriebssystemen und mobile Apps sich von Webanwendungen. Zum Beispiel macht die klassische Methode Virenprüfungen auf Basis von Signaturen durchzuführen in modernen mobilen Betriebssystemumgebungen keinen Sinn. Es ist nicht nur inkompatibel zur Art und Weise, wie mobile Apps verteilt werden, sondern darüber hinaus aufgrund des Betriebssystemdesigns (Sandbox-Isolation) von Apps technisch überhaupt nicht umsetzbar. Bei gewöhnlichen 08/15-Apps sind zudem eine Reihe von Schwachstellen wie Buffer overflows und XSS weniger relevant als in Webanwendungen und Desktopanwendungen (Ausnahmen möglich). -Über die Zeit hat sich das gewandelt und die Securitybranche hat nun eine bessere Vorstellung für die mobile Bedrohungslage entwickelt. - -Der Datenschutz steht im Mittelpunkt mobiler Sicherheit. Apps speichern persönliche Informationen, Fotos, Aufnahmen, Notizen, Kontodaten, Geschäftsdaten, Standortdaten und viele mehr. Sie dienen uns als tägliche Helfer um uns mit Daten- und Kommunikationsdiensten zu verbinden, die jede einzelne der Nachrichten, die wir mit anderen austauschen, verarbeiten. Übernimm die Kontrolle über ein Smartphone und Du erhältst ungefilterten Zugriff auf das Leben der betreffenden Person. Wenn man sich vorstellt, dass Mobilgeräte durchaus verloren gehen oder gestohlen werden können und sich mobile Schadsoftware im Aufwärtstrend befindet, wird der hohe Bedarf an Datenschutz nochmals mehr deutlich. Ein Sicherheitsstandard für mobile Apps muss deshalb klar im Fokus haben, wie mobile Apps mit sensiblen Daten umgehen, sie verarbeiten und speichern. - -Moderne mobile Betriebssysteme wie iOS und Android bieten gute APIs für sichere Datenspeicherung und Kommunikation - Diese müssen allerdings auch implementiert und dabei korrekt genutzt werden, um effektiv zu sein. Datenspeicherung, Interprozesskommunikation, korrekte Nutzung kryptografischer APIs und sichere Netzwerkkommunikation sind nur ein paar der Aspekte die eine sorgfältige Betrachtung erfordern. - -Eine wichtige Frage, die man sich stellen muss, ist, wie weit und wie umfangreich Schutzmaßnahmen umzusetzen sind und wo die Grenze liegt. Zum Beispiel würden die meisten zustimmen, dass eine mobile App das Serverzertifikat bei einem TLS-Handshake prüfen muss. Was ist jedoch mit SSL-Zertifikat-Pinning? Führt es direkt zu einer Schwachstelle, es nicht umzusetzen? Sollte dies eine Anforderung sein, wenn eine App sensible Daten verarbeitet oder ist es eventuell sogar contra-produktiv? Müssen wir Daten in einer SQLite-Datenbank verschlüsseln, wenn doch das Betriebssystem bereits ein Sandbox-Konzept mitbringt? Was für die eine App angemessen ist, kann für eine andere App unrealistisch sein. Der MASVS ist ein Versuch, diese Anforderungen zu standardisieren und Prüf-Level einzuführen die zu unterschiedlichen Bedrohungsszenarien passen. - -Darüber hinaus hat das Erscheinen von Root-Malware und Remote-Administrations-Tools gezeigt, dass mobile Betriebssysteme selbst ausnutzbare Schwachstellen haben. Um Client-seitige Manipulation zu verhindern und den Schutz sensibler Daten zu erhöhen, kommen vermehrt zusätzliche Container-basierte Isolations-Technologien zum Einsatz. An dieser Stelle wird es kompliziert. Es gibt Hardware-basierte Sicherheitsmechanismen und Betriebssystemseitige Container-Lösungen wie Android for Work und Samsung Knox aber nicht durchgängig für alle Geräte. Als Notlösung sind Software-basierte Schutzmechanismen möglich jedoch existieren leider keine Standards sowie Testprozesse zu deren Prüfung. - -Als Folge davon existieren zahlreiche mobile Sicherheitstestberichte bei denen die Tester fehlende Obfuskierung oder fehlende Root-Erkennung in einer Android-App als "Sicherheitslücke" werten. Auf der anderen Seite werden Maßnahmen wie Verschlüsselung von Zeichenketten, Erkennung von Debuggern oder Kontrollfluss-Obfuskierung nicht als verpflichtend erachtet. Letztlich ergibt dieses "schwarz-weiss Denken" keinen Sinn, denn Resilienz ist keine binäre Eigenschaft, sondern hängt davon ab gegen welche konkreten Client-seitigen Bedrohungen man sich schützen möchte. Software-Schutzmaßnahmen zur Erhöhung der Resilienz bringen gewissen Nutzen jedoch können sie definitiv umgangen werden und dürfen deshalb niemals als Ersatz für Sicherheitsmaßnahmen dienen. - -Das übergeordnete Ziel des MASVS ist es mit dem MASVS-L1 ein solides Basis-Sicherheitsniveau, mit dem MASVS-L2 ein erhöhtes Sicherheitsniveau sowie kontextbezogen weitere Defense-in-Depth-Maßnahmen gegen Client-seitige Bedrohungen (MASVS-R) für mobile App-Sicherheit anzubieten. - -Folgendes soll mit dem MASVS erreicht werden: - -- Bereitstellen von Sicherheitsanforderungen für Softwarearchitekten und Entwickler um sichere mobile Applikationen zu entwickeln; -- Definition eines Branchenstandards, gegen den mobile Apps in Sicherheits-Reviews getestet werden können; -- Schärfung und Klarstellung der Rolle von Schutzmechanismen in der mobilen Sicherheit und Definition von Anforderungen um deren Effektivität zu prüfen; -- Aussprechen von individuellen Empfehlungen zur Anwendung von mobilen Sicherheitsmechanismen für verschiedene Anwendungsfälle. - -Wir sind uns bewusst, dass ein 100%-iger Konsens innerhalb der Sicherheitsbranche unmöglich zu erreichen ist. Nichtsdestotrotz hoffen wir, dass der MASVS eine nützliche Hilfestellung für alle Phasen mobiler Softwareentwicklung und Tests darstellt. Als offener Standard soll der MASVS sich über die Zeit weiterentwickeln und wir begrüßen jede Unterstützung und Vorschläge. - -Von Bernhard Mueller diff --git a/Document-de/0x02-Frontispiece.md b/Document-de/0x02-Frontispiece.md deleted file mode 100644 index bb548fa6d..000000000 --- a/Document-de/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Über den Standard - -![OWASP Logo](images/OWASP_logo.png) - -Willkommen beim Mobile Application Security Verification Standard (MASVS). Der MASVS ist eine Community-Initiative mit dem Ziel ein Rahmenwerk von Security-Anforderungen für Design, Entwicklung und Test von mobilen Apps unter iOS und Android zu etablieren. - -Der MASVS vereint Community Engagement und Feedback aus der Praxis. Wir gehen davon aus, dass der Standard sich über die Zeit weiter entwickelt und begrüßen jedes Feedback aus der Community. Der beste Weg mit uns in Kontakt zu treten ist der OWASP Mobile Project Slack Channel: -[https://owasp.slack.com/messages/](https://owasp.slack.com/messages/project-mobile_omtg/details/). - -Nutzerkonten können unter folgender URL angelegt werden: -[https://owasp.slack.com/join](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Copyright and License - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Dieses Dokument ist veröffentlicht unter der Creative Commons Attribution ShareAlike 3.0 Lizenz. Für jedwede Wiederverwendung oder Vertrieb müssen diese Lizenzbestimmungen klar kommuniziert werden. - - - -## Danksagungen - -| Project Lead | Lead Author | Mitwirkende and Reviewer | -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Sprache | Übersetzer und Gutachter | -| --------------- | ------------------------------------------------------------ | -| Chinesisch (Traditionell) | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| Chinesisch (Vereinfacht) | Bob Peng, Harold Zang, Jack S | -| Deutsch | Rocco Gränitz, Sven Schleier (Review) | -| Französisch | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| Japanisch | Koki Takeyama, Riotaro Okada (Review) | -| Koreanisch | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| Persisch (Farsi) | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| Portugiesisch (Brasilien) | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Portugiesisch | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Russisch | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Spanisch | Martin Marsicano, Carlos Holguera | -| Türkisch | Anıl Baş, Haktan Emik | -| Griechisch | Panagiotis Yialouris | - -Dieses Dokument basiert auf einem Fork des OWASP Application Security Verification Standard verfasst von Jim Manico. - -## Sponsoren - -Obwohl beide Projekte, der MASVS und der MASTG, auf freiwilliger Basis im Rahmen der Community erarbeitet wurden und weiter gepflegt werden, ist manchmal ein wenig Hilfe von außen nötig. Wir danken deshalb den Sponsoren, mit deren Hilfe wir technische Editoren akquirieren können. Der Inhalt des MASVS oder MASTG ist in keinster Weise durch etwaige Sponsoren beeinflusst. Eine nähere Beschreibung der Sponsoren-Pakete befindet sich im [OWASP Projekt Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -Zum Schluss möchten wir uns bei allen bedanken, die das Buch von Leanpub gekauft und uns auf diese Weise gesponsert haben. diff --git a/Document-de/0x03-Using_the_MASVS.md b/Document-de/0x03-Using_the_MASVS.md deleted file mode 100644 index e5b5408e6..000000000 --- a/Document-de/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,80 +0,0 @@ -# Der Mobile Application Security Verification Standard - -Der MASVS kann genutzt werden um das Sicherheitsniveau von mobilen Apps nachweisen zu können. Die Anforderungen wurden auf Basis folgender Ziele entwickelt: - -- Nutzung als Metrik - Um Entwicklern und Applikations-Verantwortlichen einen Security Standard anzubieten gegen den existierende mobile Apps verglichen werden können; -- Nutzung als Hilfestellung - Um Hilfe zu bieten in allen Phasen mobiler App-Entwicklung und Tests. -- Nutzung bei Beschaffung/Kauf von mobilen Apps - Um als Baseline zur Prüfung der Security von mobilen Apps zu dienen. - -## Das Mobile AppSec Model - -Der MASVS definiert zwei Prüf-Level (L1 und L2), sowie eine Reihe von Sicherheitsmaßnahmen zur Robustheit gegen Reverse Engineering (MASVS-R). Diese sind flexibel, d.h. adaptierbar an ein App-spezifisches Threat Model. MASVS-L1 enthält generische Sicherheitsanforderungen und wird für alle mobilen Apps empfohlen, während MASVS-L2 für Apps verwendet werden sollte die hochsensible Daten verarbeiten. MASVS-R deckt zusätzliche Schutzmaßnahmen ab, die anzuwenden sind, um Client-seitigen Threats vorzubeugen. - -Eine App die alle Anforderungen aus MASVS-L1 erfüllt, folgt Security Best Practices und vermeidet damit typische Schwachstellen. MASVS-L2 fügt weitere Defense-In-Depth Maßnahmen wie SSL-Pinning hinzu, um ein erhöhtes Schutzniveau gegen komplexere Angriffe zu bieten. Dabei gilt die Annahme, dass das mobile Betriebssystem intakt und der Endnutzer nicht als potenzieller Angreifer betrachtet wird. Die Anforderungen aus dem MASVS-R ganz oder teilweise zu erfüllen, hilft dabei spezifische client-seitige Threats (böswilliger Nutzer o. kompromittiertes Betriebssystem) zu verhindern bzw. zu erschweren. - -**I: Die Schutzmaßnahmen enthalten in MASVS-R und beschrieben im OWASP Mobile Application Security Testing Guide können letztlich alle umgangen werden und dürfen nicht als Ersatz für Sicherheitsmaßnahmen (L1/L2) genutzt werden. Stattdessen sind sie dazu gedacht, um zusätzliche Threat-spezifische Schutzmaßnahmen zu Apps hinzuzufügen, die bereits die MASVS Anforderungen L1 oder L2 erfüllen.** - -**II: Bitte beachte das alle Anforderungen, die in MASVS-R aufgelistet und im OWASP Mobile Application Security Testing Guide beschrieben sind, immer umgangen werden können. Daher sollten diese auch nie als Ersatz für Sicherheitsmaßnahmen verwendet werden. Stattdessen ist die Intention von MASVS-R zusätzliche bedrohungsspezifische Gegenmaßnahmen für Apps zu definieren, die bereits die Anforderungen in MASVS-L1 oder MASVS-L2 erfüllen.** - -![Prüf-Level](images/masvs-levels-new.jpg) - -### Dokumentstruktur - -Der erste Teil des MASVS enthält eine Beschreibung des Security Modells und der Prüf-Level, gefolgt von Empfehlungen zur Nutzung des Standards in der Praxis. Die detaillierten Sicherheitsanforderungen und ihre Einordnung in die Prüf-Level befinden sich im zweiten Teil. Die Anforderungen wurden in acht Kategorien (V1 bis V8), basierend auf technischen Zielen/Scopes, eingeteilt. Die folgende Nomenklatur wird durchgehend im MASVS und MASTG genutzt: - -- *Anforderungs Kategorie:* MASVS-Vx, z.B. MASVS-V2: Datenspeicherung und Datenschutz -- *Anforderung:* MASVS-Vx.y, z.B. MASVS-V2.2: "Keine sensiblen Daten werden in Applikations Logs geschrieben." - -### Prüf-Level im Detail - -#### MASVS-L1: Standard Security - -Eine mobile App die MASVS-L1 entspricht, erfüllt Mobile Application Best Practices. Sie erfüllt Basis-Anforderungen in Bezug auf Codequalität, Umgang mit sensiblen Daten und Interaktion mit dem mobilen Umfeld. Es gibt einen Testprozess, um die Effektivität der Security Maßnahmen zu prüfen. Dieser Level eignet sich für alle mobilen Applikationen. - -#### MASVS-L2: Defense-in-Depth - -MASVS-L2 führt erweiterte Sicherheitsmaßnahmen ein, die über die Standardanforderungen hinausgehen. Um L2 zu erfüllen, muss ein Threat Model existieren und Security muss ein integraler Teil der App-Architektur sein. Dieser Level ist angedacht für alle Apps, die sensible Daten verarbeiten wie z.B. Apps für mobiles Bezahlen. - -#### MASVS-R: Resilienz gegen Reverse Engineering and Manipulation - -Die App hat state-of-the-art Security und ist resilient (robust) gegen spezifische, klar definierte Client-seitige Angriffe wie Manipulation, Modifizierung oder Reverse Engineering um sensiblen Quellcode oder Daten zu extrahieren. Solch eine App nutzt Hardware Security Funktionen oder ausreichend starke und überprüfbare Software-Schutzmaßnahmen. MASVS-R ist geeignet für Apps, die hochsensible Daten verarbeiten, um geistiges Eigentum zu schützen oder um eine App manipulationssicher zu machen. - -### Empfohlene Nutzung - -Nach vorheriger Bewertung des Risikos und des erforderlichen Sicherheitsniveaus können Apps gegen MASVS L1 oder L2 geprüft werden. L1 ist geeignet für alle mobilen Apps, während L2 für Apps mit mehr sensiblen Daten oder sensibler Funktionalität empfohlen wird. MASVS-R (oder Teile davon) können genutzt werden um *zusätzlich zu bereits implementierten Sicherheitsfunktionen* die Resilienz der App gegen spezifische Threats wie Repackaging oder Extraktion von sensiblen Daten zu prüfen. - -Insgesamt gibt es folgende Prüfkombinationen: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Die Kombinationen stellen verschiedene Graduierungen der Security und Resilienz dar. Das Ziel ist Flexibilität: Eine Gaming-App z.B. wird aus Usability-Gesichtspunkten darauf verzichten, MASVS-L2 Maßnahmen wie 2-Faktor Authentifizierung zu nutzen hat jedoch aus Business-Sicht hohen Schutzbedarf gegen Code-Manipulation (Tampering). - -#### Prüfvariante wählen - -Die Anforderungen aus MASVS L2 zu implementieren erhöht die Sicherheit - dies kann sich jedoch negativ auf die Endnutzerakzeptanz auswirken (klassischer Kompromiss). Zeitgleich steigen die Entwicklungskosten. - -##### Beispiele - -###### MASVS-L1 - -- Geeignet für alle mobilen Apps. MASVS-L1 benennt Security Best Practices mit akzeptablen Auswirkungen auf Entwicklungskosten und Nutzererlebnis. Sollte für jede App genutzt werden die keinen höheren Level erfordert. - -###### MASVS-L2 - -- Gesundheitswesen: Mobile Apps, die personenbezogene Daten speichern, die für Identitätsdiebstahl, Zahlungsbetrug und eine Reihe anderer Betrugsvorhaben genutzt werden können. Zu den für den US-Gesundheitsbereich geltenden Compliance-Regeln gehören der Health Insurance Portability and Accountability Act (HIPAA), Datenschutz, Security und Vorgaben/Regeln zur Benachrichtigung bei Datenpannen sowie Patientensicherheit. -- Banken/Finanzwesen: Apps mit Zugriff auf hochsensible Daten wie Kreditkarten, personenbezogene Daten oder die Zahlungsflüsse erlauben. Diese Apps erfordern erweiterte Security Maßnahmen, um Betrug zu vermeiden. Finanz-Apps müssen Compliance-Anforderungen aus dem Payment Card Industry Data Security Standard (PCI DSS), Gramm Leech Bliley Act und Sarbanes-Oxley Act (SOX) erfüllen. - -###### MASVS L1+R - -- Mobile Apps für die der Schutz des geistigen Eigentums geschäftskritisch ist. Die Resilienz-Maßnahmen aus MASVS-R dienen dazu, für Angreifer den Aufwand zu erhöhen um an den Original-Quellcode zu gelangen und Manipulation der Apps (Tampering/Cracking) zu erschweren. -- Gaming Industrie: Spiele mit hohem Bedarf Modding und Cheating zu verhindern, wie Online-Games. Cheating ist ein großes Problem in Online-Spielen, da eine hohe Anzahl von Cheatern die regulären Nutzer verärgern und ein erfolgreiches Game letztlich zum Scheitern bringen kann. MASVS-R bietet Basis-Maßnahmen, um den Aufwand für Cheater zu erhöhen. - -###### MASVS L2+R - -- Finanzwesen: Online Banking Apps, die Nutzern Geldtransfers erlauben und bei denen Techniken wie Code-Injektion oder Instrumentierung auf kompromittierten Geräten Risiken darstellen. In diesem Fall können Maßnahmen aus dem MASVS-R genutzt werden, um Manipulationen zu erschweren und den Aufwand für Malware Autoren zu erhöhen. -- Alle mobilen Apps, die sensible Daten auf dem mobilen Gerät speichern und gleichzeitig eine hohe Kompatibilität zu diversen Geräten und Betriebssystemversionen bieten müssen. In diesem Fall können Resilienz-Maßnahmen als defense-in-depth genutzt werden um den Aufwand für Angreifer, die sensible Daten extrahieren wollen, zu erhöhen. - -- Apps die In-App Bezahlung anbieten, sollten die Anforderungen in MASVS-L2 und server-seitige Schutzmaßnahmen benutzen, um bezahlte Inhalte zu beschützen. In Fällen in denen server-seite Schutzmaßnahmen nicht verwendet werden können, sollten die Anforderungen von MASVS-R berücksichtigt werden, um Reverse Engineering zu erschweren. diff --git a/Document-de/0x04-Assessment_and_Certification.md b/Document-de/0x04-Assessment_and_Certification.md deleted file mode 100644 index e6fa0867d..000000000 --- a/Document-de/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# Bewertung und Zertifizierung - -## OWASP's Standpunkt zu MASVS Zertifizierungen und Gütesiegeln - -OWASP ist eine herstellerunabhängige Non-Profit-Organisation und führt keine Zertifizierungen von Herstellern, Prüfern oder Software durch. - -OWASP distanziert sich von derartigen Bescheinigungen, Qualitätssiegeln oder Zertifikaten. Diese sind in keinem Fall durch OWASP freigegeben, registriert oder zertifiziert. Eine Organisation/Unternehmen sollte vorsichtig und misstrauisch gegenüber derartigen Gütesiegeln sein. - -Dies sollte Organisationen nicht davon abhalten Dienstleistungen auf Basis des (M)ASVS Standard anzubieten, solange keine offiziellen OWASP Zertifikate ausgestellt werden. - -## Anleitung zur Zertifizierung von mobilen Apps - -Der empfohlene Weg um eine mobile App gegen den MASVS zu prüfen ist das offene Review-Format. Dabei erhalten Tester Zugriff auf Schlüsselressourcen wie Architekten und App-Entwickler, Projekt-Dokumentation, Quellcode und authentifizierten Zugriff auf API-Endpunkte (mindestens ein Nutzeraccount für jede Rolle) - -Es ist wichtig zu erwähnen, dass der MASVS nur die Security auf der client-seitigen mobilen App und der Netzwerkkommunikation zwischen App und API-Endpunkt(en) sowie einige Basisanforderungen in Bezug auf Nutzerauthentifizierung und Session Management abdeckt. Er enthält darüber hinaus keine spezifischen Security-Anforderungen für remote Services z.B. Webservices die von der App genutzt werden. Jedoch schreibt MASVS V1 vor, dass API-Endpunkte von einem übergreifenden Threat Model berücksichtigt und gegen entsprechende Standards wie ASVS geprüft werden müssen. - -Eine Zertifizierungsstelle muss in jedem Report den Scope der Überprüfung (insbesondere wenn eine Schlüsselkomponente out of scope ist), eine Zusammenfassung der Prüfungs-Findings, inklusive einer Auflistung aller erfolgreich durchgeführten sowie gescheiterten Tests sowie klare Lösungshinweise zu allen gescheiterten Tests aufführen. Eine Sammlung detaillierter Arbeitspapiere, Screenshots oder Demo-Videos, Skripte um eine gefundene Schwachstelle zuverlässig und wiederholt zu exploiten aber auch elektronische Aufzeichnungen/Logs wie Traffic-Mitschnitte durch einen Proxy und zugehörige Notizen wie z.B. eine ToDo-Liste oder Cleanup-Liste aufzubewahren gilt als "Best Practice". Es ist unzureichend einfach nur ein Tool zu starten und die Findings zu berichten. Stattdessen ist es wichtig Beweise zu liefern, dass alle geforderten Themenpunkte gründlich getestet wurden. Für den Fall von Streitigkeiten sollten ausreichend Nachweise vorliegen um darlegen zu können, dass jede zu prüfende Anforderung tatsächlich getestet wurde. - -### Nutzung des OWASP Mobile Application Security Testing Guide (MASTG) - -Der OWASP MASTG ist eine Anleitung zum Testen der Sicherheit von mobilen Apps. Der Guide beschreibt den technischen Prozess zur Überprüfung der Anforderungen aus dem MASVS. Der MASTG enthält eine Liste von Testfällen. Jeder Testfall referenziert eine einzelne Anforderung im MASVS. Während der MASVS eher grobe und generische Anforderungen enthält, bietet der MASTG detaillierte Empfehlungen und Testprozeduren je mobilem Betriebssystem. - -### Die Rolle von Werkzeugen für automatisierte Security Tests - -Die Nutzung von Quellcode-Scannern und Black-Box-Test-Werkzeugen erhöht die Effizienz und wird klar empfohlen. Allerdings ist eine vollständige MASVS Überprüfung allein mit automatisierten Werkzeugen unmöglich. Jede mobile App ist unterschiedlich und ein Verständnis der Gesamtarchitektur, der Geschäftslogik und technischer Fallstricke genutzter Technologien und Frameworks ist eine zwingende Voraussetzung um die Sicherheit einer App zu prüfen. - -## Andere Anwendungsfälle - -### Als detaillierter Security-Architektur-Guide - -Der MASVS ist eine wertvolle Ressource für Security Architekten. Den 2 wichtigsten Security-Architektur-Frameworks SABSA und TOGAF fehlen wesentliche Teile um Security-Architektur-Reviews für mobile Apps durchführen zu können. Der MASVS kann genutzt werden, um diese Lücken zu schließen und ist eine wertvolle Hilfe bei der Auswahl geeigneter Security Maßnahmen im Bereich mobiler Apps. - -### Als Ersatz für pauschale Secure Coding Checklisten - -Viele Organisationen können davon profitieren, den MASVS zu adaptieren, indem Sie einen geeigneten Level wählen oder den MASVS als Ausgangsbasis nutzen (Forking) und die Inhalte entsprechend zum Risikoprofil und Domänen-Kontext der jeweiligen App anpassen. Dieser Weg des Forkens wird empfohlen wobei darauf zu achten ist, die Nachverfolgbarkeit der einzelnen Themenpunkte zu gewährleisten. So sollte z.B. Anforderung 4.1 auch nach zukünftigen Änderungen die gleiche semantische Bedeutung behalten. - -### Als Basis für Security Tests - -Eine gute Testmethodik für Security Tests mobiler Apps sollte alle Anforderungen aus dem MASVS abdecken. Der OWASP MASTG beschreibt Black-box und White-box Testfälle für jede Anforderungen aus dem MASVS. - -### Als Vorgabe für automatisierte Unit- und Integrationstests - -Um die Anzahl von Findings in der Vorproduktions-Phase zu reduzieren, sollten bereits während der Entwicklung automatische Unit-, Integrations- und Akzeptanztests durchgeführt werden. Um dies zu unterstützen wurde der MASVS mit starkem Fokus auf Testbarkeit entwickelt. Eine Ausnahme bilden die Anforderungen aus dem Bereich Architektur. Teams, die die Anforderungen aus dem ASVS (über automatisierte Tests) umsetzen erhöhen dadurch nicht nur die Qualität der entwickelten Apps, sondern verbessern auch die Security Awareness der Entwickler. - -### Zum Training für sichere Software-Entwicklung - -Der MASVS kann darüber hinaus genutzt werden, um die Merkmale zu beschreiben, die eine sichere mobile App haben sollte. Viele Kurse für "sichere Softwareentwicklung" sind simple Kurse über Hacking-Techniken und bieten kaum wertvolle Tipps für Entwickler. Kurse die auf Basis des MASVS proaktive Schutz-Maßnahmen in den Vordergrund stellen, anstatt z.B. die Top 10 Schwachstellen zu behandeln, bieten wesentlichen Mehrwert für Entwickler. diff --git a/Document-de/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-de/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 9d32fe419..000000000 --- a/Document-de/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: Anforderungen an Architektur, Design und Bedrohungsanalysen - -## Zielsetzung - -In einer perfekten Welt würde Security über alle Phasen der Softwareentwicklung berücksichtigt werden. In der Realität wird Security jedoch meist erst spät im Entwicklungsprozess berücksichtigt. Neben den technischen Maßnahmen fordert der MASVS auch organisatorische Maßnahmen die sicherstellen, dass Security in der Planungsphase sowie beim Design der mobilen App entsprechend Berücksichtigung gefunden hat. Für jede Komponente der App muss der fachliche Funktionsumfang und Sicherheitsfunktionen klar definiert und bekannt sein. Die meisten Apps kommunizieren mit entfernten Schnittstellen (API-Endpunkten). Deshalb müssen auch für diese API-Endpunkte angemessene Security Standards umgesetzt sein. Der isolierte Test einer mobilen App ohne die Endpunkte ist unzureichend! - -Die Kategorie "V1" enthält Sicherheitsanforderungen an die Architektur und das Design einer App. Aufgrund dessen ist dies die einzige Kategorie die nicht auf technische Testfälle in den OWASP Mobile Testing Guide referenziert. Um Themen wie Bedrohungsanalyse, sichere Softwareentwicklungsprozesse und Schlüssel-Management abzudecken, sollten Anwender des MASVS die jeweiligen OWASP Projekte und/oder Standards wie die unten verlinkten Dokumente berücksichtigen. - -## Security Anforderungen - -Die Anforderungen für MASVS-L1 und MASVS-L2 sind nachfolgend aufgelistet. - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Alle Komponenten der mobilen App sind identifiziert und für den Betrieb der App erforderlich. | x | x | -| **1.2** | MSTG-ARCH-2 | Sicherheitsfunktionen sind niemals nur auf Client-Seite implementiert, sondern immer auch im entsprechenden entfernten API-Endpunkt. | x | x | -| **1.3** | MSTG-ARCH-3 | Es existiert eine Architekturübersicht über die mobile App und alle verbundenen API-Endpunkte und Security wurde in der Gesamtarchitektur berücksichtigt. | x | x | -| **1.4** | MSTG-ARCH-4 | Alle sensiblen Daten im Kontext der mobilen App wurden klar identifiziert. | x | x | -| **1.5** | MSTG-ARCH-5 | Für jede Komponente der App ist der angebotene fachliche Funktionsumfang und/oder Sicherheitsfunktionen/-mechanismen klar definiert. | | x | -| **1.6** | MSTG-ARCH-6 | Für die mobile App und die genutzten API-Endpunkte wurde eine Bedrohungsanalyse durchgeführt und potenzielle Bedrohungen und Gegenmaßnahmen identifiziert. | | x | -| **1.7** | MSTG-ARCH-7 | Alle Sicherheitsfunktionen wurden in Form von zentralen Komponenten implementiert. | | x | -| **1.8** | MSTG-ARCH-8 | Eine dedizierte Richtlinie zum Management von kryptografischen Schlüsseln (falls in der App genutzt) beschreibt den sicheren Umgang mit Schlüsseln über den gesamten Lebenszyklus, idealerweise basierend auf Standards wie NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | Es gibt einen Mechanismus in der mobilen App, um App-Aktualisierungen zu erzwingen. | | x | -| **1.10** | MSTG-ARCH-10 | Security wird in allen Teilen des Softwareentwicklungszyklus berücksichtigt. | | x | -| **1.11** | MSTG-ARCH-11 | Eine "Responsible Disclosure Policy" ist vorhanden und wird umgesetzt. | | x | -| **1.12** | MSTG-ARCH-12 | Die App sollte Datenschutzgesetze und Regulierungen befolgen. | x | x | - -## Referenzen - -Für weitere Informationen: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat Modeling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 (Recommendation for Key Management) - -- security.txt - diff --git a/Document-de/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-de/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 4e98042f4..000000000 --- a/Document-de/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V2: Anforderungen an Datenspeicherung und Datenschutz - -## Zielsetzung - -Der Schutz sensibler Daten wie Nutzer-Anmeldedaten und privaten Informationen ist ein Schwerpunkt im Bereich mobiler Sicherheit. Zum Beispiel können sensible Daten ungewollt anderen Apps auf dem mobilen Gerät zur Verfügung gestellt werden, falls Betriebssystem-Mechanismen wie Interprozesskommunikation auf unsichere Weise genutzt werden. Datenlecks können ungewollt im Bereich Cloud-Daten-Speicherung, Backups oder dem Tastatur-Cache auftreten. Darüber hinaus können mobile Geräte leichter verloren gehen oder gestohlen werden. Die Wahrscheinlichkeit für physische Angriffe ist höher als bei anderen Geräten. In diesem Fall können zusätzliche Schutzmaßnahmen implementiert werden, um den Zugriff auf sensible Daten zu erschweren. -Im MASVS steht die App im Mittelpunkt und nicht das mobile Gerät. Security-Lösungen für mobiles Gerätemanagement (MDM) werden aus OWASP Sicht zwar zur Umsetzung von Security-Richtlinien im Unternehmens-Umfeld empfohlen, werden im MASVS jedoch nicht berücksichtigt. - -### Definition sensibler Daten - -Sensible Daten im Kontext des MASVS sind jegliche Nutzer-Anmeldedaten sowie alle übrigen Daten die entsprechend ihrem Kontext sensibel sind: - -- Personenbezogene Daten, die für Identitätsdiebstahl genutzt werden können: Sozialversicherungsnummern, Kreditkarteninformationen, Bankdaten und Gesundheitsdaten; -- Hoch sensible Daten deren Kompromittierung zu hohem Reputationsverlust oder finanziellen Aufwänden führen würde: Vertragsinformationen, Informationen die durch Verschwiegenheitserklärungen geschützt sind, Management Informationen; -- Alle Daten die durch gesetzliche Bestimmungen oder aufgrund regulatorischer Vorgaben (Compliance) zu schützen sind. - -## Anforderungen - -Ein Großteil von Datenpannen kann bereits durch Einhaltung einfacher Regeln vermieden werden. Die meisten der Sicherheitsmaßnahmen in dieser Kategorie sind deshalb für alle Prüf-Levels zwingend erforderlich. - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Die App verwendet die vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismen, um sensible Daten zu speichern wie personenbezogene Daten, Anmeldedaten oder kryptografische Schlüssel. | x | x | -| **2.2** | MSTG-STORAGE-2 | Es werden keine sensiblen Daten außerhalb des App-Containers oder außerhalb des vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismus abgelegt. | x | x | -| **2.3** | MSTG-STORAGE-3 | Es werden keine sensiblen Daten in die Logfiles der App geschrieben. | x | x | -| **2.4** | MSTG-STORAGE-4 | Es werden keine sensiblen Daten mit Dritten geteilt - es sei denn dies wurde in der App-Architektur definiert und ist zur Erfüllung des Zwecks der App erforderlich. | x | x | -| **2.5** | MSTG-STORAGE-5 | Der Tastatur-Cache ist für alle sensiblen Texteingaben deaktiviert. | x | x | -| **2.6** | MSTG-STORAGE-6 | Es werden keine sensiblen Daten über Interprozesskommunikation zur Verfügung gestellt. | x | x | -| **2.7** | MSTG-STORAGE-7 | Es werden keine sensiblen Daten wie Passwörter oder Pins über die Benutzeroberfläche exponiert. | x | x | -| **2.8** | MSTG-STORAGE-8 | Es ist sichergestellt, dass betriebssystemgesteuerte Backups keine sensiblen App-Daten enthalten. | | x | -| **2.9** | MSTG-STORAGE-9 | Die App entfernt sensible Daten aus der aktuellen Ansicht, wenn der Hintergrundmodus aktiviert wird. | | x | -| **2.10** | MSTG-STORAGE-10 | Die App hält sensible Daten nur solange wie nötig im Speicher und betroffene Speicherbereiche werden nach Nutzung explizit gelöscht. | | x | -| **2.11** | MSTG-STORAGE-11 | Die App erzwingt ein Minimum an Geräteschutz-Richtlinien wie das Definieren eines Gerätepassworts. | | x | -| **2.12** | MSTG-STORAGE-12 | Die App klärt den Nutzer über die Art und Weise der verarbeiteten personenbezogenen Daten auf und gibt dem Nutzer Security-Best-Practice-Empfehlungen zum Umgang mit der App. | x | x | -| **2.13** | MSTG-STORAGE-13 | Sensible Daten sollten nicht lokal auf dem mobilen Gerät gespeichert werden. Daten sollten stattdessen direkt vom API-Endpunkt abgerufen und nur im Arbeitsspeicher vorgehalten werden. | | x | -| **2.14** | MSTG-STORAGE-14 | Falls doch sensible Daten lokal vorgehalten werden müssen, sollten diese mit einem Schlüssel verschlüsselt werden der im vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismus abgelegt ist. Der Zugriff auf den Schlüssel sollte Authentifizierung erfordern. | | x | -| **2.15** | MSTG-STORAGE-15 | Der lokale Speicher von der App sollte gelöscht werden, nach Erreichen einer exzessiven Anzahl von fehlgeschlagenen Login-Versuchen. | | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-de/0x08-V3-Cryptography_Verification_Requirements.md b/Document-de/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 200472250..000000000 --- a/Document-de/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V3: Anforderungen an Kryptografie - -## Zielsetzung - -Kryptografie ist ein wesentlicher Eckpfeiler zum Schutz von Daten, die auf mobilen Geräten gespeichert werden. Es ist aber auch eine Kategorie, bei der vieles falsch gemacht werden kann, besonders wenn man keine Standard-Konventionen einhält. Die Kategorie soll sicherstellen, dass eine überprüfte App Kryptografie-Best-Practices nach dem Stand der Technik nutzt: - -- Nutzung bewährter Krypto-Bibliotheken, -- Richtige Auswahl und Konfiguration kryptografischer Primitive, -- Nutzung eines geeigneten Zufallszahlengenerators, wenn kryptografisch sichere Zufallszahlen erforderlich sind. - -## Anforderungen - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | Verschlüsselung in der App basiert nicht nur auf symmetrischer Kryptografie mit hart-codierten Schlüsseln. | x | x | -| **3.2** | MSTG-CRYPTO-2 | Die App nutzt bewährte Implementierungen zur Umsetzung kryptografischer Primitive. | x | x | -| **3.3** | MSTG-CRYPTO-3 | Die App nutzt kryptografische Primitive passend zum spezifischen Anwendungsfall, konfiguriert nach Best-Practice Vorgaben dem Stand der Technik entsprechend. | x | x | -| **3.4** | MSTG-CRYPTO-4 | Die App nutzt keine kryptografischen Protokolle oder Algorithmen die allgemein als veraltet und unsicher gelten. | x | x | -| **3.5** | MSTG-CRYPTO-5 | Die App verwendet einen kryptografischen Schlüssel für genau einen Zweck und nicht für mehrere Zwecke. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Alle Zufallswerte werden über einen ausreichend sicheren kryptografischen Zufallszahlengenerator erzeugt. | x | x | - - - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-de/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-de/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index db1c2124f..000000000 --- a/Document-de/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Anforderungen an Authentifizierung und Session Management - -## Zielsetzung - -Ein integraler Teil der Architektur einer mobilen App ist der Login eines Nutzers an einem entfernten Service. Obwohl sich ein Großteil der Logik an dem Endpunkt abspielt, definiert der MASVS eine Reihe von Basisanforderungen an Nutzerkonten und Session-Management. - -## Anforderungen - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Falls die App Nutzern Zugriff auf entfernte Service APIs bietet, wird am API-Endpunkt eine Authentifizierung z.B. mit Nutzername/Passwort durchgeführt. | x | x | -| **4.2** | MSTG-AUTH-2 | Kommt Session-Management am API-Endpunkt zum Einsatz, so werden zufällig generierte Session-IDs erzeugt, um Client-Anfragen zu authentifizieren und keine Nutzer-Anmeldedaten versandt. | x | x | -| **4.3** | MSTG-AUTH-3 | Kommt statuslose Token-basierte Authentifizierung zum Einsatz, so werden die Token am Server mit einem sicheren Algorithmus signiert. | x | x | -| **4.4** | MSTG-AUTH-4 | Der API-Endpunkt beendet die existierende Nutzersitzung, sobald sich der Nutzer abmeldet. | x | x | -| **4.5** | MSTG-AUTH-5 | Es existiert eine Passwort-Richtlinie, die am entfernten API-Endpunkt erzwungen wird. | x | x | -| **4.6** | MSTG-AUTH-6 | Der entfernte API-Endpunkt implementiert einen Mechanismus, um sich gegen eine exzessive Anzahl von Login-Versuchen zu schützen. | x | x | -| **4.7** | MSTG-AUTH-7 | Nach einer definierten Inaktivitätsdauer werden Nutzersitzungen am entfernten API-Endpunkt beendet und Zugriffs-Tokens werden nach Ablauf der Gültigkeitsdauer abgelehnt. | x | x | -| **4.8** | MSTG-AUTH-8 | Biometrische Authentifizierung basiert auf dem Betriebssystem-basierten Entsperren des Keystores (Android)/der Keychain (iOS) und nicht auf einer z.B. event-basierten API die einfach "true" oder "false" zurück liefert. | | x | -| **4.9** | MSTG-AUTH-9 | Es gibt einen 2. Authentifizierungsfaktor und er wird am entfernten API-Endpunkt konsistent erzwungen. | | x | -| **4.10** | MSTG-AUTH-10 | Sensible Transaktionen erfordern eine zusätzliche Authentifizierung (durch einen weiteren Authentifizierungsfaktor). | | x | -| **4.11** | MSTG-AUTH-11 | Die App informiert den Nutzer über alle Anmelde-Vorgänge am Nutzerkonto. Nutzer können eine Liste aller mit dem Konto verbundenen Geräte sowie kontextbezogene Informationen (IP Adresse, Lokation usw.) sehen und ausgewählte Geräte blockieren. | | x | -| **4.12** | MSTG-AUTH-12 | Authentifizierung wird am API-Endpunkt definiert und überprüft. | | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-de/0x10-V5-Network_communication_requirements.md b/Document-de/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index eaac83401..000000000 --- a/Document-de/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Anforderungen an Netzwerkkommunikation - -## Zielsetzung - -Der Zweck dieser Kategorie ist es die Vertraulichkeit und Integrität übertragener Daten zwischen mobiler App und entferntem Server zu gewährleisten. Dazu muss eine mobile App einen sicheren, verschlüsselten Kanal zur Netzwerkkommunikation unter Nutzung des TLS-Protokolls mit adäquaten TLS-Einstellungen aufbauen. Level 2 benennt zusätzliche Defense-in-Depth Maßnahmen wie SSL-Pinning. - -## Anforderungen - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Daten werden zur Netzwerkkommunikation innerhalb der App durchgängig mit TLS verschlüsselt. | x | x | -| **5.2** | MSTG-NETWORK-2 | Die TLS-Einstellungen entsprechen aktuellen Best Practices, oder erfüllen die Best Practices so gut wie möglich, falls das mobile Betriebssystem die Empfehlung nicht unterstützt. | x | x | -| **5.3** | MSTG-NETWORK-3 | Die App überprüft das X.509-Zertifikat des Servers beim TLS-Handshake. Die App akzeptiert nur Zertifikate die von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. | x | x | -| **5.4** | MSTG-NETWORK-4 | Die App nutzt entweder ihren eigenen Zertifikatspeicher oder nutzt Public Key-/ Zertifikats-Pinning und akzeptiert deshalb keine Verbindungen zu Endpunkten die andere Zertifikate/Schlüssel präsentieren - selbst wenn die Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle signiert sind. | | x | -| **5.5** | MSTG-NETWORK-5 | Die App nutzt keine unsicheren Kommunikationskanäle wie E-Mail oder SMS für kritische Operationen wie Konten-Registrierung oder Konten-Reaktivierung. | | x | -| **5.6** | MSTG-NETWORK-6 | Die App nutzt aktuelle Bibliotheken zum Aufbau von sicheren Kommunikationsverbindungen. | | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-de/0x11-V6-Interaction_with_the_environment.md b/Document-de/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index d863de422..000000000 --- a/Document-de/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Anforderungen zur Plattform-Interaktion - -## Zielsetzung - -Die Anforderungen aus dieser Kategorie sollen sicherstellen, dass Plattform-Komponenten und Standard-Komponenten von der App auf sichere Weise genutzt werden. Zusätzlich decken die Anforderungen auch die Kommunikation (IPC) zwischen Apps ab. - -## Anforderungen - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | Die App fordert vom Nutzer nur die unbedingt erforderlichen App-Berechtigungen. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Alle Eingaben von externen Quellen und dem Nutzer werden validiert und falls erforderlich bereinigt. Dazu gehören Daten aus der GUI, IPC Mechanismen wie Intents oder spezifische URL-Schemas und Netzwerk-Daten. | x | x | -| **6.3** | MSTG-PLATFORM-3 | Die App bietet keine sensible Funktionalität über App-eigene URL-Schemas an - wenn doch, ist der Mechanismus angemessen geschützt. | x | x | -| **6.4** | MSTG-PLATFORM-4 | Die App bietet keine sensible Funktionalität über Interprozesskommunikation (IPC) an - wenn doch, ist der Mechanismus angemessen geschützt. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript ist in WebViews deaktiviert, wenn es nicht unbedingt erforderlich ist. | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebViews sind so konfiguriert, dass nur die minimal nötigen Protokoll-Handler erlaubt sind (Idealerweise nur HTTPS). Potenziell gefährliche Handler wie file, tel und app-id sind deaktiviert. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Wenn eine WebView über Javascript Zugriff auf native Methoden einer App bekommt, ist sichergestellt, dass die WebView nur vorgegebenes Javascript aus der App rendert und kein Javascript aus externen Quellen. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Objektserialisierung wird, falls vorhanden, über eine sichere Serialisierungs-API implementiert. | x | x | -| **6.9** | MSTG-PLATFORM-9 | Die App verwendet Mechanismen, um sich vor Screen Overlay Angriffen zu schützen (nur Android). | | x | -| **6.10** | MSTG-PLATFORM-10 | Cache, Speicher und geladene Ressourcen (JavaScript usw.) eines WebViews sollten gelöscht werden bevor der WebView geschlossen wird. | | x | -| **6.11** | MSTG-PLATFORM-11 | Die App sollte verhindern das 3rd Party Tastaturen verwendet werden, wenn sensible Daten eingegeben werden (nur iOS). | | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-de/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-de/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index e50818aa2..000000000 --- a/Document-de/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Anforderungen zu Code Qualität und Build-Einstellungen - -## Zielsetzung - -Das Ziel dieser Kategorie ist, sicherzustellen, dass bei der App-Entwicklung Basis-Security-Praktiken eingehalten werden und die enthaltenen Sicherheits-Funktionen des Compilers aktiviert sind. - -## Anforderungen - -| # | MSTG-ID | Beschreibung | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | Die App ist signiert und mit einem gültigen Zertifikat provisioniert dessen privater Schlüssel angemessen geschützt ist. | x | x | -| **7.2** | MSTG-CODE-2 | Die App wurde im Release-Modus gebaut und mit passenden Release-Einstellungen (kein Debugging). | x | x | -| **7.3** | MSTG-CODE-3 | Debugging Symbole wurden von nativen Binärdateien entfernt. | x | x | -| **7.4** | MSTG-CODE-4 | Debugging Code und "Entwicklerüberbleibsel" (z.B. Test Code, backdoors oder versteckte Einstellungen) wurden entfernt und die App-Logdateien enthalten keine ausführlichen Fehler oder Debug-Meldungen. | x | x | -| **7.5** | MSTG-CODE-5 | Bibliotheken und Frameworks von Drittanbietern, die die App nutzt, wurden auf Schwachstellen geprüft. | x | x | -| **7.6** | MSTG-CODE-6 | Die App führt eine sichere Fehlerbehandlung durch, indem sie Exceptions abfängt und kontrolliert behandelt. | x | x | -| **7.7** | MSTG-CODE-7 | Treten in Sicherheitsfunktionen Fehler auf, lehnt die App-Fehlerbehandlung die Zugriffe standardmäßig ab. | x | x | -| **7.8** | MSTG-CODE-8 | Das Speichermanagement (Allokation und Freigabe von Speicher) erfolgt in unmanaged code auf sichere Weise. | x | x | -| **7.9** | MSTG-CODE-9 | Angebotene Sicherheitsfunktionen der Entwicklungsumgebung wie Byte-Code Minimierung, Stack-Protection, PIE-Support und automatisches Reference-Counting sind aktiviert. | x | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-de/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-de/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 842614354..000000000 --- a/Document-de/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V8: Anforderungen an Manipulationssicherheit/Resilienz - -## Zielsetzung - -Diese Kategorie behandelt Defense-in-Depth-Maßnahmen empfohlen für Apps, die Zugriff auf sensible Daten oder sensible Funktionalitäten beinhalten. Sind diese Maßnahmen nicht umgesetzt, führt dies nicht unmittelbar zu einer Schwachstelle - jedoch erhöhen die Maßnahmen die Robustheit der App gegen Client-seitige Angriffe und Reverse Engineering. - -Die Schutzmechanismen in diesem Abschnitt sollten nach Bedarf angewendet werden. Anhand einer Risikoprüfung sollten Risiken wie unerlaubte Manipulation der App oder Reverse Engineering des Codes bewertet werden. Es wird empfohlen das OWASP Dokument "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" (siehe Referenzen) zu nutzen um eine Liste mit Geschäftsrisiken und zugeordneten technischen Bedrohungen zu identifizieren. - -**Achtung: Diese Software-Schutzmaßnahmen sind kein Ersatz für die Umsetzung adäquater Sicherheitsmaßnahmen. Die Maßnahmen aus MASVR-R sind gedacht, um auf Basis App-spezifischer konkreter Bedrohungen zusätzliche Schutzmaßnahmen über die bereits umgesetzten Sicherheitsmaßnahmen aus MASVS hinaus umzusetzen.** - -Folgende Eckpunkte gelten: - -1. Eine Bedrohungsanalyse wurde durchgeführt. Darin werden wesentliche Client-seitige Bedrohungen und Gegenmaßnahmen sowie der erforderliche Schutzbedarf dargestellt. Ein Aspekt zum Schutzbedarf könnte beispielsweise sein den Aufwand zum manuellen Reverse Engineering einer App für Malware-Autoren, die die App instrumentieren wollen, signifikant zu erhöhen. - -2. Die Bedrohungsanalyse muss realistisch und vernünftig erfolgen. Zum Beispiel nützt es nichts, einen kryptografischen Schlüssel in einer White-Box-Implementierung zu "verbergen" wenn doch der Angreifer ohne weiteres an den Code kommt. - -3. Die Effektivität der Schutzmaßnahmen sollte immer von einem Experten mit ausgewiesener Erfahrung im Bereich Anti-Code-Manipulation und Code-Obfuskierung überprüft werden (siehe auch Kapitel "reverse engineering" and "assessing software protections" im Mobile Application Security Testing Guide). - -### Dynamische Analyse und Manipulation verhindern - -| # | MSTG-ID | Beschreibung | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | Die App erkennt und reagiert auf ein gerootetes Gerät oder Geräte mit Jailbreak, indem der Nutzer gewarnt oder die App beendet wird. | x | -| **8.2** | MSTG-RESILIENCE-2 | Die App verhindert Debugging und/oder erkennt und reagiert auf einen Debugger. Alle verfügbaren Debugging-Protokolle müssen abgedeckt werden. | x | -| **8.3** | MSTG-RESILIENCE-3 | Die App erkennt und reagiert auf Manipulationen an ausführbaren Dateien und kritischen Daten innerhalb der App-eigenen Sandbox. | x | -| **8.4** | MSTG-RESILIENCE-4 | Die App erkennt und reagiert auf typische und allgemein bekannte Reverse Engineering Tools und Frameworks auf dem Gerät.| x | -| **8.5** | MSTG-RESILIENCE-5 | Die App erkennt und reagiert darauf, wenn sie in einem Emulator ausgeführt wird. | x | -| **8.6** | MSTG-RESILIENCE-6 | Die App erkennt und reagiert auf Manipulation von Code und Daten im eigenen Arbeitsspeicherbereich. | x | -| **8.7** | MSTG-RESILIENCE-7 | Die App realisiert mehrere Mechanismen in jeder Kategorie (8.1 bis 8.6). Die Resilienz steigt mit der Anzahl, Vielfalt und Originalität der genutzten Mechanismen. | x | -| **8.8** | MSTG-RESILIENCE-8 | Die Erkennungsmechanismen der App lösen verschiedene Arten von Reaktionen aus z.B. verzögerte, versteckte oder heimliche Reaktionen. | x | -| **8.9** | MSTG-RESILIENCE-9 | Programmatische Abwehrmaßnahmen werden durch Obfuskierung geschützt was wiederum De-Obfuskierung mittels dynamischer Analyse verhindert. | x | - -### Gerätebindung - -| # | MSTG-ID | Beschreibung | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | Die App implementiert einen Mechanismus zur Gerätebindung, bei dem der Geräte-Fingerabdruck aus mehreren einzigartigen Geräteeigenschaften ermittelt wird. | x | - -### Nachvollziehbarkeit verhindern - -| # | MSTG-ID | Beschreibung | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Alle ausführbaren Dateien und Bibliotheken der App sind entweder auf Dateiebene verschlüsselt und/oder wichtige Code- und Datensegmente in ausführbaren Dateien sind verschlüsselt oder durch Packing obfuskiert. Triviale statische Analyse offenbart keinen wichtigen Code oder Daten. | x | -| **8.12** | MSTG-RESILIENCE-12 | Wenn das Ziel der Obfuskierung der Schutz sensibler Logik wie Algorithmen oder Berechnungen ist, so wird ein angemessener Obfuskierungsmechanismus, dem Stand der Technik entsprechend, genutzt der resilient gegen manuelle und automatisierte De-Obfuskierungsangriffe ist. Die Wirksamkeit der Obfuskierungsmethode muss durch manuelle Tests überprüft werden. Es ist zu beachten, dass hardware-basierte Isolations-Mechanismen softwarebasierter Obfuskierung vorzuziehen sind. | x | - -### Abhören erschweren - -| # | MSTG-ID | Beschreibung | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Neben einer gehärteten Kommunikation zwischen Client und API-Endpunkt, sollte auch der übertragene Payload verschlüsselt werden, um das Abhören von Daten zu erschweren. | x | - -## Referenzen - -Der OWASP Mobile Application Security Testing Guide bietet detaillierte Anleitungen, um die Anforderungen aus dieser Kategorie zu überprüfen. - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -Weitere Informationen unter: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-de/0x90-Appendix-A_Glossary.md b/Document-de/0x90-Appendix-A_Glossary.md deleted file mode 100644 index a27fc10b7..000000000 --- a/Document-de/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Appendix A: Glossar - -- **Address Space Layout Randomization (ASLR)** – Eine Technik um Angriffe auf Arbeitsspeicherbereiche zu erschweren. -- **Akzeptanztest (UAT)** – Eine Testumgebung die sich ähnlich verhält wie die Produktivumgebung, in der Tests vor dem go-live ausgeführt werden. -- **Applikationssicherheit** – Applikationssicherheit ist fokussiert auf Sicherheitsaspekte und Angriffe auf Anwendungsebene d.h. Applikationskomponenten und -funktionen korrespondierend zur Anwendungsschicht im Open Systems Interconnection Reference Model (OSI Modell). Der Fokus liegt nicht auf Betriebssystem- oder Netzwerkaspekten. -- **Authentifizierung** – Die Überprüfung der angegebenen Identität eines Nutzers. -- **Automatisierte Prüfungen** – Die Nutzung automatisierter Werkzeuge (dynamische/statische Analyse oder beides) die Schwachstellen anhand von Signaturen identifizieren. -- **Bedrohungsanalyse** – Eine Methodik die dazu dient Sicherheitsschwachstellen im Design einer Anwendung zu identifizieren und Gegenmaßnahmen zu entwickeln, um die Sicherheitsarchitektur zu verbessern. Dabei werden relevante Gruppen von Angreifern, Sicherheitszonen, Sicherheitsmechanismen sowie technische und fachliche Wertgegenstände identifiziert und einbezogen. -- **Black box Tests** – Ist eine Testmethode bei der die Funktionalität einer Komponente oder Anwendung "von außen" ohne Wissen über interne Strukturen und Mechanismen getestet wird. -- **Cross-Site Scripting (XSS)** – Eine Sicherheitsschwachstelle die typischerweise in Web-Applikationen vorkommt die das Einschleusen von Client-seitigem Script-Code in den Seiteninhalt zulassen. -- **CWE** – Common Weaknesses Enumeration - CWE ist eine Community-basierte Sammlung von allgemeinen Software Security Schwächen. Sie dient als gemeinsame Sprache, als Messlatte für Software-Sicherheits-Tools und als Grundlage für die Identifizierung von Schwachstellen sowie für Maßnahmen zur Schadensbegrenzung und -vermeidung. -- **DAST** – Dynamische Applikations-Security Tests (DAST) dienen der Erkennung von Sicherheitsschwachstellen einer Applikation zur Laufzeit. -- **Dynamische Prüfungen** – Die Nutzung automatisierter Werkzeuge um zur Laufzeit einer Applikation Sicherheitsschwachstellen auf Basis von Signaturprüfungen zu finden. -- **Eingabe-Validierung** – Überführung in eine standardisierte Form (Kanonisierung) und Prüfung von Eingabedaten denen nicht vertraut wird z.B. Nutzereingaben oder Request-Parameter. -- **Globally Unique Identifier(GUID)** – Eine einzigartige Referenz-Nummer die als Identifikator in einer Software genutzt werden kann. -- **Hartcodierte Schlüssel** – Kryptografische Schlüssel die auf unsichere Weise direkt im Quellcode oder der Anwendungskonfiguration hinterlegt sind. -- **Hyper Text Transfer Protocol (HTTP)** – Ein Kommunikations-Protokoll für verteilte Informationssysteme auf Basis von Hypermedia und damit die Basis der Datenkommunikation im weltweiten Internet. -- **IPC** – Interprozesskommunikation - Mit IPC kommunizieren Prozesse über Betriebssystem-Mechanismen mit dem Kernel und untereinander um Aktivitäten zu koordinieren oder Daten auszutauschen. -- **Java Bytecode** – Java Bytecode ist der Befehlssatz der Java Virtual Machine (JVM). Ein Bytecode besteht aus einem oder in einigen Fällen zwei Bytes die einen Befehl (OP-Code) repräsentieren sowie optional weitere Bytes die als Parameter für den OP-Code dienen. -- **Komponente** – Eine Zusammenfassung einzelner Code-Elemente zu einer eigenständigen Einheit mit Zugriffen auf Speicher- und Netzwerkschnittstellen um mit anderen Komponenten zu kommunizieren. -- **Kryptographisches Modul** – Hardware, Software, und/oder Firmware, die kryptografische Algorithmen und/oder erzeugte kryptografische Schlüssel nutzt. -- **Malicious Code** – Bösartiger Code der während der Entwicklung, verborgen vor dem Applikationsverantwortlichen, in die Applikation eingebracht wird. Der eingeschleuste Code umgeht dabei gezielt Sicherheitsrichtlinien und ist dadurch nicht vergleichbar mit Malware wie einem Virus oder einem Wurm! -- **Malware** – Ausführbarer Code der zur Laufzeit ohne Wissen des Nutzers oder Administrators in die Zielanwendung injiziert wird. -- **Open Web Application Security Project (OWASP)** – Open Web Application Security Project (OWASP) ist eine weltweite freie, offene und herstellerunabhängige Community mit Fokus auf Verbesserung der Applikationssicherheit. Unsere Mission ist es Applikationssicherheit sichtbar zu machen, sodass Einzelpersonen und Organisationen klare und bewusste Entscheidungen über Sicherheitsrisiken treffen können. Mehr unter: -- **Personenbezogene Daten** – Personenbezogene Daten sind Daten die genutzt werden können um eine Person direkt oder indirekt zu identifizieren, kontaktieren oder lokalisieren bzw. eine Person in einem Zusammenhang zu identifizieren. -- **PIE** – Position-independent executable (PIE) - Positionsunabhängiger Code ist Maschinencode der an einer beliebigen Stelle im primären Speicher ausgeführt werden kann. (unabhängig von der absoluten Speicheradresse) -- **PKI** – Public Key Infrastruktur - PKI basiert darauf, dass öffentliche Schlüssel an eine Identität gebunden werden. Die Bindung erfolgt durch einen Registrierungsprozess und das Ausstellen eines Zertifikats durch eine Zertifizierungsstelle, in Englisch Certificate Authority (CA). -- **Prüfer** – Eine Person oder ein Team, dass eine Anwendung gegen den OWASP MASVS prüft. -- **Prüfung zur Applikationssicherheit** – Die technische Prüfung einer Applikation gegen den OWASP MASVS. -- **Prüfbericht zur Applikationssicherheit** – Ein Prüfbericht, für eine Applikation, der die Analyseschritte eines Prüfers sowie die Gesamtergebnisse dokumentiert. -- **SAST** – Statische Applikations-Security-Tests (SAST) sind eine Reihe von Techniken, die dazu genutzt werden können, potenzielle Sicherheitsschwachstellen in Quellcode, Bytecode und Binärdateien zu identifizieren. SAST Lösungen analysieren eine Applikation typischerweise zur Entwicklungs- oder Buildzeit jedoch nicht zur Laufzeit. -- **SDLC** – Software development lifecycle. -- **Sicherheitsarchitektur** – Eine Abstraktion des Applikations-Designs einer Anwendung bei der dokumentiert wird an welchen Stellen und in welchem Maße Sicherheitsmechanismen genutzt werden. Darüber hinaus wird beschrieben an welchen Stellen im System sensible Nutzer- und Anwendungsdaten verarbeitet werden. -- **Sicherheitsarchitekturanalyse** – Die technische Prüfung der Sicherheitsarchitektur einer Applikation. -- **Sicherheitskonfiguration** – Die Laufzeitkonfiguration einer Anwendung; enthält Optionen, die die Sicherheitsfunktionen beeinflussen. -- **Sicherheitsmechanismus** – Eine Sicherheitsfunktion oder Komponente die Sicherheitsprüfungen durchführt z.B. eine Autorisierungsprüfung oder das Erzeugen eines Eintrags im Audit-Log beim Login eines Administrators. -- **SQL Injection (SQLi)** – Eine Technik um Code in datengetriebene Anwendungen einzuschleusen. Dabei werden schadhafte SQL-Anweisungen in Nutzereingaben eingeschleust und in der Datenbank zur Ausführung gebracht. -- **SSO Authentifizierung** – Single Sign On(SSO) bedeutet, ein Nutzer muss sich an einer Applikation einloggen und ist dann automatisch an weiteren Anwendungen angemeldet. Damit können sich Nutzer u.U. über mehrere unterschiedliche Plattformen, Technologien und Domains anmelden. Zum Beispiel ist man bei Google nach der Nutzeranmeldung automatisch auch für Youtube, Google-Docs und Google-Mail angemeldet. -- **Transport Layer Security (TLS)** – Kryptografisches Protokoll um die Vertraulichkeit, Integrität und Authentizität von Daten während der Übertragung im Internet abzusichern. -- **URI/URL/URL Fragmente** – Eine URI (Uniform Resource Identifier) ist eine Zeichenfolge um einen Namen oder eine Webressource zu identifizieren. Ein URL (Uniform Resource Locator) wird oft als Referenz auf eine Webressource genutzt. -- **Whitelist** – Eine Liste erlaubter Operationen zum Beispiel eine Liste erlaubter Buchstaben die zur Eingabe-Validierung genutzt werden soll. -- **X.509 Zertifikat** – Ein X.509 Zertifikat ist ein digitales Zertifikat das eine international standardisierten PKI-Standard nutzt, um nachzuweisen, dass ein öffentlicher Schlüssel zu einem Nutzer, einem Computer oder einer Serviceidentität, aufgeführt in dem Zertifikat, gehört. diff --git a/Document-de/0x91-Appendix-B_References.md b/Document-de/0x91-Appendix-B_References.md deleted file mode 100644 index 69a95e81c..000000000 --- a/Document-de/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Appendix B: Referenzen - -Die folgenden OWASP Projekte könnten für Anwender dieses Standards nützlich sein: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -Die folgenden Webseiten könnten ebenfalls für Anwender dieses Standards nützlich sein: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-de/CHANGELOG.md b/Document-de/CHANGELOG.md deleted file mode 100644 index 52e261804..000000000 --- a/Document-de/CHANGELOG.md +++ /dev/null @@ -1,98 +0,0 @@ -# Versionshistorie - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 März 2020 - Internationale Veröffentlichung - -Die folgenden Änderungen sind Teil von Version 1.2: - -- Übersetzung des MASVS in verinfachtes Chinesisch verfügbar. -- Änderung des Titles auf dem Cover des MASVS. -- Mobile Top 10 und CWE Referenzen wurden aus dem MSTG entfernt und zu existierenden Referenzen im MASVS hinzugefügt. - -## V1.2-RC - 5 Oktober 2019 - Pre-Release - -Die folgenden Änderungen sind Teil von Version 1.2-RC: - -- "Flagship Status" von OWASP erhalten. -- Anforderung MSTG-Storage-1 verändert. -- Anforderung MSTG-STORAGE-13, MSTG-STORAGE-14 und MSTG-STORAGE-15 wurden hinzugefügt mit Fokus auf Datenschutz. -- Anforderung MSTG-CODE-4 wurde aktualisiert um mehr Fälle als nur Debugging abzudecken. -- Anforderung MSTG-AUTH-11 wurde aktualisiert um "kontextbezogene Informationen". -- Anforderung MSTG-PLATFORM-10 wurde hinzugefügt für einen weiteren Fall um WebViews sicher zu verwenden. -- Anforderung MSTG-AUTH-12 wurde hinzugefügt um Entwickler daran zu erinnern Autorisierung zu implementieren, vor allem im Fall von multi-user Apps. -- Beschreibung hinzugefügt, wie der MASVS in einem Risk Assessment verwendet werden sollte. -- Beschreibung hinzugefügt für Bezahl-Inhalte. -- Anforderung MSTG-ARCH-11 wurde hinzugefügt um Responsible Disclosure Policies zu implementieren. -- Anforderung MSTG-ARCH-12 wurde hinzugefügt um Datenschutzgesetze zu befolgen. -- Anforderung MSTG-PLATFORM-11 wurde hinzugefügt um 3rd Party Tastaturen zu verbieten. -- Anforderung MSTG-RESILIENCE-13 wurde hinzugefügt um das Abhören von Apps zu erschweren. -- Die folgenden Sprachen in denen der MASVS verfügbar ist wurden aktualisiert: Chinesisch (ZHTW), Englisch, Deutsch, Französisch, Russisch, Spanisch und Japanisch - -## V1.1.4 - 4 Juli 2019 - Summit edition - -Die folgenden Änderungen sind Teil von Version 1.1.4: - -- Markdown Fehler wurden alle behoben. -- Französische und Spanische Übersetzung wurden aktualisiert. -- Versionshistorie wurde übersetzt in Chinesisch (ZHTW) und Japanisch. -- Automatische überprüfung der Markdown Syntax und Erreichbarkeit von URLs. -- Jede Anforderung hat eine ID erhalten um die Suche nach Anforderungen und Testfällen zu vereinfachen. Die IDs werden in der kommenden Version des MSTG eingearbeitet. -- Größe des Github Repositories wurde reduziert und das Verzeichnis Generated wurde zum .gitignore hinzugefügt. -- "Code of Conduct" und "Contributing Guidelines" wurden hinzugefügt. -- Ein Pull-Request Template wurde hinzugefügt. -- Die Synchronisation zwischen dem MASVS Repository das für Gitbook genutzt wird und Gitbook wurde aktualisiert. -- Die Skripte zum Erzeugen von XML/JSON/CSV von allen Sprachen wurden aktualisiert. -- Das Vorwort wurde in Chinesisch (ZHTW) übersetzt. - -## V1.1.3 - 9 Januar 2019 - Kleine Fehlerbehebungen - -Die folgenden Änderungen sind Teil von Version 1.1.3: - -- Fix für Spanische Übersetzung von Anforderung 7.1. -- Neue Tabelle für Übersetzer in Danksagungen. -- Kleine fixes in der Japanischen Version. - -## V1.1.2 - 3 Januar 2019 - Sponsoren und Internationalisierung - -Die folgenden Änderungen sind Teil von Version 1.1.2: - -- Danksagung für alle Käufer, die das Buch von [Leanpub](https://leanpub.com/mobile-security-testing-guide) gekauft haben. -- Fehlender link für Authentifizierung und Session Management hinzugefügt und kaputten link in V4 aktualisiert. -- Anforderung 4.7 und 4.8 ausgetauscht in englischer Version. -- Erste internationale Version! - - Fehler behoben in spanischer Version. Übersetzung ist auf gleichem Stand mit englischer Version (1.1.2). - - Fehler behoben in russischer Version. Übersetzung ist auf gleichem Stand mit englischer Version (1.1.2). - - Erste Version auf Chinesisch (ZHTW), Französisch, Deutsch und Japanisch! -- Dokument vereinfacht um Übersetzung zu erleichtern. -- Anleitung für automatische Erstellung von neuen MASVS Versionen hinzugefügt. - -## V1.1.0 - 14 Juli 2018 - -Die folgenden Änderungen sind Teil von Version 1.1: - -- Anforderung 2.6 "The clipboard is deactivated on text fields that may contain sensitive data." wurde entfernt. -- Anforderung 2.2 "Es werden keine sensiblen Daten außerhalb des App-Containers oder außerhalb des vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismus abgelegt." wurde hinzugefügt. -- Anforderung 2.1 wurde umformuliert zu "Die App speichert sensible Daten wie personenbezogene Daten, Anmeldedaten oder kryptographische Schlüssel unter Nutzung der vom jeweiligen Betriebssystem angebotenen sicheren Speichermechanismen.". - -## V1.0 - 12 Januar 2018 - -Die folgenden Änderungen sind Teil von Version 1.0: - -- Anforderung 8.9 wurde entfernt, da redundant zu 8.12 -- Anforderung 4.6 wurde allgemeiner formuliert -- Kleine fixes (typos etc.) diff --git a/Document-de/GLOSSARY.md b/Document-de/GLOSSARY.md deleted file mode 100644 index e1ff2915c..000000000 --- a/Document-de/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Appendix A: Glossar - -## Address Space Layout Randomization (ASLR) - -Eine Technik um Angriffe auf Arbeitsspeicherbereiche zu erschweren. - -## Akzeptanztest (UAT) - -Eine Testumgebung die sich ähnlich verhält wie die Produktivumgebung, in der Tests vor dem go-live ausgeführt werden. - -## Applikationssicherheit - -Applikationssicherheit ist fokussiert auf Sicherheitsaspekte und Angriffe auf Anwendungsebene d.h. Applikationskomponenten und -funktionen korrespondierend zur Anwendungsschicht im Open Systems Interconnection Reference Model (OSI Modell). Der Fokus liegt nicht auf Betriebssystem- oder Netzwerkaspekten. - -## Authentifizierung - -Die Überprüfung der angegebenen Identität eines Nutzers. - -## Automatisierte Prüfungen - -Die Nutzung automatisierter Werkzeuge (dynamische/statische Analyse oder beides) die Schwachstellen anhand von Signaturen identifizieren. - -## Bedrohungsanalyse - -Eine Methodik die dazu dient Sicherheitsschwachstellen im Design einer Anwendung zu identifizieren und Gegenmaßnahmen zu entwickeln, um die Sicherheitsarchitektur zu verbessern. Dabei werden relevante Gruppen von Angreifern, Sicherheitszonen, Sicherheitsmechanismen sowie technische und fachliche Wertgegenstände identifiziert und einbezogen. - -## Black box Tests - -Ist eine Testmethode bei der die Funktionalität einer Komponente oder Anwendung "von außen" ohne Wissen über interne Strukturen und Mechanismen getestet wird. - -## Cross-Site Scripting (XSS) - -Eine Sicherheitsschwachstelle die typischerweise in Web-Applikationen vorkommt, die das Einschleusen von Client-seitigem Script-Code in den Seiteninhalt zulassen. - -## CWE - -Common Weaknesses Enumeration - CWE ist eine Community-basierte Sammlung von allgemeinen Software Security Schwächen. Sie dient als gemeinsame Sprache, als Messlatte für Software-Sicherheits-Tools und als Grundlage für die Identifizierung von Schwachstellen sowie für Maßnahmen zur Schadensbegrenzung und -vermeidung. - -## DAST - -Dynamische Applikations-Security Tests (DAST) dienen der Erkennung von Sicherheitsschwachstellen einer Applikation zur Laufzeit. - -## Dynamische Prüfungen - -Die Nutzung automatisierter Werkzeuge um zur Laufzeit einer Applikation Sicherheitsschwachstellen auf Basis von Signaturprüfungen zu finden. - -## Eingabe-Validierung - -Überführung in eine standardisierte Form (Kanonisierung) und Prüfung von Eingabedaten denen nicht vertraut wird z.B. Nutzereingaben oder Request-Parameter. - -## Globally Unique Identifier(GUID) - -Eine einzigartige Referenz-Nummer die als Identifikator in einer Software genutzt werden kann. - -## Hartcodierte Schlüssel - -Kryptografische Schlüssel die auf unsichere Weise direkt im Quellcode oder der Anwendungskonfiguration hinterlegt sind. - -## Hyper Text Transfer Protocol (HTTP) - -Ein Kommunikations-Protokoll für verteilte Informationssysteme auf Basis von Hypermedia und damit die Basis der Datenkommunikation im weltweiten Internet. - -## IPC - -Interprozesskommunikation - Mit IPC kommunizieren Prozesse über Betriebssystem-Mechanismen mit dem Kernel und untereinander um Aktivitäten zu koordinieren oder Daten auszutauschen. - -## Java Bytecode - -Java Bytecode ist der Befehlssatz der Java Virtual Machine (JVM). Ein Bytecode besteht aus einem oder in einigen Fällen zwei Bytes die einen Befehl (OP-Code) repräsentieren sowie optional weitere Bytes die als Parameter für den OP-Code dienen. - -## Komponente - -Eine Zusammenfassung einzelner Code-Elemente zu einer eigenständigen Einheit mit Zugriffen auf Speicher- und Netzwerkschnittstellen um mit anderen Komponenten zu kommunizieren. - -## Kryptographisches Modul - -Hardware, Software, und/oder Firmware, die kryptografische Algorithmen und/oder erzeugte kryptografische Schlüssel nutzt. - -## Malicious Code - -Bösartiger Code der während der Entwicklung, verborgen vor dem Applikationsverantwortlichen, in die Applikation eingebracht wird. Der eingeschleuste Code umgeht dabei gezielt Sicherheitsrichtlinien und ist dadurch nicht vergleichbar mit Malware wie einem Virus oder einem Wurm! - -## Malware - -Ausführbarer Code der zur Laufzeit ohne Wissen des Nutzers oder Administrators in die Zielanwendung injiziert wird. - -## Open Web Application Security Project (OWASP) - -Open Web Application Security Project (OWASP) ist eine weltweite freie, offene und herstellerunabhängige Community mit Fokus auf Verbesserung der Applikationssicherheit. Unsere Mission ist es Applikationssicherheit sichtbar zu machen, sodass Einzelpersonen und Organisationen klare und bewusste Entscheidungen über Sicherheitsrisiken treffen können. Mehr unter: - -## Personenbezogene Daten - -Personenbezogene Daten sind Daten die genutzt werden können um eine Person direkt oder indirekt zu identifizieren, kontaktieren oder lokalisieren bzw. eine Person in einem Zusammenhang zu identifizieren. - -## PIE - -Position-independent executable (PIE) - Positionsunabhängiger Code ist Maschinencode der an einer beliebigen Stelle im primären Speicher ausgeführt werden kann. (unabhängig von der absoluten Speicheradresse) - -## PKI - -Public Key Infrastruktur - PKI basiert darauf, dass öffentliche Schlüssel an eine Identität gebunden werden. Die Bindung erfolgt durch einen Registrierungsprozess und das Ausstellen eines Zertifikats durch eine Zertifizierungsstelle, in Englisch Certificate Authority (CA). - -## Prüfer - -Eine Person oder ein Team, dass eine Anwendung gegen den OWASP MASVS prüft. - -## Prüfung zur Applikationssicherheit - -Die technische Prüfung einer Applikation gegen den OWASP MASVS. - -## Prüfbericht zur Applikationssicherheit - -Ein Prüfbericht, für eine Applikation, der die Analyseschritte eines Prüfers sowie die Gesamtergebnisse dokumentiert. - -## SAST - -Statische Applikations-Security-Tests (SAST) sind eine Reihe von Techniken, die dazu genutzt werden können, potenzielle Sicherheitsschwachstellen in Quellcode, Bytecode und Binärdateien zu identifizieren. SAST Lösungen analysieren eine Applikation typischerweise zur Entwicklungs- oder Buildzeit jedoch nicht zur Laufzeit. - -## SDLC - -Software development lifecycle. - -## Sicherheitsarchitektur - -Eine Abstraktion des Applikations-Designs einer Anwendung bei der dokumentiert wird an welchen Stellen und in welchem Maße Sicherheitsmechanismen genutzt werden. Darüber hinaus wird beschrieben an welchen Stellen im System sensible Nutzer- und Anwendungsdaten verarbeitet werden. - -## Sicherheitsarchitekturanalyse - -Die technische Prüfung der Sicherheitsarchitektur einer Applikation. - -## Sicherheitskonfiguration - -Die Laufzeitkonfiguration einer Anwendung; enthält Optionen, die die Sicherheitsfunktionen beeinflussen. - -## Sicherheitsmechanismus - -Eine Sicherheitsfunktion oder Komponente die Sicherheitsprüfungen durchführt z.B. eine Autorisierungsprüfung oder das Erzeugen eines Eintrags im Audit-Log beim Login eines Administrators. - -## SQL Injection (SQLi) - -Eine Technik um Code in datengetriebene Anwendungen einzuschleusen. Dabei werden schadhafte SQL-Anweisungen in Nutzereingaben eingeschleust und in der Datenbank zur Ausführung gebracht. - -## SSO Authentifizierung - -Single Sign On(SSO) bedeutet, ein Nutzer muss sich an einer Applikation einloggen und ist dann automatisch an weiteren Anwendungen angemeldet. Damit können sich Nutzer u.U. über mehrere unterschiedliche Plattformen, Technologien und Domains anmelden. Zum Beispiel ist man bei Google nach der Nutzeranmeldung automatisch auch für Youtube, Google-Docs und Google-Mail angemeldet. - -## Transport Layer Security (TLS) - -Kryptografisches Protokoll um die Vertraulichkeit, Integrität und Authentizität von Daten während der Übertragung im Internet abzusichern. - -## URI/URL/URL Fragmente - -Eine URI (Uniform Resource Identifier) ist eine Zeichenfolge um einen Namen oder eine Webressource zu identifizieren. Ein URL (Uniform Resource Locator) wird oft als Referenz auf eine Webressource genutzt. - -## Whitelist - -Eine Liste erlaubter Operationen zum Beispiel eine Liste erlaubter Buchstaben die zur Eingabe-Validierung genutzt werden soll. - -## X.509 Zertifikat - -Ein X.509 Zertifikat ist ein digitales Zertifikat das eine international standardisierten PKI-Standard nutzt, um nachzuweisen, dass ein öffentlicher Schlüssel zu einem Nutzer, einem Computer oder einer Serviceidentität, aufgeführt in dem Zertifikat, gehört. diff --git a/Document-de/SUMMARY.md b/Document-de/SUMMARY.md deleted file mode 100644 index 29c2ad721..000000000 --- a/Document-de/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Inhaltsverzeichnis - -- [Changelog](CHANGELOG.md) -- [Vorwort](0x01-Foreword.md) -- [Frontispiece](0x02-Frontispiece.md) -- [Verwendung des MASVS](0x03-Using_the_MASVS.md) -- [Bewertung und Zertifizierung](0x04-Assessment_and_Certification.md) - -## Security Requirements - -- [V1: Anforderungen an Architektur, Design und Bedrohungsanalysen](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Anforderungen an Datenspeicherung und Datenschutz](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Anforderungen an Kryptographie](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Anforderungen an Authentifizierung und Session Management](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Anforderungen an Netzwerkkommunikation](0x10-V5-Network_communication_requirements.md) -- [V6: Anforderungen zur Plattform-Interaktion](0x11-V6-Interaction_with_the_environment.md) -- [V7: Anforderungen zu Code Qualität und Build-Einstellungen](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Anforderungen an Manipulationssicherheit/Resilienz](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendix - -- [Appendix A - Glossary](GLOSSARY.md) -- [Appendix B - References](0x91-Appendix-B_References.md) diff --git a/Document-de/book.json b/Document-de/book.json deleted file mode 100644 index 53b30c4a1..000000000 --- a/Document-de/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "de" -} diff --git a/Document-de/images/CC-license.png b/Document-de/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-de/images/CC-license.png and /dev/null differ diff --git a/Document-de/images/MASVS-levels.png b/Document-de/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-de/images/MASVS-levels.png and /dev/null differ diff --git a/Document-de/images/OWASP_logo.png b/Document-de/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-de/images/OWASP_logo.png and /dev/null differ diff --git a/Document-de/images/license.png b/Document-de/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-de/images/license.png and /dev/null differ diff --git a/Document-de/images/masvs-cover-1.1.xcf b/Document-de/images/masvs-cover-1.1.xcf deleted file mode 100644 index 7e4ddd1e0..000000000 Binary files a/Document-de/images/masvs-cover-1.1.xcf and /dev/null differ diff --git a/Document-de/images/masvs-levels-new.jpg b/Document-de/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-de/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-de/images/masvs-mini-cover.jpg b/Document-de/images/masvs-mini-cover.jpg deleted file mode 100644 index bae43fdf8..000000000 Binary files a/Document-de/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-de/images/masvs-mini-cover.png b/Document-de/images/masvs-mini-cover.png deleted file mode 100644 index 15d07d0c2..000000000 Binary files a/Document-de/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-de/metadata.md b/Document-de/metadata.md deleted file mode 100644 index e2aee6eda..000000000 --- a/Document-de/metadata.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -# This overide the main Document/metadata.md file -lang: 'de' -languagetext: '(German Translation)' - -# toc-title is translated when `lang` is correctly defined -#toc-title: 'Inhaltsverzeichnis' - ---- diff --git a/Document-es/0x01-Foreword.md b/Document-es/0x01-Foreword.md deleted file mode 100644 index 882af27b1..000000000 --- a/Document-es/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Prólogo - -Las revoluciones tecnológicas pueden suceder rápidamente. Hace menos de una década los dispositivos móviles eran aparatos enormes con pequeños teclados - juguetes caros para usuarios empresariales expertos en tecnología. Hoy los dispositivos móviles son una parte esencial de nuestras vidas. Hemos llegado a confiar en ellos para la búsqueda de información, la navegación y la comunicación y están presentes tanto en los negocios como en nuestra vida social. - -Cada nueva tecnología introduce nuevos riesgos de seguridad, y mantenerse al día con estos cambios es uno de los principales retos a los que se enfrenta la industria de la seguridad. El bando defensivo está siempre unos pasos por detrás. Por ejemplo, el modo predeterminado fue para muchos aplicar viejas formas de hacer las cosas: Los dispositivos móviles son como pequeños ordenadores y las aplicaciones móviles forman parte del software, así que seguramente los requerimientos de seguridad son similares, ¿no?. Pero esto no funciona así. Los sistemas operativos para dispositivos móviles son diferentes a los sistemas operativos de escritorio, y las aplicaciones móviles son diferentes a las aplicaciones web. Por ejemplo, el método clásico de escaneo de virus basado en firmas no tiene sentido en los sistemas operativos móviles modernos: no sólo es incompatible con el modelo de distribución de aplicaciones móviles, sino que también es técnicamente imposible debido a las restricciones de aislamiento. Además, algunos tipos de vulnerabilidades, como los desbordamientos de búfer y los problemas XSS, son menos relevantes en el contexto de las aplicaciones móviles que, por ejemplo, en las aplicaciones de escritorio y las aplicaciones web (con excepciones). - -Con el tiempo, la industria ha conseguido un mejor control del panorama de amenazas móviles. Resulta que la seguridad móvil tiene que ver con la protección de los datos: Las aplicaciones almacenan nuestra información personal, imágenes, grabaciones, notas, datos de cuentas bancarias, información empresarial, ubicación y mucho más. Actúan como clientes que nos conectan con los servicios que utilizamos a diario, y como centros de comunicación que procesan todos y cada uno de los mensajes que intercambiamos con otros. Comprometer el dispositivo móvil de una persona, es obtener acceso sin filtros a su vida. Cuando consideramos que los dispositivos móviles se pierden o roban más fácilmente y que el malware para dispositivos móviles está aumentando, la necesidad de protección de datos se hace aún más evidente. - -Por lo tanto, un estándar de seguridad para aplicaciones móviles debe centrarse en la forma en que las aplicaciones móviles gestionan, almacenan y protegen la información sensible. A pesar de que los sistemas operativos móviles modernos como iOS y Android ofrecen buenas APIs para el almacenamiento y la comunicación de datos seguros, éstas deben ser incluidas en las aplicaciones y usadas correctamente para ser efectivas. El almacenamiento de datos, la comunicación entre aplicaciones, el uso apropiado de las API criptográficas y la comunicación segura a través de la red son sólo algunos de los aspectos que requieren una cuidadosa consideración. - -Una cuestión importante que requiere el consenso de la industria es, ¿hasta dónde se debe llegar exactamente para proteger la confidencialidad e integridad de los datos? Por ejemplo, la mayoría de nosotros estaríamos de acuerdo en que una aplicación móvil debería verificar el certificado del servidor en una conexión TLS. Pero, ¿qué ocurre con el _certificate pinning_?, ¿el no implementarlo resultaría en una vulnerabilidad?, ¿debería ser este un requerimiento si una aplicación maneja datos sensibles?, ¿o es contraproducente?, ¿necesitamos cifrar los datos almacenados en bases de datos SQLite, a pesar de que el sistema operativo aísla la aplicación? Lo que es apropiado para una aplicación puede ser poco realista para otra. El MASVS es un intento de estandarizar estos requerimientos utilizando distintos niveles de verificación que se ajustan a los diferentes escenarios de amenaza. - -Además, la aparición del malware y las herramientas de administración remota han conseguido promover una mayor conciencia pública de que los propios sistemas operativos móviles tienen vulnerabilidades explotables, por lo que las estrategias de aislamiento se utilizan cada vez más para proporcionar protección adicional a los datos confidenciales y evitar la manipulación en el lado del cliente. Aquí es donde las cosas se complican. Las características de seguridad por hardware y las soluciones de aislamiento a nivel de sistema operativo, como _Android for Work_ y Samsung Knox, existen, pero no siempre están disponibles en diferentes dispositivos. Es posible implementar medidas de protección basadas en software a modo de parches - pero desafortunadamente, no hay estándares o procesos de prueba para verificar este tipo de protecciones. - -Como resultado, los informes de pruebas de seguridad de aplicaciones móviles están por todas partes: por ejemplo, algunos reportan una falta de ofuscación o detección de _root_ en una aplicación Android como "fallo de seguridad". Por otra parte, las medidas como el cifrado de _strings_, la detección de depuradores o la ofuscación del flujo de control no se consideran obligatorias. Sin embargo, esta forma binaria de ver las cosas no tiene sentido porque la resistencia no es una proposición binaria sino que depende de las amenazas particulares en el dispositivo contra las que se quiere defender. Las protecciones de software no son inútiles, pero en última instancia pueden ser eludidas, por lo que nunca deben utilizarse como sustituto de los controles de seguridad. - -El objetivo general del MASVS es ofrecer tanto una línea base de referencia para la seguridad de las aplicaciones móviles (MASVS-L1) como también la inclusión de medidas de defensa en profundidad (MASVS-L2) y protecciones contra las amenazas del lado del cliente (MASVS-R). El MASVS está pensado para lograr lo siguiente: - -- Proveer requerimientos para arquitectos y desarrolladores de software que buscan desarrollar aplicaciones móviles seguras. -- Ofrecer un estándar para que la industria pueda utilizar en las revisiones de seguridad de aplicaciones móviles. -- Clarificar el rol de los mecanismos de protección de software en la seguridad móvil y proporcionar requerimientos para verificar su efectividad. -- Proporcionar recomendaciones específicas sobre el nivel de seguridad que se recomienda para los diferentes casos de uso. - -Somos conscientes de que es imposible lograr un consenso del 100% en la industria. No obstante, esperamos que el MASVS sea útil para proporcionar orientación en las fases de desarrollo y verificación de aplicaciones móviles. Como estándar de código abierto, el MASVS evolucionará con el tiempo, y acogemos con gusto cualquier contribución o sugerencia. - -Por Bernhard Mueller diff --git a/Document-es/0x02-Frontispiece.md b/Document-es/0x02-Frontispiece.md deleted file mode 100644 index bad9d539e..000000000 --- a/Document-es/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Sobre el Estándar - -![OWASP Logo](images/OWASP_logo.png) - -Bienvenido al Estándar de Verificación de Seguridad de Aplicaciones Móviles (MASVS). El MASVS es un esfuerzo comunitario para establecer un marco de requisitos de seguridad necesarios para diseñar, desarrollar y probar la seguridad de aplicaciones móviles iOS y Android. - -El MASVS es la culminación del esfuerzo de la comunidad y la retroalimentación con la industria. Esperamos que este estándar evolucione con el tiempo y agradecemos todo _feedback_ que la comunidad pueda darnos. - -La mejor manera de ponerse en contacto con nosotros es a través del canal OWASP Mobile Project en Slack: - -Las cuentas se pueden crear en la siguiente URL: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Copyright y Licencia - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Este documento está licenciado bajo la licencia Internacional 4.0 de [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Para cualquier reutilización o distribución, debe dejar claro los términos de la licencia de esta obra. - - - -## Reconocimientos - -| Líderes del proyecto | Autor principal | Colaboradores y revisores -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Idioma | Traductores y revisores | -| --------------- | ------------------------------------------------------------ | -| Alemán | Rocco Gränitz, Sven Schleier (revisor) | -| Chino (Tradicional)| Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| Chino (Simplificada) | Bob Peng, Harold Zang, Jack S | -| Coreano | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| Español | Martin Marsicano, Carlos Holguera | -| Francés | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (revisor) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| Japonés | Koki Takeyama, Riotaro Okada (revisor) | -| Persa | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| Portugués (brasilera) | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Portugués | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Ruso | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Turco | Anıl Baş, Haktan Emik | -| Griego | Panagiotis Yialouris | - -Este documento comenzó como un _fork_ del Estándar de Verificación de Seguridad de Aplicaciones de OWASP escrito por Jim Manico. - -## Patrocinadores - -Aunque tanto el MASVS como la MASTG fueron creados y son mantenidos por la comunidad de forma voluntaria, a veces se requiere de un poco de ayuda externa. Por lo tanto, agradecemos a nuestros patrocinadores por proporcionar los fondos para poder contratar editores técnicos. Ha de notarse que su patrocinio no influye en el contenido del MASVS o la MASTG de ninguna manera. Los paquetes de patrocinio están descritos en la [Wiki del proyecto OWASP](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -Por último, nos gustaría agradecer a todos los que compraron el libro en [Leanpub](https://leanpub.com/mobile-security-testing-guide) y nos patrocinaron de esa manera. diff --git a/Document-es/0x03-Using_the_MASVS.md b/Document-es/0x03-Using_the_MASVS.md deleted file mode 100644 index da446deac..000000000 --- a/Document-es/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,83 +0,0 @@ -# Estándar de Verificación de Seguridad de Aplicaciones Móviles - -El MASVS se puede utilizar para establecer un nivel de confianza en la seguridad de las aplicaciones móviles. Los requisitos fueron desarrollados con los siguientes objetivos en mente: - -- Uso como una métrica - Proporciona un estándar dirigido tanto a desarrolladores como a propietarios de aplicaciones, el cual puede ser utilizado para comparar aplicaciones en términos de seguridad. -- Uso como guía - Hace de guía durante todas las fases del desarrollo y pruebas de seguridad de las aplicaciones móviles. -- Uso durante la compra o contratación - Proporcionar una línea base para la verificación de la seguridad de aplicaciones móviles. - -## Modelo de Seguridad para una Aplicación Móvil - -El MASVS define dos niveles de verificación de seguridad (MASVS-L1 y MASVS-L2), así como un conjunto de requisitos de resistencia a la ingeniería inversa (MASVS-R). El nivel MASVS-L1 contiene requisitos genéricos de seguridad recomendados para todas las aplicaciones móviles, mientras que MASVS-L2 debería aplicarse a aplicaciones que manejan datos altamente sensibles. MASVS-R cubre los controles de seguridad adicionales que se pueden aplicar si la prevención de las amenazas del lado del cliente es un objetivo de diseño. - -El cumplimiento de los requisitos de MASVS-L1 dará como resultado una aplicación segura que sigue las mejores prácticas de seguridad y no sufre de las vulnerabilidades más comunes. MASVS-L2 añade controles adicionales de defensa en profundidad, tales como _SSL certificate pinning_, haciendo la aplicación resistente a ataques más sofisticados, siempre y cuando los controles de seguridad del sistema operativo móvil estén intactos y que el usuario final no sea considerado como un potencial adversario. El cumplimiento de todos o de un subconjunto de los requisitos de protección de software del nivel MASVS-R ayuda a prevenir amenazas específicas del lado del cliente cuando el usuario final es considerado malicioso y/o el sistema operativo móvil ha sido comprometido. - -**I: Aunque recomendamos implementar los controles MASVS-L1 en toda aplicación, la implementación de uno o varios de los controles, o el no hacerlo, debería ser una decisión basada en el riesgo. Dicha decisión deberá ser correctamente comunicada a los dueños del negocio.** - -**II: Los controles de protección de software listados en MASVS-R y descritos en la MASTG pueden ser eludidos y no deben nunca reemplazar los demás controles de seguridad. Al contrario, su intención es añadir controles de protección adicionales (específicos a ciertas amenazas) para las aplicaciones que ya de por sí cumplen los requisitos MASVS-L1 y/o MASVS-L2.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### Estructura del Documento - -La primera parte del MASVS contiene una descripción del modelo de seguridad y de los niveles de verificación disponibles, seguido de recomendaciones sobre cómo utilizar el estándar en la práctica. En la segunda parte se detallan los requisitos de seguridad, junto con un mapeo a los distintos niveles de verificación. Los requisitos se han agrupado en ocho categorías (V1 a V8) basadas en el objetivo/alcance técnico. La siguiente nomenclatura se utiliza a lo largo del MASVS y la MASTG: - -- *Categoría de los requisitos:* MASVS-Vx, p. ej. MASVS-V2: Requisitos de Almacenamiento de datos y Privacidad. -- *Requisito:* MASVS-Vx.y, p. ej. MASVS-V2.2: "No se debe almacenar información sensible fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema." - -### Niveles de Verificación Detallados - -#### MASVS-L1: Seguridad Estándar - -Una aplicación móvil que logra el nivel MASVS-L1 se adhiere a las mejores prácticas de seguridad en aplicaciones móviles. Cumple con los requisitos básicos en términos de calidad de código, manejo de los datos sensibles e interacción con el entorno móvil. Debe existir un proceso de pruebas para verificar los controles de seguridad. Este nivel es apropiado para todas las aplicaciones móviles. - -#### MASVS-L2: Defensa en Profundidad - -MASVS-L2 introduce controles de seguridad avanzados que van más allá de los requisitos estándar. Para cumplir con el MASVS-L2, debe existir un modelo de amenazas y la seguridad debe ser una parte fundamental de la arquitectura y el diseño de la aplicación. Tomando ese modelo de amenazas como base, deben de seleccionarse e implementarse los controles del MASVS-L2 que correspondan. Este nivel es apropiado para aplicaciones que manejan datos altamente sensibles, como las aplicaciones de banca móvil. - -#### MASVS-R: Resistencia contra la Ingeniería Inversa y la Manipulación - -La aplicación cuenta con el nivel de seguridad específico para la aplicación y también es resistente a ataques específicos y claramente definidos en el lado del cliente, como alteración, modificación o ingeniería inversa para extraer código o datos sensibles. Esta aplicación aprovecha las características de seguridad del hardware o bien técnicas de protección de software suficientemente fuertes y verificables. MASVS-R es adecuado para las aplicaciones que manejan datos altamente confidenciales y puede servir como medio para proteger la propiedad intelectual o dificultar la manipulación de una aplicación. - -### Uso Recomendado - -Las aplicaciones pueden ser verificadas en base a los niveles MASVS-L1 o MASVS-L2 de acuerdo con la evaluación previa del riesgo y el nivel general de seguridad requerido. MASVS-L1 es aplicable a todas las aplicaciones móviles, mientras que MASVS-L2 se recomienda generalmente para las aplicaciones que manejan datos y/o funciones sensibles. MASVS-R (o partes de él) puede aplicarse para verificar la resistencia frente a amenazas específicas, como el reempaquetado o la extracción de datos sensibles, *además* de una verificación de seguridad adecuada. - -En resumen, los siguientes tipos de verificación están disponibles: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Las diferentes combinaciones reflejan diferentes grados de seguridad y resistencia. El objetivo es permitir la flexibilidad: por ejemplo, un juego móvil puede no requerir controles de seguridad MASVS-L2, como la autenticación de doble factor por razones de usabilidad, pero seguramente deba intentar prevenir la manipulación del código por razones de negocio. - -#### Cómo Elegir el Tipo de Verificación - -La implementación de los requisitos del nivel MASVS-L2 aumenta la seguridad, pero al mismo tiempo podría aumentar el coste de desarrollo y potencialmente empeorar la experiencia del usuario final (el compromiso clásico). En general, MASVS-L2 debe utilizarse siempre que tenga sentido desde el punto de vista del riesgo frente al coste que conlleva (es decir, cuando la potencial pérdida causada por un compromiso de confidencialidad o integridad sea superior al coste de implementación que suponen los controles de seguridad adicionales). Una evaluación de riesgo debe ser el primer paso antes de aplicar el MASVS. - -##### Ejemplos - -###### MASVS-L1 - -- Todas las aplicaciones móviles. El nivel MASVS-L1 enumera las mejores prácticas de seguridad que se pueden seguir con un impacto razonable en el coste de desarrollo y la experiencia del usuario. Los requisitos del MASVS-L1 pueden aplicarse en cualquier aplicación no apta para los niveles superiores. - -###### MASVS-L2 - -- Industria de la Salud: aplicaciones móviles que almacenan información personal identificable que puede ser utilizada para el robo de identidad, pagos fraudulentos, o una variedad de esquemas de fraude. Para el sector de la salud en los Estados Unidos, las consideraciones de cumplimiento incluyen la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA, por sus siglas en inglés), Privacidad, Seguridad, Reglas de Notificación de Violación (Breach Notification Rules) y Reglas de Seguridad del Paciente (Patient Safety Rule). - -- Sector Financiero: aplicaciones que permiten el acceso a información altamente sensible como números de tarjetas de crédito, información personal o que permiten al usuario mover fondos. Estas aplicaciones deben tener controles de seguridad adicionales para prevenir el fraude. Las aplicaciones financieras necesitan asegurar el cumplimiento de las normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS), Gramm Leech Bliley Act y Sarbanes-Oxley Act (SOX). - -###### MASVS L1+R - -- Aplicaciones móviles donde la protección de la propiedad intelectual (IP, por sus siglas en inglés) es un claro objetivo empresarial. Los controles de resistencia listados en MASVS-R se pueden utilizar para incrementar el esfuerzo necesario para obtener el código fuente original y dificultar la manipulación / _cracking_. - -- Industria de los videojuegos: aplicaciones con una necesidad esencial de evitar la posibilidad de _modding_ y el engaño, como los videojuegos competitivos _online_. Hacer trampa es un tema importante en los juegos _online_, ya que una gran cantidad de tramposos conduce a un descontento de la base de jugadores y, en última instancia, puede causar que un juego fracase. MASVS-R proporciona controles básicos contra la manipulación para ayudar a incrementar el esfuerzo que los tramposos deberían realizar. - -###### MASVS L2+R - -- Industria Financiera: aplicaciones de banca móvil que permiten al usuario mover fondos, donde las técnicas de inyección de código e instrumentación en dispositivos comprometidos suponen un riesgo. En este caso, los controles MASVS-R se pueden utilizar para dificultar la manipulación de código, dificultando el trabajo de potenciales autores de _malware_. - -- Todas las aplicaciones móviles que, por diseño, necesitan almacenar datos sensibles en el dispositivo móvil y, al mismo tiempo, deben soportar una amplia gama de dispositivos y versiones del sistema operativo. En este caso, los controles de resistencia pueden utilizarse como una medida de defensa en profundidad para aumentar el esfuerzo de los atacantes que intentan extraer datos sensibles. - -- Todas las aplicaciones que contengan "compras en la aplicación" deberían de proteger su contenido de pago utilizando idealmente controles MASVS-L2 y del lado del servidor. Sin embargo, puede haber casos en los que no sea posible implementar la proctección del lado del servidor. En esos casos, deberían de aplicarse los controles MASVS-R de forma adicional para incrementar el esfuerzo necesario para revertir o manipular la aplicación. diff --git a/Document-es/0x04-Assessment_and_Certification.md b/Document-es/0x04-Assessment_and_Certification.md deleted file mode 100644 index 4f7458c27..000000000 --- a/Document-es/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,56 +0,0 @@ -# Evaluación y Certificación - -## Posición de OWASP en cuanto a Certificaciones MASVS y Marcas de Confianza - -OWASP, como una organización sin ánimo de lucro e independiente de toda empresa, no certifica a ningún proveedor, verificador o software. - -Ninguna certificación, marca de garantía o confianza actualmente existente ha sido examinada, registrada o certificada oficialmente por OWASP. -Por tanto, una organización que confía en tal opinión debe tener la precaución de la confianza depositada en cualquier tercero o marca de confianza que alega la certificación (M)ASVS. - -Esto no debe impedir que las organizaciones ofrezcan tales servicios de seguridad, siempre que no reclamen la certificación oficial OWASP. - -## Guía para Certificar Aplicaciones Móviles - -La forma recomendada de verificar la conformidad de una aplicación móvil con el MASVS es realizar una revisión de "libro abierto", lo que significa que los verificadores tienen acceso a recursos claves como arquitectos y desarrolladores de la aplicación, documentación del proyecto, código fuente y acceso autenticado a los terminales, incluyendo acceso a al menos una cuenta de usuario para cada función. - -Es importante tener en cuenta que el MASVS sólo cubre la seguridad de la aplicación móvil (en el dispositivo del cliente) y la comunicación de red entre la aplicación y sus puntos remotos, así como algunos requisitos básicos y genéricos relacionados con la autenticación del usuario y la gestión de sesiones. No contiene requisitos específicos para los servicios remotos (por ejemplo, servicios web) asociados a la aplicación, salvo para un conjunto limitado de requisitos genéricos relacionados con la autenticación y la gestión de sesiones. No obstante, MASVS-V1 especifica que los servicios remotos deben ser cubiertos por el modelo general de amenazas, y ser verificados contra los estándares apropiados, tales como el OWASP ASVS. - -Los informes creados por organismos de certificación deberían incluir los siguientes elementos considerados como práctica estándar de la industria: - -- El alcance de la verificación, especialmente cuando un componente clave está fuera de dicho alcance. -- Un resumen de los resultados de la verificación, incluyendo las pruebas superadas y fallidas, con instrucciones claras de cómo resolver las pruebas fallidas. -- Mantener documentos de trabajo detallados, incluyendo capturas de pantalla o vídeos. -- Guiones para explotar de forma fiable y repetida un problema. -- Registros electrónicos de las pruebas, como los _logs_ de un proxy y cualquier nota asociada. - -Nòtese que no basta con simplemente ejecutar una herramienta y presentar un informe sobre los fallos; esto no aporta suficientes evidencias de que se han analizado y probado a fondo todos los aspectos a nivel de una certificación. En caso de controversia, debe haber pruebas suficientes para demostrar que todos los requisitos verificados han sido efectivamente probados. - -### Usando la Guía de Pruebas de Seguridad Móvil de OWASP (MASTG) - -La OWASP MASTG es una guía para la verificación de la seguridad de las aplicaciones móviles. Describe los procedimientos técnicos para verificar los requisitos listados en el MASVS. La MASTG incluye una lista de casos de prueba, cada uno de los cuales se corresponde con un requerimiento del MASVS. Mientras que los requerimientos del MASVS son de alto nivel y genéricos, la MASTG proporciona recomendaciones detalladas y procedimientos de verificación para cada uno de los sistemas operativos móviles. - -### El Papel de las Herramientas de Pruebas de Seguridad Automatizadas - -Se recomienda el uso de escáneres de código fuente y herramientas de auditoría de tipo _black-box_ para aumentar la eficiencia siempre que sea posible. Sin embargo, no es posible completar la verificación MASVS utilizando únicamente herramientas automatizadas: cada aplicación móvil es diferente. Por tanto, la comprensión de la arquitectura general, la lógica de negocio y los problemas específicos de las tecnologías y plataformas que se utilizan es un requerimiento obligatorio para verificar la seguridad de la aplicación. - -## Otros Usos - -### Como Guía Detallada para una Arquitectura Segura - -Uno de los usos más comunes del MASVS es como guía para los arquitectos de seguridad. Los dos principales esquemas de seguridad en la arquitectura, SABSA o TOGAF, carecen de una gran cantidad de información necesaria para completar las revisiones de seguridad en la arquitectura de las aplicaciones móviles. El MASVS se puede utilizar para llenar esos vacíos permitiendo a los arquitectos elegir los mejores controles para los problemas comunes de seguridad en las aplicaciones móviles. - -### Como Reemplazo de las _Checklists_ de Desarrollo Seguro de Aplicaciones Móviles - -Muchas organizaciones pueden beneficiarse de la adopción del MASVS simplemente eligiendo uno de los niveles, o haciendo su propio _fork_ del MASVS y cambiando lo que se requiera específicamente en el contexto y el nivel de riesgo de cada aplicación. Fomentamos este tipo de _forks_ siempre y cuando se mantenga la trazabilidad, de modo que si una aplicación cumple con un requerimiento del MASVS original, lo mismo ocurre en los _forks_ del estándar cuando éste evoluciona. - -### Como Base para las Metodologías de Pruebas de Seguridad - -Una buena metodología de pruebas de seguridad para aplicaciones móviles debe cubrir todos los requisitos listados en el MASVS. La OWASP MASTG describe los casos de prueba de tipo _black-box_ y _white-box_ para cada requisito de verificación. - -### Como Guía para la Automatización de Pruebas Unitarias y de Integración - -El MASVS está diseñado para ser altamente verificable, con la única excepción de los requisitos de arquitectura. Las pruebas unitarias, de integración y de aceptación automatizadas, basadas en los requisitos del MASVS, pueden integrarse en el ciclo de vida de desarrollo de software (SDLC, por sus siglas en inglés). Esto no sólo aumenta la conciencia de seguridad de los desarrolladores, sino que también mejora la calidad general de las aplicaciones desarrolladas, y reduce la cantidad de hallazgos durante las pruebas de seguridad en la fase previa al _release_. - -### Para el Entrenamiento en Desarrollo Seguro - -El MASVS también se puede utilizar para definir características de aplicaciones móviles seguras. Muchos cursos de "desarrollo segura" son simplemente cursos de _hacking_ ético con algunos consejos de programación segura. Esto no ayuda a los desarrolladores. En su lugar, los cursos de desarrollo seguro de aplicaciones móviles pueden utilizar el MASVS, con un fuerte enfoque en los controles proactivos documentados en el MASVS, en lugar de basarse simplemente en, por ejemplo, el "Top 10 de problemas de seguridad en el desarrollo software". diff --git a/Document-es/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-es/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 5b9bcdf5d..000000000 --- a/Document-es/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: Requisitos de Arquitectura, Diseño y Modelado de Amenazas - -## Objetivo de la Categoría V1 - -En un mundo perfecto, la seguridad sería considerada en todas las fases del desarrollo. Sin embargo, en la realidad, la seguridad es a menudo sólo considerada en una etapa tardía del desarrollo del software. Además de los controles técnicos, el MASVS requiere que existan procesos que garanticen que la seguridad se ha abordado explícitamente al planificar la arquitectura de la aplicación móvil, y que se conocen los roles funcionales y de seguridad de todos los componentes. Dado que la mayoría de las aplicaciones móviles actúan como clientes de los servicios remotos, debe garantizarse que también se apliquen las medidas de seguridad adecuadas a dichos servicios, no basta con probar la aplicación móvil de forma aislada. - -La categoría V1 lista los requisitos pertinentes a la arquitectura y al diseño de la aplicación. Debido a esto es la única categoría que no se corresponde con casos de test de la Guía de Pruebas Móviles de OWASP. Para cubrir temas tales como el modelado de amenazas, SDLC seguro, gestión de claves, los usuarios del MASVS deben consultar los respectivos proyectos de OWASP y/u otros estándares como los que se encuentran enlazados debajo. - -## Requisitos de Verificación de Seguridad - -A continuación, se enumeran los requisitos para MASVS-L1 y MASVS-L2. - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Todos los componentes se encuentran identificados y asegurar que son necesarios. | x | x | -| **1.2** | MSTG-ARCH-2 | Los controles de seguridad nunca se aplican sólo en el cliente, sino que también en los respectivos servidores. | x | x | -| **1.3** | MSTG-ARCH-3 | Se definió una arquitectura de alto nivel para la aplicación y los servicios y se incluyeron controles de seguridad en la misma. | x | x | -| **1.4** | MSTG-ARCH-4 | Se identificó claramente la información considerada sensible en el contexto de la aplicación móvil. | x | x | -| **1.5** | MSTG-ARCH-5 | Todos los componentes de la aplicación están definidos en términos de la lógica de negocio o las funciones de seguridad que proveen. | | x | -| **1.6** | MSTG-ARCH-6 | Se realizó un modelado de amenazas para la aplicación móvil y los servicios en el que se definieron las mismas y sus contramedidas. | | x | -| **1.7** | MSTG-ARCH-7 | Todos los controles de seguridad poseen una implementados centralizada. | | x | -| **1.8** | MSTG-ARCH-8 | Existe una política explícita sobre el uso de claves criptográficas (si se usan) a través de todo su ciclo de vida. Idealmente siguiendo un estándar de gestión de claves como el NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | Existe un mecanismo para forzar las actualizaciones de la aplicación móvil. | | x | -| **1.10** | MSTG-ARCH-10 | La implementación de medidas de seguridad es una parte esencial durante todo el ciclo de vida del desarrollo de software de la aplicación. | | x | -| **1.11** | MSTG-ARCH-11 | Existe una política de divualgación responsable y es llevada a cabo adecuadamente. | | x | -| **1.12** | MSTG-ARCH-12 | La aplicación debería de cumplir con las leyes y regulaciones de privacidad. | x | x | - -## Referencias - -Para más información, ver también: - -- OWASP Top 10 Móvil: M10 (Funcionalidades Extrañas) - -- Modelado de Amenazas (OWASP) - -- "Cheat Sheet" del Ciclo de Vida del Desarrollo Software Seguro (OWASP) - -- Microsoft SDL - -- NIST SP 800-57 (Recomendación de Gestión de Claves) - -- security.txt - diff --git a/Document-es/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-es/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 49d24f144..000000000 --- a/Document-es/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Requisitos de Almacenamiento de datos y Privacidad - -## Objetivo de la Categoría V2 - -La protección de datos sensibles, como las credenciales del usuario y la información privada, es un aspecto clave de la seguridad móvil. En primer lugar, los datos confidenciales pueden exponerse involuntariamente a otras aplicaciones que se ejecutan en el mismo dispositivo si se utilizan de forma inadecuada mecanismos de comunicación entre procesos del sistema operativo. Los datos también pueden filtrarse involuntariamente en el almacenamiento en la nube, las copias de seguridad o la caché del teclado. Además, los dispositivos móviles pueden perderse o robarse más fácilmente que otros tipos de dispositivos, por lo que un adversario que obtiene acceso físico al mismo es un escenario más probable. En ese caso, se pueden implementar protecciones adicionales para dificultar la recuperación de los datos sensibles. - -El MASVS se centra en las aplicaciones y por esto no cubre políticas para el dispositivo como Mobile Device Managment (MDM) () o Enter (EDM). Igualmente se recomienda utilizar estas soluciones en contextos empresariales. - -### Definición de Datos Sensibles - -Los datos sensibles en el contexto del MASVS se refieren tanto a las credenciales de usuario como a cualquier otro dato que se considere sensible en el contexto particular de los siguientes ejemplos: - -- Información de identificación personal que puede ser usada para el robo de identidad: información de la Seguridad Social, números de tarjetas de crédito, números de cuentas bancarias, información médica. -- Datos altamente confidenciales que, en caso de que ser comprometidos, ocasionarían daños a la reputación y/o costes financieros: información contractual, información cubierta por acuerdos de confidencialidad, información de gestión. -- Cualquier dato que debe ser protegido por ley o por razones de conformidad. - -## Requisitos de Verificación de Seguridad - -La gran mayoría de las cuestiones relativas a la divulgación de datos pueden prevenirse siguiendo reglas sencillas. La mayoría de los controles enumerados en este capítulo son obligatorios para todos los niveles de verificación. - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Las funcionalidades de almacenamiento de credenciales del sistema deben ser utilizadas para almacenar información sensible, tal como información personal, credenciales de usuario o claves criptográficas. | x | x | -| **2.2** | MSTG-STORAGE-2 | No se debe almacenar información sensible fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema. | x | x | -| **2.3** | MSTG-STORAGE-3 | No se debe escribir información sensible en los registros (logs) de la aplicación. | x | x | -| **2.4** | MSTG-STORAGE-4 | No se debe compartir información sensible con servicios externos salvo que sea una necesidad de la arquitectura. | x | x | -| **2.5** | MSTG-STORAGE-5 | Se debe desactivar la caché del teclado en los campos de texto que contienen información sensible. | x | x | -| **2.6** | MSTG-STORAGE-6 | No se debe exponer información sensible mediante mecanismos de comunicación entre procesos (IPC). | x | x | -| **2.7** | MSTG-STORAGE-7 | No se debe exponer información sensible como contraseñas y números de tarjetas de crédito a través de la interfaz o capturas de pantalla. | x | x | -| **2.8** | MSTG-STORAGE-8 | No se debe incluir información sensible en las copias de seguridad generadas por el sistema operativo. | | x | -| **2.9** | MSTG-STORAGE-9 | La aplicación debe eliminar toda información sensible de la vista cuando la aplicación pasa a un segundo plano. | | x | -| **2.10** | MSTG-STORAGE-10 | La aplicación no debe conservar ninguna información sensible en memoria más allá del tiempo necesario y la memoria debe limpiarse trás su uso. | | x | -| **2.11** | MSTG-STORAGE-11 | La aplicación obliga a que exista una política mínima de seguridad en el dispositivo, como por ejemplo que el usuario deba configurar un código de acceso. | | x | -| **2.12** | MSTG-STORAGE-12 | La aplicación debe informar al usuario tanto de los tipos de información personal que procesa como de las buenas prácticas en seguridad que el usuario debería seguir al utilizar la aplicación. | x | x | -| **2.13** | MSTG-STORAGE-13 | No debe guardarse ningún tipo de información sensible de forma local en el dispositivo móvil. En su lugar, esa información debería ser obtenida desde un sistema remoto sólo cuando es necesario y únicamente residir en memoria. | | x | -| **2.14** | MSTG-STORAGE-14 | En caso de ser necesario guardar información sensible de forma local, ésta debe de ser cifrada usando una clave derivada del hardware de almacenamiento seguro, el cual debe requerir autenticación previa. | | x | -| **2.15** | MSTG-STORAGE-15 | El almacenamiento local de la aplicación debe ser borrado trás un número excesivo de intentos fallidos de autenticación. | | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-es/0x08-V3-Cryptography_Verification_Requirements.md b/Document-es/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 639cf71fc..000000000 --- a/Document-es/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Requisitos de Criptografía - -## Objetivo de la Categoría V3 - -La criptografía es un componente esencial a la hora de proteger los datos almacenados en un dispositivo móvil. También es una categoría en la que las cosas pueden ir terriblemente mal, especialmente cuando no se siguen las convenciones del estándar. El propósito de estos controles es asegurarse de que la aplicación utiliza criptografía siguiendo las mejores prácticas de la industria, incluyendo: - -- Uso de librerías criptográficas reconocidas y probadas. -- Configuración y elección apropiada de primitivas criptográficas. -- Uso de generadores de números aleatorios suficientemente seguros. - -## Requisitos de Verificación de Seguridad - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | La aplicación no debe depender únicamente de criptografía simétrica cuyas claves se encuentran directamente en el código fuente de la misma.| x | x | -| **3.2** | MSTG-CRYPTO-2 | La aplicación debe utilizar implementaciones de criptografía probadas. | x | x | -| **3.3** | MSTG-CRYPTO-3 | La aplicación debe utilizar controles de seguridad que son apropiados para casos de uso personalizados y la configuración de sus parámetros siguen las buenas prácticas de la industria. | x | x | -| **3.4** | MSTG-CRYPTO-4 | La aplicación no debe utilizar protocolos o algoritmos criptográficos considerados obsoletos para su uso en seguridad. | x | x | -| **3.5** | MSTG-CRYPTO-5 | La aplicación no debe reutilizar una misma clave criptográfica para varios propósitos. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Los valores aleatorios son generados utilizando un generador de números aleatorios suficientemente seguro. | x | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-es/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-es/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index b95fa297e..000000000 --- a/Document-es/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Requisitos de Autenticación y Manejo de Sesiones - -## Objetivo de la Categoría V4 - -En la mayoría de los casos, una parte esencial de la arquitectura global de aplicaciones móviles es que los usuarios deben iniciar sesión en un servicio remoto. Aunque la mayor parte de la lógica ocurre en el servidor, MASVS define algunos requisitos básicos sobre cómo manejar las cuentas y sesiones del usuario. - -## Requisitos de Verificación de Seguridad - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Si la aplicación provee acceso a un servicio remoto, un mecanismo aceptable de autenticación como usuario y contraseña es realizado en el servidor remoto. | x | x | -| **4.2** | MSTG-AUTH-2 | Si se utiliza la gestión de sesión por estado, el servidor remoto usa tokens de acceso aleatorios para autenticar los pedidos del cliente sin requerir el envío de las credenciales del usuario en cada uno. | x | x | -| **4.3** | MSTG-AUTH-3 | Si se utiliza la autenticación basada en tokens sin estado, el servidor proporciona un token que se ha firmado utilizando un algoritmo seguro. | x | x | -| **4.4** | MSTG-AUTH-4 | Cuando el usuario cierra sesión se termina la sesión también en el servidor. | x | x | -| **4.5** | MSTG-AUTH-5 | Debe existir una política de contraseñas y debe ser aplicada en el servidor. | x | x | -| **4.6** | MSTG-AUTH-6 | El servidor debe implementar mecanismos que eviten excesivos de intentos de inicio de sesión. | x | x | -| **4.7** | MSTG-AUTH-7 | Las sesiones y los tokens de acceso deben expirar pasado un tiempo predefinido de inactividad. | x | x | -| **4.8** | MSTG-AUTH-8 | La autenticación biométrica, si la hay, no debe estar asociada a eventos (p. ej. usando una API que simplemente retorna "true" o "false"), sino basada en el desbloqueo del keychain/keystore (almacenamiento seguro). | | x | -| **4.9** | MSTG-AUTH-9 | En el servidor debe existir un mecanismo de segundo factor de autenticación (2FA) y éste debe ser aplicado de forma consistente. | | x | -| **4.10** | MSTG-AUTH-10 | Para realizar transacciones críticas se requiere una autenticación adicional (step-up). | | x | -| **4.11** | MSTG-AUTH-11 | La aplicación debe informar al usuario acerca de todas las actividades sensibles en su cuenta. El usuario es capaz de ver una lista de los dispositivos conectados, información contextual (dirección IP, localización, etc.), y debe ser capaz de bloquear dispositivos. | | x | -| **4.12** | MSTG-AUTH-12 | Los modelos de autorización deberían de ser definidos e impuestos por el sistema remoto. | x | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- General - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-es/0x10-V5-Network_communication_requirements.md b/Document-es/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 28d1c155c..000000000 --- a/Document-es/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,40 +0,0 @@ -# V5: Requisitos de Comunicación a través de la red - -## Objetivo de la Categoría V5 - -Los controles enumerados en esta categoría tienen el objetivo de asegurar la confidencialidad e integridad de la información intercambiada entre la aplicación móvil y los servicios del servidor. Como mínimo se deben utilizar canales seguros y cifrados utilizando el protocolo TLS con las configuraciones apropiadas. En el nivel 2 se establecen medidas en profundidad como fijación de certificados SSL. - -## Requisitos de Verificación de Seguridad - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | La información se debe enviar cifrada utilizando TLS. El canal seguro es usado consistentemente en la aplicación. | x | x | -| **5.2** | MSTG-NETWORK-2 | Las configuraciones del protocolo TLS deben seguir las buenas prácticas de la industria, o deben hacerlo lo mejor posible en caso de que el sistema operativo del dispositivo no soporte los estándares recomendados. | x | x | -| **5.3** | MSTG-NETWORK-3 | La aplicación debe verificar el certificado X.509 del sistema remoto al establecer el canal seguro y sólo se deben aceptar certificados firmados por una autoridad certificadora (CA) de confianza. | x | x | -| **5.4** | MSTG-NETWORK-4 | La aplicación debe utilizar su propio almacén de certificados o realiza _pinning_ del certificado o la clave pública del servidor. Bajo ningún concepto establecerá conexiones con servidores que ofrecen otros certificados o claves, incluso si están firmados por una autoridad certificadora (CA) de confianza. | | x | -| **5.5** | MSTG-NETWORK-5 | La aplicación no debe depender de un único canal de comunicaciones inseguro (email o SMS) para operaciones críticas como registro de usuarios o recuperación de cuentas. | | x | -| **5.6** | MSTG-NETWORK-6 | La aplicación sólo debe depender de bibliotecas de conectividad y seguridad actualizadas. | | x | - - - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-es/0x11-V6-Interaction_with_the_environment.md b/Document-es/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index bc46e0b60..000000000 --- a/Document-es/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Requisitos de Interacción con la Plataforma - -## Objetivo de la Categoría V6 - -Estos controles revisan que se utilicen las APIs de la plataforma y componentes estándar de una manera segura. Además, se cubre la comunicación entre aplicaciones (IPC). - -## Requisitos de Verificación de Seguridad - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | La aplicación debe requerir la mínima cantidad de permisos necesaria. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Todo dato ingresado por el usuario o cualquier fuente externa debe ser validado y, si es necesario, saneado. Esto incluye información recibida por la UI o mecanismos IPC como los Intents, URLs y datos provenientes de la red. | x | x | -| **6.3** | MSTG-PLATFORM-3 | La aplicación no debe exponer ninguna funcionalidad sensible a través de esquemas de URL salvo que dichos mecanismos estén debidamente protegidos. | x | x | -| **6.4** | MSTG-PLATFORM-4 | La aplicación no debe exponer ninguna funcionalidad sensible a través de mecanismos IPC salvo que dichos mecanismos estén debidamente protegidos. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript debe estar deshabilitado en los WebViews salvo que sea necesario. | x | x | -| **6.6** | MSTG-PLATFORM-6 | Las WebViews se deben configurar para permitir el mínimo número de protocolos requeridos (idealmente sólo https). Aquellos considerados como peligrosos deben estar deshabilitados (p. ej. file, tel y app-id). | x | x | -| **6.7** | MSTG-PLATFORM-7 | Si los métodos nativos son expuestos en WebViews, debe verificarse que cualquier componente JavaScript se carga exclusivamente desde el contenedor de la aplicación. | x | x | -| **6.8** | MSTG-PLATFORM-8 | La serialización de objetos, si se realiza, debe implementarse utilizando APIs seguras. | x | x | -| **6.9** | MSTG-PLATFORM-9 | La aplicación debe protegerse contra ataques de tipo screen overlay. (sólo en Android) | | x | -| **6.10** | MSTG-PLATFORM-10 | La caché, el almacenamiento y los recursos cargados (JavaScript, etc.) de las WebViews deben borrarse antes de destruir la WebView. | | x | -| **6.11** | MSTG-PLATFORM-11 | Se debe verificar que la aplicación impide el uso de teclados de terceros siempre que se introduzca información sensible. (sólo en iOS) | | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-es/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-es/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 8e5a0e4df..000000000 --- a/Document-es/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Requisitos de Calidad del Código y de la Configuración del Compilador - -## Objetivo de la Categoría V7 - -Estos controles buscan asegurar que se siguieron las prácticas de seguridad básicas en el desarrollo de la aplicación y que se activaron las funcionalidades "gratuitas" ofrecidas por el compilador. - -## Requisitos de Verificación de Seguridad - -| # | MSTG-ID | Descripción | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | La aplicación debe estar firmada y provista con un certificado válido, cuya clave privada está debidamente protegida. | x | x | -| **7.2** | MSTG-CODE-2 | La aplicación debe estar publicada en modo release y con sus configuraciones apropiadas (p. ej. non-debuggable). | x | x | -| **7.3** | MSTG-CODE-3 | Los símbolos de depuración deben estar eliminados de los binarios nativos. | x | x | -| **7.4** | MSTG-CODE-4 | Cualquier código de depuración y/o de asistencia al desarrollador (p. ej. código de test, backdoors, configuraciones ocultas) debe ser eliminado. La aplicación no debe hacer logs detallados de errores ni de mensajes de depuración. | x | x | -| **7.5** | MSTG-CODE-5 | Todos los componentes de terceros deben ser identificados y revisados en busca de vulnerabilidades comunes. | x | x | -| **7.6** | MSTG-CODE-6 | La aplicación debe capturar y gestionar debidamente las posibles excepciones. | x | x | -| **7.7** | MSTG-CODE-7 | Un correcto control de errores debe denegar el acceso por defecto. | x | x | -| **7.8** | MSTG-CODE-8 | En el código no administrado, la memoria solicitada debe ser utilizada y liberada de manera correcta. | x | x | -| **7.9** | MSTG-CODE-9 | Las funcionalidades y las herramientas de seguridad gratuitas deben estar activadas. Esto incluye simplificación del código, protección de la pila, soporte PIE y conteo automático de referencias. | x | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-es/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-es/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 1efaac007..000000000 --- a/Document-es/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,68 +0,0 @@ -# V8: Requisitos de Resistencia ante la Ingeniería Inversa - -## Objetivo de la Categoría V8 - -En esta sección se cubren las protecciones recomendadas para aplicaciones que manejan o dan acceso a información o funcionalidades sensibles. La falta de estos controles no implica necesariamente que la aplicación contenga vulnerabilidades. Estos controles están pensados para incrementar la resistencia contra la ingeniería inversa, dificultando al adversario el acceso a los datos o el entendimiento del funcionamiento interno de la aplicación. - -Los controles de esta sección deben aplicarse según sea necesario, basándose en una evaluación de los riesgos causados por la manipulación no autorizada de la aplicación y/o la ingeniería inversa del código. Sugerimos consultar el documento de OWASP ["Riesgos técnicos de la Ingeniería Inversa y Modificaciones de Código no Autorizadas"](https://wiki.owasp.org/index.php/Technical_Risks_of_Reverse_Engineering_and_Unauthorized_Code_Modification) para obtener una lista de los riesgos de negocio, así como de las amenazas técnicas asociadas. - -**Tenga en cuenta que los controles de software nunca deben utilizarse como reemplazo de los controles de seguridad. Los controles listados en MASVR-R buscan añadir controles de protección adicionales y específicos contra las amenazas a las aplicaciones que también cumplen con los requisitos de seguridad del MASVS.** - -Se aplican las siguientes consideraciones: - -1. Debe definirse un modelo de amenaza que defienda claramente las amenazas del lado del cliente. Además, debe especificarse el grado de protección que debe proporcionar el sistema. Por ejemplo, un objetivo podría ser forzar a los autores de malware pensado para obtener información de la aplicación, a que tengan que invertir importantes esfuerzos para realizar la ingeniería inversa. - -2. El modelo de amenaza debe ser sensato. Por ejemplo, ocultar una clave criptográfica en una implementación de caja blanca es un problema si el atacante puede simplemente utilizar la aplicación como un todo. - -3. La eficacia de la protección siempre debe ser verificada por un experto con experiencia en el testeo y uso de tipos específicos de anti-manipulación y ofuscación. Ver también el capítulo ["Ingeniería Inversa y Manipulación de Aplicaciones Móviles"](https://github.com/OWASP/owasp-mastg/blob/master/Document/0x04c-Tampering-and-Reverse-Engineering.md) en la Guía de Pruebas de Seguridad Móvil (OWASP MSTG). - - - -### Impedir el Análisis Dinámico y la Manipulación - -| # | MSTG-ID | Descripción | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | La aplicación detecta y responde a la presencia de un dispositivo rooteado, ya sea alertando al usuario o finalizando la ejecución de la aplicación. | x | -| **8.2** | MSTG-RESILIENCE-2 | La aplicación impide la depuración o detecta y responde a la misma. Se deben cubrir todos los protocolos de depuración. | x | -| **8.3** | MSTG-RESILIENCE-3 | La aplicación detecta y responde a cualquier modificación de ejecutables y datos críticos de la propia aplicación. | x | -| **8.4** | MSTG-RESILIENCE-4 | La aplicación detecta la presencia de herramientas de ingeniería inversa o frameworks comúnmente utilizados. | x | -| **8.5** | MSTG-RESILIENCE-5 | La aplicación detecta y responde a ser ejecutada en un emulador. | x | -| **8.6** | MSTG-RESILIENCE-6 | La aplicación detecta y responde ante modificaciones de código o datos en su propio espacio de memoria. | x | -| **8.7** | MSTG-RESILIENCE-7 | La aplicación implementa múltiples mecanismos de detección para los puntos del 8.1 al 8.6. Nótese que, a mayor cantidad y diversidad de mecanismos usados, mayor será la resistencia. | x | -| **8.8** | MSTG-RESILIENCE-8 | Los mecanismos de detección provocan distintos tipos de respuestas, incluyendo respuestas retardadas y silenciosas. | x | -| **8.9** | MSTG-RESILIENCE-9 | La ofuscación se aplica a las defensas del programa, lo que a su vez impide la desofuscación mediante análisis dinámico. | x | - -### Asociación del Dispositivo - -| # | MSTG-ID | Descripción | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | La aplicación implementa un “enlace al dispositivo” utilizando una huella del dispositivo derivada de varias propiedades únicas al mismo. | x | - - - -### Impedir la Comprensión - -| # | MSTG-ID | Descripción | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Todos los archivos ejecutables y bibliotecas correspondientes a la aplicación se encuentran cifrados, o bien los segmentos importantes de código se encuentran cifrados o "empaquetados" (packed). De este modo cualquier análisis estático trivial no revelará código o datos importantes. | x | -| **8.12** | MSTG-RESILIENCE-12 | Si el objetivo de la ofuscación es proteger código propietario, debe utilizarse un esquema de ofuscación apropiado para la tarea particular y robusto contra métodos de desofuscación manual y automatizada, considerando la investigación actual publicada. La eficacia del esquema de ofuscación debe verificarse mediante pruebas manuales. Nótese que, siempre que sea posible, las características de aislamiento basadas en hardware son preferibles a la ofuscación. | x | - -### Impedir el Eavesdropping - -| # | MSTG-ID | Descripción | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | A modo de defensa en profundidad, además de incluir un refuerzo (hardening) sólido de la comunicación, puede implementarse el cifrado de datos (payloads) a nivel de aplicación como medida adicional contra ataques de eavesdropping. | x | - -## Referencias - -La Guía de Pruebas de Seguridad Móvil de OWASP proporciona instrucciones detalladas para verificar los requisitos listados en esta sección. - -- Android - -- iOS - - -Para más información, ver también: - -- OWASP Top 10 Móvil: M8 (Modificación de Código) - -- OWASP Top 10 Móvil: M9 (Ingeniería Inversa) - -- Amenazas de Ingeniería Inversa (OWASP) - -- Ingeniería Inversa y Prevención de Modificación de Código (OWASP) - diff --git a/Document-es/0x90-Appendix-A_Glossary.md b/Document-es/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 7c0cb8a8a..000000000 --- a/Document-es/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Apéndice A: Glosario - -- **Aleatorización del Espacio de Direcciones (ASLR)** – Una técnica para hacer más difícil la explotación de errores de corrupción de memoria. -- **Seguridad de Aplicación** – La seguridad a nivel de aplicación se centra en el análisis de los componentes que componen la capa de aplicación del modelo de referencia de interconexión de sistemas abiertos (modelo OSI), en lugar de centrarse, por ejemplo, en el sistema operativo subyacente o las redes conectadas. -- **Verificación de la Seguridad de una Aplicación** – La evaluación técnica de una aplicación utilizando el OWASP MASVS. -- **Informe de la Verificación de la Seguridad de una Aplicación** – Un informe que documenta los resultados generales y el análisis detallado producido por el verificador para una aplicación particular. -- **Autenticación** – La verificación de la identidad alegada por el usuario de una aplicación. -- **Verificación Automatizada** – El uso de herramientas automatizadas (herramientas de análisis dinámico, estático o ambas) que utilizan firmas de vulnerabilidades para encontrar problemas. -- **Verificación de tipo Back-box** – Es un método de verificación de software que examina la funcionalidad de una aplicación sin tener en cuenta sus estructuras internas ni su funcionamiento. -- **Componente** – Una unidad de código autónoma, con un disco asociado e interfaces de red que se comunican con otros componentes. -- **Cross-Site Scripting (XSS)** – Una vulnerabilidad de seguridad que normalmente se encuentra en las aplicaciones web que permiten la inyección de scripts en el contenido del lado del cliente. -- **Módulo Criptográfico** – Hardware, software y/o firmware que implementa algoritmos criptográficos y/o genera claves criptográficas. -- **CWE** – CWE es una lista de debilidades comunes de seguridad de software desarrollada por la comunidad. Sirve como un lenguaje común, un instrumento de medición para las herramientas de seguridad de software, y como una línea base para la identificación de debilidades, mitigación y esfuerzos de prevención. -- **Pruebas Dinámicas de Seguridad de Aplicaciones (DAST)** – Las tecnologías de Pruebas Dinámicas de Seguridad de Aplicaciones (DAST, por sus siglas en inglés) están diseñadas para detectar indicios de vulnerabilidades de seguridad en una aplicación mientras se está ejecutando. -- **Verificaciones de Diseño** – La evaluación técnica de la seguridad de la arquitectura de una aplicación. -- **Verificación Dinámica** – El uso de herramientas automatizadas que utilizan firmas de vulnerabilidades para encontrar problemas durante la ejecución de una aplicación. -- **Identificador Único Global (GUID)** – Un número de referencia único utilizado como identificador en el software. -- **Hyper Text Transfer Protocol (HTTP)** – Un protocolo de aplicación para sistemas de información distribuidos y colaborativos. Es la base de la comunicación de datos para la World Wide Web. -- **Claves Grabadas (Hardcoded keys)** – Claves criptográficas que se encuentran almacenadas directamente en el dispositivo. -- **Comunicación Entre Procesos** – La comunicación entre procesos (IPC, por sus siglas en inglés) es un método mediante el cual un proceso se comunica con otro a través del kernel del dispositivo para coordinar sus actividades. -- **Validación de la Entrada** – La canonización y validación de las entradas de usuario no confiables. -- **JAVA Bytecode** – _Java bytecode_ es el conjunto de instrucciones de la máquina virtual Java (JVM). Cada _bytecode_ está compuesto por uno, o en algunos casos dos bytes que representan la instrucción (_opcode_), junto con cero o más bytes para pasar parámetros. -- **Código Malicioso** – Código introducido en una aplicación durante su desarrollo que es desconocido para el propietario de la aplicación y que elude la política de seguridad alegada por la misma. ¡No es lo mismo que malware, virus o gusano! -- **Malware** – Código ejecutable que se introduce en una aplicación durante el tiempo de ejecución sin el conocimiento del usuario o administrador de la misma. -- **Open Web Application Security Project (OWASP)** – OWASP es una comunidad abierta a nivel mundial y sin ánimo de lucro enfocada en mejorar la seguridad del software de aplicaciones. Nuestra misión es hacer que la seguridad de las aplicaciones sea "visible" para que las personas y las organizaciones puedan tomar decisiones informadas sobre los riesgos de seguridad de las aplicaciones. Ver: -- **Información de Identificación Personal (PII)** - La información de identificación personal (PII, por sus siglas en inglés) es la información que se puede utilizar por sí sola o junto con otra información para identificar, contactar o localizar a una sola persona, o para identificar a un individuo en su contexto. -- **Ejecutable de Posición Independiente (PIE)** – Es un ejecutable que, al ser cargado en memoria, se ejecuta correctamente independientemente de su dirección absoluta. -- **Infraestructura de Clave Pública (PKI)** – Una PKI es un acuerdo que vincula claves públicas con las identidades respectivas de las entidades. La vinculación se establece mediante un proceso de registro y expedición de certificados realizado por una autoridad de certificación (CA). -- **Pruebas Estáticas de Seguridad de Aplicaciones (SAST)** – Las pruebas estáticas de seguridad de aplicaciones (SAST) son un conjunto de tecnologías diseñadas para analizar el código fuente de la aplicación, el _bytecode_, los binarios del código y las condiciones del diseño para detectar indicios de vulnerabilidades de seguridad. Las soluciones SAST analizan una aplicación desde "dentro hacia fuera" en un estado reposo, i.e., cuando no se está ejecutando. -- **SDLC** – Ciclo de vida de desarrollo software. -- **Seguridad de la Arquitectura** – Una abstracción del diseño de una aplicación que identifica y describe dónde y cómo se utilizaran los controles de seguridad, además de la ubicación y sensibilidad de los datos tanto del usuario como de la aplicación. -- **Configuración de Seguridad** – La configuración en tiempo de ejecución de una aplicación que afecta a la forma en que se utilizan los controles de seguridad. -- **Control de Seguridad** – Una función o componente que realiza un chequeo de seguridad (por ejemplo, una verificación del control de acceso) o que cuando es invocado produce un evento de seguridad (por ejemplo, al generar un registro de auditoría). -- **Inyección SQL (SQLi)** – Una técnica de inyección de código utilizada para atacar aplicaciones basadas en datos, en la que se insertan instrucciones SQL maliciosas en un punto de entrada. -- **Autenticación SSO** – La Autenticación de inicio de sesión único (SSO, por sus siglas en inglés) se produce cuando un usuario inicia sesión en un cliente y luego se conecta desde otros servicios automáticamente, independientemente de la plataforma, tecnología o dominio que esté utilizando el usuario. Por ejemplo, un inicio de sesión en Google dará acceso automáticamente a los servicios de YouTube, Drive y Gmail. -- **Modelado de Amenazas** – Una técnica que consiste en desarrollar arquitecturas de seguridad cada vez más perfeccionadas para identificar agentes de amenazas, zonas de seguridad, controles de seguridad e importantes activos técnicos y empresariales. -- **Seguridad en la Capa de Transporte (TLS)** – Protocolos criptográficos que proporcionan seguridad en las comunicaciones a través de Internet. -- **URI y URL** – Un Identificador Uniforme de Recursos (URI) es una cadena de caracteres que se utiliza para identificar un nombre o un recurso web. Un Localizador Uniforme de Recursos (URL) se utiliza a menudo como referencia a un recurso. -- **Pruebas de Aceptación de Usuario (UAT)** – Tradicionalmente un entorno de pruebas que se comporta como el entorno de producción donde se realizan todas las pruebas de la aplicación antes de su puesta en marcha. -- **Verificador** – La persona o equipo que está revisando una aplicación usando los requisitos del MASVS de OWASP. -- **Lista Blanca** – Una lista de datos u operaciones permitidas, por ejemplo, una lista de caracteres que permiten realizar la validación de la entrada. -- **Certificado X.509** – Un certificado X.509 es un certificado digital que utiliza el estándar internacional de infraestructura de clave pública (PKI) X.509 ampliamente aceptado para verificar que una clave pública pertenece a la identidad de usuario, dispositivo o servicio contenida en el certificado. diff --git a/Document-es/0x91-Appendix-B_References.md b/Document-es/0x91-Appendix-B_References.md deleted file mode 100644 index f63b99f1b..000000000 --- a/Document-es/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Apéndice B: Referencias - -Los siguientes proyectos de OWASP serán probablemente de utilidad para los usuarios de este estándar: - -- Proyecto de Seguridad Móvil de OWASP - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- Guía de Pruebas de Seguridad Móvil OWASP - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- Top 10 de Riesgos Móviles de OWASP - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- Ingeniería Inversa y Prevención de Modificación de Código de OWASP - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -También los siguientes sitios web serán probablemente de utilidad para los usuarios de este estándar: - -- Enumeración de debilidades comunes de MITRE - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- Consejo de Normas de Seguridad PCI - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- Estándar de seguridad de datos PCI (DSS) v3.0 Requisitos y procedimientos de evaluación de la seguridad [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-es/CHANGELOG.md b/Document-es/CHANGELOG.md deleted file mode 100644 index d6cab14c2..000000000 --- a/Document-es/CHANGELOG.md +++ /dev/null @@ -1,97 +0,0 @@ -# Changelog - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 de marzo 2020 - Release Internacional - -Los siguientes cambios forman parte de la versión 1.2: - -- El MASVS ha sido traducido al chino simplificado. -- El título ha sido cambiado en la portada del MASVS. -- Todas las referencias CWE y Mobile Top 10 han sido eliminadas de la MSTG y han sido integradas a las referencias existentes en el MASVS. - -## V1.2-RC - 5 de octubre de 2019 - Pre-release - -Los siguientes cambios forman parte de la versión 1.2: - -- ¡Ya somos flagship! -- Requisitos MSTG-STORAGE-1 modificado para ser más extricto. -- Añadidos los requisitos MSTG-STORAGE-13, MSTG-STORAGE-14 y MSTG-STORAGE-15 centrados en la protección de datos. -- Actualizado el requisito MSTG-AUTH-11 para preservar información contextual. -- Actualizado el requisito MSTG-CODE-4 para cubrir más allá de la depuración. -- Añadido el requisito MSTG-PLATFORM-10 para incrementar la seguridad al usar WebViews. -- Añadido el requisito MSTG-AUTH-12 para recordar a los desarrolladores que deben de implementar medidas de autorización, especialmente en aplicaciones multi usuario. -- Descripción mejorada sobre como usar el MASVS dado una evaluación de riesgo. -- Añadida más descripción sobre contenidos de pago. -- Añadido el requisito MSTG-ARCH-11 incluyendo una política de divulgación responsable para aplicaciones MASVS-L2. -- Añadido el requisito MSTG-ARCH-12 informando a los desarrolladores que las correspondientes leyes internacionales de privacidad deberían de ser seguidas. -- Consolidado el estilo de referencias en la versión inglesa. -- Añadido el requisito MSTG-PLATFORM-11 para combatir el espionaje mediante teclados de terceros. -- Añadido el requisito MSTG-MSTG-RESILIENCE-13 para impedir el _eavesdropping_ en aplicaciones. - -## V1.1.4 - 4 de julio de 2019 - Summit edition - -Los siguientes cambios forman parte de la versión 1.1.4: - -- Todos los problemas de markdown arreglados. -- Versiones francesa y española actualizadas. -- Changelog traducido al chino (ZHTW) y al japonés. -- Verificación automática de sintáxis de markdown y accesibilidad de URLs. -- Categorías añadidas a cada requisito. Èstas serán usadas en futuras versiones de la MSTG para encontrar recomendaciones y test cases con más facilidad. -- Tamaño del repositorio reducido y Generated añadido al .gitignore. -- Añadidos Código de Conducta y Guía de Contribución. -- Plantilla para Pull-Requests añadida. -- Actualizada la sincronización del repositorio con el servicio de Gitbook hosting. -- Scripts de generación de XML/JSON/CSV actualizados para todas las traducciones. -- Prólogo traducido al chino (ZHTW). - -## V1.1.3 - 9 de enero de 2019 - Pequeñas correcciones - -Los siguientes cambios forman parte de la versión 1.1.3: - -- Requisito 7.1 corregido en la traducción al español. -- Nueva disposición de los traductores en los agradecimientos. - -## V1.1.2 - 3 de enero de 2018 - Patrocinio e internacionalización - -Los siguientes cambios forman parte de la versión 1.1.2: - -- Añadido agradecimiento a los compradores del libro electrónico (e-book). -- Link de "falta de autenticación" añadido y link de "autentificación rota" actualizado en V4. -- Requisitos 4.7 y 4.8 corregidos en la versión inglesa. -- ¡Primer release incluyendo internacionalización! - - Correcciones en la traducción al español. Ahora la traducción está sincronizada con la versión en inglés (1.1.2). - - Correcciones en la traducción al ruso. Ahora la traducción está sincronizada con la versión en inglés (1.1.2). - - ¡Corregido el primer release en chino (ZHTW), francés, alemán y japonés! -- Documento simplificado para facilitar la traducción. -- Añadidas instrucciones para poder hacer releases automáticos. - -## V1.1.0 - 14 de julio de 2018 - -Los siguientes cambios forman parte de la versión 1.1: - -- Requisito 2.6 "Se desactiva el portapapeles en los campos de texto donde se maneja información sensible." eliminado. -- Requisito 2.2 "No se debe almacenar información sensible fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema." añadido. -- Requisito 2.1 reescrito como "Las funcionalidades de almacenamiento de credenciales del sistema son utilizadas para almacenar la información sensible, como la información personal, credenciales del usuario y claves criptográficas." - -## V1.0 - 12 de enero de 2018 - -Los siguientes cambios forman parte de la versión 1.0: - -- Requisito 8.9 eliminado por similitud con el 8.12. -- Requisito 4.6 generalizado. -- Correcciones menores (errores ortográficos, etc.). diff --git a/Document-es/GLOSSARY.md b/Document-es/GLOSSARY.md deleted file mode 100644 index 90967c931..000000000 --- a/Document-es/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Apéndice A: Glosario - -## Aleatorización del Espacio de Direcciones (ASLR) - -Una técnica para hacer más difícil la explotación de errores de corrupción de memoria. - -## Seguridad de Aplicación - -La seguridad a nivel de aplicación se centra en el análisis de los componentes que componen la capa de aplicación del modelo de referencia de interconexión de sistemas abiertos (modelo OSI), en lugar de centrarse, por ejemplo, en el sistema operativo subyacente o las redes conectadas. - -## Verificación de la Seguridad de una Aplicación - -La evaluación técnica de una aplicación utilizando el OWASP MASVS. - -## Informe de la Verificación de la Seguridad de una Aplicación - -Un informe que documenta los resultados generales y el análisis detallado producido por el verificador para una aplicación particular. - -## Autenticación - -La verificación de la identidad alegada por el usuario de una aplicación. - -## Verificación Automatizada - -El uso de herramientas automatizadas (herramientas de análisis dinámico, estático o ambas) que utilizan firmas de vulnerabilidades para encontrar problemas. - -## Verificación de tipo Back-box - -Es un método de verificación de software que examina la funcionalidad de una aplicación sin tener en cuenta sus estructuras internas ni su funcionamiento. - -## Componente - -Una unidad de código autónoma, con un disco asociado e interfaces de red que se comunican con otros componentes. - -## Cross-Site Scripting (XSS) - -Una vulnerabilidad de seguridad que normalmente se encuentra en las aplicaciones web que permiten la inyección de scripts en el contenido del lado del cliente. - -## Módulo Criptográfico - -Hardware, software y/o firmware que implementa algoritmos criptográficos y/o genera claves criptográficas. - -## CWE - -CWE es una lista de debilidades comunes de seguridad de software desarrollada por la comunidad. Sirve como un lenguaje común, un instrumento de medición para las herramientas de seguridad de software, y como una línea base para la identificación de debilidades, mitigación y esfuerzos de prevención. - -## Pruebas Dinámicas de Seguridad de Aplicaciones (DAST) - -Las tecnologías de Pruebas Dinámicas de Seguridad de Aplicaciones (DAST, por sus siglas en inglés) están diseñadas para detectar indicios de vulnerabilidades de seguridad en una aplicación mientras se está ejecutando. - -## Verificaciones de Diseño - -La evaluación técnica de la seguridad de la arquitectura de una aplicación. - -## Verificación Dinámica - -El uso de herramientas automatizadas que utilizan firmas de vulnerabilidades para encontrar problemas durante la ejecución de una aplicación. - -## Identificador Único Global (GUID) - -Un número de referencia único utilizado como identificador en el software. - -## Hyper Text Transfer Protocol (HTTP) - -Un protocolo de aplicación para sistemas de información distribuidos y colaborativos. Es la base de la comunicación de datos para la World Wide Web. - -## Claves Grabadas (Hardcoded keys) - -Claves criptográficas que se encuentran almacenadas directamente en el dispositivo. - -## Comunicación Entre Procesos - -La comunicación entre procesos (IPC, por sus siglas en inglés) es un método mediante el cual un proceso se comunica con otro a través del kernel del dispositivo para coordinar sus actividades. - -## Validación de la Entrada - -La canonización y validación de las entradas de usuario no confiables. - -## JAVA Bytecode - -_Java bytecode_ es el conjunto de instrucciones de la máquina virtual Java (JVM). Cada _bytecode_ está compuesto por uno, o en algunos casos dos bytes que representan la instrucción (_opcode_), junto con cero o más bytes para pasar parámetros. - -## Código Malicioso - -Código introducido en una aplicación durante su desarrollo que es desconocido para el propietario de la aplicación y que elude la política de seguridad alegada por la misma. ¡No es lo mismo que malware, virus o gusano! - -## Malware - -Código ejecutable que se introduce en una aplicación durante el tiempo de ejecución sin el conocimiento del usuario o administrador de la misma. - -## Open Web Application Security Project (OWASP) - -OWASP es una comunidad abierta a nivel mundial y sin ánimo de lucro enfocada en mejorar la seguridad del software de aplicaciones. Nuestra misión es hacer que la seguridad de las aplicaciones sea "visible" para que las personas y las organizaciones puedan tomar decisiones informadas sobre los riesgos de seguridad de las aplicaciones. Ver: - -## Información de Identificación Personal (PII)** - -La información de identificación personal (PII, por sus siglas en inglés) es la información que se puede utilizar por sí sola o junto con otra información para identificar, contactar o localizar a una sola persona, o para identificar a un individuo en su contexto - -## Ejecutable de Posición Independiente (PIE) - -Es un ejecutable que, al ser cargado en memoria, se ejecuta correctamente independientemente de su dirección absoluta. - -## Infraestructura de Clave Pública (PKI) - -Una PKI es un acuerdo que vincula claves públicas con las identidades respectivas de las entidades. La vinculación se establece mediante un proceso de registro y expedición de certificados realizado por una autoridad de certificación (CA). - -## Pruebas Estáticas de Seguridad de Aplicaciones (SAST) - -Las pruebas estáticas de seguridad de aplicaciones (SAST) son un conjunto de tecnologías diseñadas para analizar el código fuente de la aplicación, el _bytecode_, los binarios del código y las condiciones del diseño para detectar indicios de vulnerabilidades de seguridad. Las soluciones SAST analizan una aplicación desde "dentro hacia fuera" en un estado reposo, i.e., cuando no se está ejecutando. - -## SDLC - -Ciclo de vida de desarrollo software. - -## Seguridad de la Arquitectura - -Una abstracción del diseño de una aplicación que identifica y describe dónde y cómo se utilizaran los controles de seguridad, además de la ubicación y sensibilidad de los datos tanto del usuario como de la aplicación. - -## Configuración de Seguridad - -La configuración en tiempo de ejecución de una aplicación que afecta a la forma en que se utilizan los controles de seguridad. - -## Control de Seguridad - -Una función o componente que realiza un chequeo de seguridad (por ejemplo, una verificación del control de acceso) o que cuando es invocado produce un evento de seguridad (por ejemplo, al generar un registro de auditoría). - -## Inyección SQL (SQLi) - -Una técnica de inyección de código utilizada para atacar aplicaciones basadas en datos, en la que se insertan instrucciones SQL maliciosas en un punto de entrada. - -## Autenticación SSO - -La Autenticación de inicio de sesión único (SSO, por sus siglas en inglés) se produce cuando un usuario inicia sesión en un cliente y luego se conecta desde otros servicios automáticamente, independientemente de la plataforma, tecnología o dominio que esté utilizando el usuario. Por ejemplo, un inicio de sesión en Google dará acceso automáticamente a los servicios de YouTube, Drive y Gmail. - -## Modelado de Amenazas - -Una técnica que consiste en desarrollar arquitecturas de seguridad cada vez más perfeccionadas para identificar agentes de amenazas, zonas de seguridad, controles de seguridad e importantes activos técnicos y empresariales. - -## Seguridad en la Capa de Transporte (TLS) - -Protocolos criptográficos que proporcionan seguridad en las comunicaciones a través de Internet. - -## URI y URL - -Un Identificador Uniforme de Recursos (URI) es una cadena de caracteres que se utiliza para identificar un nombre o un recurso web. Un Localizador Uniforme de Recursos (URL) se utiliza a menudo como referencia a un recurso. - -## Pruebas de Aceptación de Usuario (UAT) - -Tradicionalmente un entorno de pruebas que se comporta como el entorno de producción donde se realizan todas las pruebas de la aplicación antes de su puesta en marcha. - -## Verificador - -La persona o equipo que está revisando una aplicación usando los requerimientos del MASVS de OWASP. - -## Lista Blanca - -Una lista de datos u operaciones permitidas, por ejemplo, una lista de caracteres que permiten realizar la validación de la entrada. - -## Certificado X.509 - -Un certificado X.509 es un certificado digital que utiliza el estándar internacional de infraestructura de clave pública (PKI) X.509 ampliamente aceptado para verificar que una clave pública pertenece a la identidad de usuario, dispositivo o servicio contenida en el certificado. diff --git a/Document-es/SUMMARY.md b/Document-es/SUMMARY.md deleted file mode 100644 index 6b6d6594a..000000000 --- a/Document-es/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Tabla de contenido - -- [Registro de cambios](CHANGELOG.md) -- [Prólogo](0x01-Foreword.md) -- [Frontispicio](0x02-Frontispiece.md) -- [Usos del MASVS](0x03-Using_the_MASVS.md) -- [Evaluación y Certificación](0x04-Assessment_and_Certification.md) - -## Requerimientos de Seguridad - -- [V1: Requisitos de Arquitectura, Diseño y Modelado de Amenazas](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Requerimientos en el Almacenamiento de datos y la Privacidad](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Requerimientos de Criptografía](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Requerimientos de Autenticación y Manejo de Sesiones](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Requerimientos de Comunicación a través de la red](0x10-V5-Network_communication_requirements.md) -- [V6: Requerimientos de Interacción con la Plataforma](0x11-V6-Interaction_with_the_environment.md) -- [V7: Requerimientos de Calidad de Código y Configuración del Compilador](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Requerimientos de Resistencia ante la Ingeniería Inversa](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendices - -- [Apéndice A: Glosario](GLOSSARY.md) -- [Apéndice B: Referencias](0x91-Appendix-B_References.md) diff --git a/Document-es/book.json b/Document-es/book.json deleted file mode 100644 index 079e0627a..000000000 --- a/Document-es/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "es" -} diff --git a/Document-es/images/CC-license.png b/Document-es/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-es/images/CC-license.png and /dev/null differ diff --git a/Document-es/images/MASVS-levels.png b/Document-es/images/MASVS-levels.png deleted file mode 100644 index b083ba829..000000000 Binary files a/Document-es/images/MASVS-levels.png and /dev/null differ diff --git a/Document-es/images/OWASP_logo.png b/Document-es/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-es/images/OWASP_logo.png and /dev/null differ diff --git a/Document-es/images/license.png b/Document-es/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-es/images/license.png and /dev/null differ diff --git a/Document-es/images/masvs-levels-new.jpg b/Document-es/images/masvs-levels-new.jpg deleted file mode 100644 index 7285100ec..000000000 Binary files a/Document-es/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-es/images/masvs-mini-cover.jpg b/Document-es/images/masvs-mini-cover.jpg deleted file mode 100644 index 29aecc0f3..000000000 Binary files a/Document-es/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-es/images/masvs-mini-cover.png b/Document-es/images/masvs-mini-cover.png deleted file mode 100644 index 70cda6db1..000000000 Binary files a/Document-es/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-es/metadata.md b/Document-es/metadata.md deleted file mode 100644 index 3c8d70998..000000000 --- a/Document-es/metadata.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -# This overide the main Document/metadata.md file -lang: 'es' -languagetext: '(Spanish Translation)' - -# toc-title is translated when `lang` is correctly defined -#toc-title: 'Tabla de Contenidos' ---- diff --git a/Document-fa/0x01-Foreword.md b/Document-fa/0x01-Foreword.md deleted file mode 100644 index ab8b14fb2..000000000 --- a/Document-fa/0x01-Foreword.md +++ /dev/null @@ -1,30 +0,0 @@ -
- -# پیشگفتار - -انقلاب‌های فناورانه می‌توانند به‌سرعت اتفاق بیفتند. کمتر از یک دهه قبل، گوشی‌های هوشمند دستگاه‌های سنگین و عجیب با صفحه‌کلیدهای کوچک و ابزاری گران قیمت برای کاربران تجاری با دانش بالا بودند. امروزه، گوشی‌های هوشمند یک بخش ضروری از زندگی ما را تشکیل می‌دهند. ما برای اطلاعات، مسیریابی و ارتباطات به آنها وابسته شده‌ایم و آنها، هم در زندگی تجاری و هم در زندگی اجتماعی ما حاضر هستند. - -هر تکنولوژی جدید خطرات امنیتی جدیدی را به‌وجود می‌آورد و یکی از چالش‌های عمده‌ای که صنعت امنیت با آن مواجه است، وفق یافتن با این تغییرات است. همواره جبهه‌ی دفاعی چند قدم عقب‌تر است. برای مثال، واکنش پیش‌فرض خیلی از افراد، به‌کارگیری شیوه‌های قدیمی در انجام کارها است: گوشی‌های هوشمند همانند کامپیوترهای کوچک و برنامه‌های کاربردی موبایل دقیقا همانند نرم‌افزارهای کلاسیک هستند، بنابراین به‌طور حتم باید بتوان نتیجه گرفت که الزامات امنیتی گوشی‌های هوشمند و کامپیوترها یکسان است. اما این فرضیه درست نیست. سیستم‌عامل‌های گوشی‌های هوشمند و کامپیوترهای رومیزی با یکدیگر متفاوت هستند و برنامه‌های کاربردی موبایل نیز با برنامه‌های تحت وب تفاوت دارند. برای مثال، شیوه‌ی کلاسیک مبتنی بر امضاء، کاربردی جهت پویش ویروس در سیستم‌عامل‌های نوین موبایل ندارد؛ این شیوه نه تنها با مدل توزیع شده‌ی برنامه‌ی کاربردی موبایل ناسازگار است، بلکه به‌دلیل محدودیت‌های sandboxing، از نظر فنی نیز غیرممکن می‌باشد. همچنین بعضی از انواع آسیب‌پذیری مانند سرریز بافر و مشکلات XSS، مطابقت کم‌تری با برنامه‌های عادی حوزه‌ی موبایل دارند و بیش‌تر در برنامه‌های کامپیوتری و برنامه‌های تحت وب موضوعیت پیدا می‌کنند (البته با در نظر گرفتن استثنائات). - -با گذشت زمان، صنعت ما درک بهتری از مخاطرات و تهدیدات در حوزه‌ی موبایل پیدا کرده است. همانطور که مشخص است، موضوع امنیت موبایل، تماما در‌خصوص محافظت از داده است: برنامه‌ها، اطلاعات خصوصی ما شامل تصاویر، فایل‌های ضبط‌شده‌ی صوتی، یادداشت‌ها، اطلاعات حساب، اطلاعات تجاری، موقعیت مکانی و بسیاری چیزهای دیگر را ذخیره می‌کنند. آنها همانند کاربرانی که ما را جهت انجام خدماتی که روزانه استفاده می‌کنیم به سرویس‌ها متصل می‌کنند، و همانند مراکز ارتباطاتی که همه‌ی پیام‌های مبادله شده ما با دیگران را پردازش می‌کنند، عمل می‌نمایند. برای دسترسی بدون فیلتر به زندگی شخصی یک فرد فقط کافی است گوشی هوشمند او را تحت کنترل بگیرید. وقتی در نظر داشته باشیم که دستگاه‌های تلفن همراه به‌راحتی گم شده و یا سرقت می‌شوند و تعداد بدافزارهای موبایل رو به افزایش هستند، نیاز به حفاظت از داده‌ها بیشتر مشخص می‌شود. - -بنابراین یک استاندارد امنیتی برای برنامه‌های کاربردی موبایل، باید بر چگونگی مدیریت، ذخیره و حفاظت از اطلاعات حساس توسط برنامه‌های موبایل تمرکز کند. اگرچه سیستم‌عامل‌های مدرن موبایل مانند iOS و اندروید، APIهای خوبی برای ذخیره امن داده‌ها و ارتباطات امن پیشنهاد داده‌اند، اما برای موثر واقع‌شدن، APIها باید به‌طور صحیح پیاده‌سازی و استفاده شوند. ذخیره‌سازی داده، ارتباطات بین ‌برنامه‌ای، استفاده مناسب از API‌های رمزنگاری و ارتباطات امن شبکه تنها بخشی از جنبه‌هایی هستند که نیاز به توجه دقیق دارند. - -پرسش مهمی که به موافقت همگانی در صنعت نیاز دارد این است که در حفاظت از محرمانگی و صحت داده تا کجا باید پیش رفت. به‌عنوان مثال، اغلب ما موافق هستیم که یک برنامه‌ی کاربردی موبایل باید گواهی سرور را در مبادله TLS اعتبارسنجی نماید. اما در مورد سازوکار امنیتی SSL certificate pinning چطور؟ آیا عدم استفاده از آن منجر به بروز آسیب‌پذیری می‌شود؟ آیا استفاده از این سازوکار باید در برنامه‌هایی که داده‌های حساس مدیریت می‌کنند الزام گردد؟ یا ممکن است حتی نتیجه‌ی معکوس دهد؟ آیا نیاز داریم تا داده‌های ذخیره‌شده در پایگاه‌های داده‌ی SQLite را حتی اگر سیستم‌عامل، برنامه را محصور کند، رمز کنیم؟ چیزی که برای یک برنامه مناسب است ممکن است برای برنامه‌ای دیگر ناکارآمد باشد. MASVS تلاشی است برای استانداردسازی این الزامات با بهره‌گیری از سطوح وارسی‌ متناسب با سناریوهای تهدیدات متنوع. - -علاوه‌بر این، ظهور بدافزار root و ابزارهای مدیریت از راه دور باعث ایجاد آگاهی در مورد این واقعیت شده است که خود سیستم‌عامل‌های موبایل دارای رخنه‌های امنیتی قابل ‌بهره‌برداری هستند، درنتیجه استراتژی‌های کانتینریزاسیون برای محافظت بیشتر از داده‌های حساس و جلوگیری از دست‌کاری در سمت کاربر، به‌صورت فزاینده‌ای مورد استفاده قرار می‌گیرند. اینجاست که همه چیز پیچیده می‌شود. ویژگی‌های امنیتی مربوط به سخت‌افزار و راهکارهای کانتینریزاسیون در سطح سیستم‌عامل مانند Android for Work و Samsung Knox وجود دارند اما به‌طور یکنواخت برای دستگاه‌های مختلف در دسترس نیستند. یک راهکار موقت، امکان پیاده‌سازی معیارهای محافظتی مبتنی بر نرم‌افزار است اما متاسفانه هیچ استاندارد یا فرآیند تستی برای وارسی چنین محافظت‌هایی وجود ندارد. - -نتیجه آنکه، گزارشات آزمون امنیت برنامه‌ی کاربردی موبایل همه‌جا قابل‌دسترس هستند؛ برای مثال برخی آزمونگرها عدم مبهم‌سازی(Obfuscation) کد یا تشخیص root بودن دستگاه در یک برنامه‌ی کاربردی اندروید را به‌عنوان «حفره‌ی امنیتی» گزارش می‌کنند. از طرف دیگر، معیارهای دیگری مانند رمزنگاری رشته، تشخیص debugger یا مبهم‌سازی(Obfuscation) جریان کنترل برنامه، اجباری در نظر گرفته نمی‌شوند. از آنجایی که تاب‌آوری یک مفهوم صفر و یکی نیست و این نوع دیدگاه به مسائل نیز منطقی نمی‌باشد: این وابسته به تهدیدات مشخص در سمت کاربر است که باید با آن مقابله شود. محافظت‌های نرم‌افزاری بی‌فایده نیستند اما نهایتا ممکن است دور زده شوند، درنتیجه هیچ‌گاه نباید به‌عنوان جایگزینی برای کنترل‌های امنیتی استفاده شوند. - -هدف کلی استاندارد MASVS، ارائه‌ی مبانی اولیه برای امنیت برنامه‌ی کاربردی موبایل (استاندارد MASVS-سطح یک)، همچنین دربرگیرنده‌ی معیارهای دفاع در عمق (استاندارد MASVS-سطح دو) و محافظت‌هایی در برابر تهدیدات سمت کاربر (استاندارد MASVS-مهندسی معکوس) است. MASVS به‌دنبال دستیابی به موارد زیر است: - -- فراهم آوردن الزامات برای معمارهای نرم‌افزار و توسعه‌دهندگانی که به‌دنبال توسعه‌ی امن برنامه‌های کاربردی موبایل هستند؛ -- پیشنهاد یک استاندارد صنعتی که بتواند در بازبینی‌های امنیتی برنامه‌ی کاربردی موبایل، مورد آزمون قرار گیرد؛ -- تبیین نقش سازوکارهای محافظتی نرم‌افزار در امنیت برنامه‌های کاربردی موبایل و تهیه‌ی الزامات به‌منظور وارسی میزان موثر بودن آنها؛ -- ارائه‌ی توصیه‌های ویژه، متناظر با هر یک از سطوح امنیتی برای کاربردهای گوناگون. - -می‌دانیم که دستیابی به رضایت 100٪ در صنعت غیرممکن است. با این‌وجود امیدواریم که استاندارد MASVS در فراهم آوردن دستورالعمل راهنما در همه‌ی مراحل توسعه و آزمون برنامه‌ی کاربردی موبایل مفید واقع شود. MASVS به‌عنوان یک استاندارد متن‌باز، در طول زمان تکامل پیدا خواهد کرد و در همین راستا از هر پیشنهاد و مشارکتی استقبال می‌کنیم. - -توسط Bernhard Mueller - -
diff --git a/Document-fa/0x02-Frontispiece.md b/Document-fa/0x02-Frontispiece.md deleted file mode 100644 index 42994876d..000000000 --- a/Document-fa/0x02-Frontispiece.md +++ /dev/null @@ -1,59 +0,0 @@ -
- -# درباره‌ی استاندارد - -![OWASP Logo](images/OWASP_logo.png) - -به استاندارد وارسی امنیت برنامه‌ی کاربردی موبایل (MASVS) نسخه 1.1 خوش آمدید. MASVS یک تلاش جمعی برای برپاسازی چارچوبی از الزامات امنیتی مربوط به طراحی، توسعه و آزمون برنامه‌های کاربردی امن موبایل بر روی iOS و اندروید است. - -MASVS نقطه اوج یک تلاش جمعی و بازخورد صنعت است. ما انتظار داریم که این استاندارد در طی زمان تکامل پیدا کرده و از بازخورد اجتماع استقبال می‌کنیم. - -بهترین راه برای ارتباط با ما از طریق کانال Slack پروژه موبایل OWASP است: - . - -حساب‌های کاربری می توانند در این آدرس ایجاد شوند: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## حق تکثیر و مجوز - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -حق تکثیر © 2021 توسط بنیاد OWASP محفوظ است. این اثر تحت یک مجوز [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/) منتشر می‌شود. جهت هرگونه استفاده مجدد یا توزیع، شما باید شرایط مجوز این اثر را برای دیگران روشن سازید. - - - -## تشکر و قدردانی - -| رهبر پروژه | نویسنده اصلی | مشارکت کنندگان و ویراستاران -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| زبان | مترجمان و ویراستاران | -| --------------- | ------------------------------------------------------------ | -| چینی (سنتی) | Peter Chi, Lex Chien, Henry Hu, Leo Wang | -| چینی (ساده‌شده) | Bob Peng, Harold Zang, Jack S | -| فارسی | Ramin Atefinia, Hamed Salimian, Bardiya Akbari, Dorna Azhirak, Mahsa Omidvar, Alireza Mazhari, Mehran Seifalinia, Milad Khoshdel | -| فرانسوی | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| آلمانی | Rocco Gränitz, Sven Schleier (Review) | -| هندی | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| ژاپنی | Koki Takeyama, Riotaro Okada (Review) | -| کره‌ای | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| روسی | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| اسپانیایی | Martin Marsicano, Carlos Holguera | -| پرتغالی (برزیلی) | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| پرتغالی | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| ترکی | Anıl Baş, Haktan Emik | -| یونانی | Panagiotis Yialouris | - - این سند به‌عنوان یک fork از استاندارد وارسی برنامه‌ی کاربردی موبایل نوشته شده توسط Jim Manico آغاز شده است. - -## حامیان - -با اینکه هر دو استاندارد MASVS و MASTG به‌طور داوطلبانه توسط جامعه تولید و نگهداری می‌شوند، اما گاهی اوقات به اندکی کمک خارجی نیاز است. بنابراین، از حامیان مالی‌مان بخاطر فراهم آوردن بودجه برای استخدام ویراستارهای فنی تشکر می‌کنیم. توجه داشته باشید که حمایت مالی آنان محتوای استاندارد MASVS یا MASTG را تحت تأثیر قرار نمی‌دهد. بسته‌های حمایت مالی در [OWASP Project Wiki]( "OWASP Mobile Application Security Testing Guide Sponsorship Packages") شرح داده‌شده‌اند. - - - -مایلیم از تمام کسانی که کتاب را از [Leanpub](https://leanpub.com/mobile-security-testing-guide) خریداری کرده و ما را حمایت کردند تشکر و قدردانی نماییم. - -
diff --git a/Document-fa/0x03-Using_the_MASVS.md b/Document-fa/0x03-Using_the_MASVS.md deleted file mode 100644 index 6d20984df..000000000 --- a/Document-fa/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,90 +0,0 @@ -
- -# استاندارد وارسی امنیت برنامه‌ی کاربردی موبایل - -از استاندارد MASVS می‌توان برای ایجاد سطحی از اطمینان در امنیت برنامه‌های کاربردی موبایل استفاده نمود. الزامات با در نظر گرفتن رسیدن به اهداف زیر توسعه داده شده‌اند: - -- استفاده به‌عنوان معیار اندازه‌گیری - به‌منظور ارائه‌ی استاندارد امنیتی که بوسیله‌ی آن برنامه‌های کاربردی موجود موبایل بتوانند توسط توسعه‌دهندگان و مالکان آن‌ها مقایسه شوند؛ -- استفاده به‌عنوان راهنما - به‌منطور ارائه‌ی راهنمایی در طول تمام مراحل توسعه و تست برنامه‌ی کاربردی موبایل؛ -- قابل استفاده بودن در مدت تهیه - به‌منظور ارائه‌ی مبنایی برای وارسی امنیت برنامه‌ی کاربردی موبایل. - -## مدل AppSec موبایل - -استاندارد MASVS دو سطح وارسی امنیت (MASVS-L1 و MASVS-L2) را در کنار مجموعه‌ای از الزامات تاب‌آوری مهندسی معکوس (MASVS-R)، تعریف می‌کند. MASVS-L1 شامل الزامات کلی امنیتی است که برای همه‌ی برنامه‌های کاربردی موبایل توصیه شده‌اند، درحالی‌که MASVS-L2 باید برای برنامه‌هایی که با داده‌های بسیار حساس سر و کار دارند اعمال شود. MASVS-R کنترل‌های محافظتی بیشتری را نیز پوشش می‌دهد و در صورتی می‌تواند اعمال شود که هدف از طراحی، جلوگیری از تهدیدات سمت کاربر باشد. - -نتیجه انجام الزامات موجود در MASVS-L1 یک برنامه امن می‌شود که بهترین رویه‌های امنیتی را دنبال می‌کند و از آسیب‌پذیری‌های رایج ضرری نمی‌بیند. MASVS-L2 نیز کنترل‌های دفاع در عمق بیشتری از قبیل SSL pinning را می‌افزاید که نتیجه آن برنامه ای مقاوم در برابر حملات پیچیده می‌باشد - با این فرض که کنترل‌های امنیتی سیستم‌عامل موبایل دست‌نخورده باشد و کاربر نهایی به‌عنوان دشمنی بالقوه در نظر گرفته نشده باشد. انجام تمامی الزامات محافظتی در MASVS-R و یا زیرمجموعه‌هایی از آن، به جلوگیری از تهدیدات خاص سمت کاربر، درجایی که کاربر نهایی مخرب یا سیستم‌عامل موبایل در معرض خطر باشد، کمک می‌کند. - -**الف: اگرچه ما پیاده‌سازی کنترل‌های موجود در MASVS-L1 را در هر برنامه‌ای توصیه می‌کنیم، اما پیاده‌سازی کردن یا نکردن آن در نهایت باید یک تصمیم مخاطره محور باشد که توسط صاحبان کسب‌وکار گرفته می‌شود.** - -**ب: توجه داشته باشید که کنترل‌های محافظت نرم‌افزار که در MASVS-R فهرست شده‌اند و در راهنمای آزمون امنیت موبایل OWASP شرح داده‌شده‌اند، در نهایت می‌توانند دور زده شوند و هیچ‌گاه نباید به‌عنوان جایگزینی برای کنترل‌های امنیتی، مورداستفاده قرار گیرند. در عوض، هدف آن افزودن کنترل‌های محافظتی تهدیدات خاص به برنامه‌های کاربردی است که الزامات استاندارد MASVS در MASVS-L1 یا MASVS-L2 را نیز انجام می‌دهد.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### ساختار سند - -بخش نخست استاندارد MASVS شامل توضیحاتی در خصوص مدل امنیت و سطوح وارسی در دسترس می‌باشد، که با توصیه‌هایی در خصوص نحوه‌ی استفاده عملی از استاندارد همراه شده است. جزئیات الزامات امنیتی، به همراه نگاشت آنها به سطوح وارسی، در بخش دوم فهرست شده‌اند. الزامات ها بر اساس اهداف/چارچوب فنی به هشت دسته (V1 تا V8) طبقه‌بندی‌شده‌اند. نام‌گذاری زیر در کل استاندارد MASVS و MASTG استفاده شده است. - -- *طبقه‌بندی الزامات:* MASVS-Vx، به‌عنوان‌مثال MASVS-V2: -ذخیره‌سازی داده و حریم خصوصی -- *الزام:* MASVS-Vx.y، به‌عنوان‌مثال MASVS-V2.2: "هیچ اطلاعات حساسی در لاگ‌های برنامه نوشته‌ نشده است." - -### جزئیات سطوح وارسی - -#### MASVS-L1: امنیت استاندارد - -برنامه‌ی کاربردی موبایلی که استاندارد MASVS-L1 را کسب می‌کند به بهترین رویه‌های امنیتی برنامه‌ی کاربردی موبایل پایبند می‌شود. این موضوع، الزامات پایه‌ای در خصوص کیفیت کد، مدیریت داده‌های حساس و تعامل با محیط موبایل را محقق می‌کند. به‌منظور وارسی کنترل‌های امنیتی باید یک فرآیند آزمون طی شود. این سطح برای همه‌ی برنامه‌های کاربردی موبایل مناسب است. - -#### MASVS-L2: دفاع در عمق - -MASVS-L2 کنترل‌های امنیتی پیشرفته‌ای را ارائه می‌دهد که فراتر از الزامات استاندارد است. برای تحقق الزامات MASVS-L2 باید یک مدل تهدید وجود داشته باشد و امنیت بایستی بخش جدایی‌ناپذیری از معماری و طراحی برنامه کاربردی موبایل باشد. بر اساس مدل تهدید، باید موارد کنترلی مناسبی در MASVS-L2 انتخاب و با موفقیت پیاده‌سازی می‌شدند. این سطح برای برنامه‌های کاربردی که داده‌های بسیار حساس را مدیریت می‌کنند، مانند برنامه‌های بانکی موبایل مناسب است. - -#### MASVS-R: تاب‌آوری در برابر مهندسی معکوس و دست‌کاری - -برنامه‌ی کاربردی دارای فناوری امنیتی پیشرفته و به روز است، همچنین در برابر حملات خاص و شناخته‌شده‌ی سمت کاربر مانند دست‌کاری، تعدیل یا مهندسی معکوس برای استخراج کد یا داده‌های حساس، منعطف است. چنین برنامه‌ای از ویژگی‌های امنیتی سخت‌افزاری یا تکنیک‌های قوی و تایید شده‌ی محافظت از نرم‌افزار بهره می‌گیرد. MASVS-R در برنامه‌های کاربردی که داده‌های بسیار حساس را مدیریت می‌کنند، کاربرد دارد و می‌تواند به‌عنوان وسیله‌ای برای محافظت از مالکیت معنوی یا اثبات دست‌کاری یک برنامه‌ی کاربردی، مورد استفاده قرار گیرد. - -### کاربرد توصیه‌شده - -برنامه‌های کاربردی را می‌توان بر اساس ارزیابی مخاطره قبلی و سطح کلی امنیت موردنیاز، مطابق با MASVS سطح L1 یا L2 وارسی نمود. L1 برای همه‌ی برنامه‌های موبایل قابل‌اجرا است، درحالی‌که L2 به‌طورکلی برای برنامه‌های کاربردی‌ای توصیه می‌شود که داده یا کاربرد حساس‌تری را مدیریت می‌نمایند. MASVS-R (یا بخش‌هایی از آن) را می‌توان برای اثبات تاب‌آوری در برابر تهدیدات خاص، مانند بسته‌بندی مجدد یا استخراج داده‌های حساس و *افزون بر آن* در وارسی امنیتی مناسب استفاده نمود. - -به‌طور خلاصه، انواع وارسی‌های موجود، به‌شرح زیر می‌باشند: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -ترکیب‌های مختلف، درجه‌های متفاوتی از امنیت و تاب‌آوری را منعکس می‌کنند. هدف آن است که امکان تاب‌آوری فراهم گردد: برای مثال، یک بازی موبایل ممکن است اضافه کردن کنترل‌های امنیتی MASVS-L2، مانند احراز هویت دو عاملی را به دلایل مرتبط با کاربردپذیری تضمین نکند، اما نیاز تجاری شدیدی برای جلوگیری از دست‌کاری داشته‌باشد. - -#### کدام نوع وارسی باید انتخاب گردد - -پیاده‌سازی الزامات MASVS L2 باعث افزایش امنیت می‌شود، درعین‌حال که هزینه‌ی توسعه را افزایش می‌دهد و به‌طور بالقوه تجربه‌ی کاربر نهایی را بدتر می‌کند (این همان فرآیند قدیمی است که در آن چیزی را به ازای چیز دیگری از دست می‌دهیم). سطح دو به‌طورکلی زمانی باید برای برنامه‌های کاربردی به‌کار گرفته شود که موازنه‌ی بین مخاطره و هزینه منطقی باشد (به‌عنوان‌مثال، ضرر بالقوه ناشی از به‌خطر انداختن محرمانگی یا یکپارچگی بالاتر از هزینه‌ی ایجادشده به‌واسطه‌ی کنترل‌های امنیتی اضافی است). ارزیابی مخاطره باید نخستین گام پیش از به‌کارگیری استاندارد MASVS باشد. - -##### مثال‌ها - -###### MASVS-L1 - -- همه‌ی برنامه‌های کاربردی موبایل. MASVS-L1 بهترین رویه‌های موجود که تاثیری منطقی بر هزینه‌ی توسعه و تجربه کاربری را به همراه دارد، فهرست می‌کند. الزامات موجود در MASVS-L1 را برای هر برنامه‌ای که واجد شرایط سطوح بالاتر نیست، اعمال نمایید. - - - -###### MASVS-L2 - -- صنعت خدمات بهداشت و درمان: برنامه‌های موبایل که اطلاعات شخصی قابل‌شناسایی را ذخیره می‌نمایند، می‌توانند در سرقت هویت، پرداخت‌های جعلی یا انواع طرح‌های کلاه‌برداری مورداستفاده قرار گیرند. در بخش خدمات بهداشت و درمان ایالات‌متحده، ملاحظات قانونی مطلوب، شامل قانون انتقال و پاسخ‌گویی الکترونیک بیمه‌ی سلامت (HIPAA)، حریم خصوصی، امنیت، قوانین اعلان رخنه و قانون ایمنی بیمار است. - -- صنعت مالی: برنامه‌های کاربردی که دسترسی به اطلاعات بسیار حساس مانند شماره‌ی کارت‌های اعتباری و اطلاعات شخصی دارند و یا به کاربر اجازه‌ی انتقال وجه می‌دهند. این برنامه‌های کاربردی، کنترل‌های امنیتی بیشتری را برای جلوگیری از کلاه‌برداری ضمانت می‌کنند. برنامه‌های مالی باید مطابقت با استاندارد امنیت داده‌ی صنعت پرداخت کارتی (PCI DSS)، قانون Gramm Leech Bliley و قانون Sarbanes-Oxley (SOX) را تضمین کنند. - -###### MASVS L1+R - -- برنامه‌های کاربردی موبایل که در آن‌ها حفاظت از مالکیت معنوی (IP) یک هدف تجاری است. کنترل‌های تاب‌آوری فهرست شده در MASVS-R می‌توانند برای دشوار نمودن دستیابی به کد منبع اصلی و جلوگیری از دست‌کاری یا کرک شدن استفاده شوند. - -- صنعت بازی: بازی‌هایی با نیاز ضروری به مقابله با تعدیل و تقلب، همانند بازی‌های آنلاین رقابتی. تقلب مسئله‌ی مهمی در بازی‌های آنلاین است چراکه تعداد زیاد متقلبان منجر به نارضایتی بازیکنان دیگر می‌شود و در نهایت می‌تواند موجب شکست یک بازی گردد. MASVS-R کنترل‌های پایه‌ای ضد دست‌کاری را فراهم می‌آورد که به دشوار سازی فرآیند تقلب کمک می‌کند و افزایش تلاش متقلبان را به‌همراه دارد. - -###### MASVS L2+R - -- صنعت مالی: برنامه‌های کاربردی بانکداری آنلاین که به کاربر امکان انتقال وجوه را می‌دهند، محیطی هستند که در آن‌ها روش‌هایی همچون تزریق کد و انجام فرآیند بانکی با استفاده از دستگاه‌های آلوده شده، مخاطره آمیز است. در این مورد، کنترل‌های موجود در MASVS-R می‌توانند به‌عنوان مانعی برای دست‌کاری و به دنبال آن افزایش فشار بر روی سازندگان بدافزار، به‌کار گرفته شوند. - -- همه‌ی برنامه‌های موبایل که با توجه به طراحی‌شان، نیاز به ذخیره‌ی داده‌های حساس در دستگاه همراه دارند و درعین‌حال باید از طیف گسترده‌ای از دستگاه‌ها و نسخه‌های سیستم‌عامل پشتیبانی کنند. در این حالت، می‌توان از کنترل‌های تاب‌آوری به‌عنوان یک تکنیک دفاع در عمق برای دشوار نمودن تلاش مهاجمانی استفاده نمود که قصد استخراج داده‌های حساس را دارند. - -- برنامه‌هایی که دارای خریدهای درون برنامه‌ای هستند باید به‌طور ایده‌آل از کنترل‌های سمت سرور و MASVS-L2 برای محافظت از محتوای پرداخت استفاده نمایند. اما مواردی ممکن است وجود داشته باشند که امکان محافظت از سمت سرور وجود نداشته باشد. در آن موارد، کنترل‌های استاندارد MASVS-R باید به‌منظور دشوار سازی مهندسی معکوس و دست‌کاری برنامه اعمال شوند. - -
diff --git a/Document-fa/0x04-Assessment_and_Certification.md b/Document-fa/0x04-Assessment_and_Certification.md deleted file mode 100644 index 45194b43c..000000000 --- a/Document-fa/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,53 +0,0 @@ -
- -# ارزیابی و گواهی - -## دیدگاه OWASP در مورد گواهینامه‌های استاندارد MASVS و نمادهای اعتماد الکترونیکی - -OWASP، به‌عنوان یک سازمان غیرانتفاعی بی‌طرف، هیچ فروشنده، ممیز یا نرم‌افزاری را تأیید نمی‌نماید. - -کلیه‌ی دعاوی ضمانتی، نمادهای اعتماد الکترونیکی یا گواهینامه‌ها به‌طور رسمی موردبررسی، ثبت یا تأیید OWASP قرار نگرفته‌اند، بنابراین یک سازمان با اتکا بر چنین دیدگاهی بایستی نسبت به اعتماد به هر شخص ثالث یا هر نماد اعتماد الکترونیکی مدعی ارائه‌ی گواهینامه‌ی (M)ASVS هوشیار باشد. - -این موضوع نباید سازمان‌ها را از ارائه‌ی چنین خدمات ضمانتی‌ای مادامی‌که ادعای ارائه‌ی گواهینامۀ رسمی OWASP را نمی‌کنند، بازدارد. - -## راهنمای صدور گواهینامه برای برنامه‌های کاربردی موبایل - -روش توصیه‌شده به‌منظور وارسی انطباق یک برنامه‌ی کاربردی موبایل با استاندارد MASVS، انجام بازبینی به شیوه‌ی "کتاب‌باز" است، به این معنی که به آزمونگرها اجازه‌ی دسترسی به منابع کلیدی از جمله معماران و توسعه‌دهندگان برنامه‌ی کاربردی، مستندات پروژه، کد منبع و دسترسی تأیید شده به پایانه شامل دسترسی به حداقل یک حساب کاربری برای هر نقش، داده می‌شود. - -لازم به ذکر است که استاندارد MASVS تنها امنیت (سمت کاربر) برنامه‌ی کاربردی موبایل و ارتباطات شبکه‌ای بین برنامه‌ی کاربردی و پایانه‌های راه دور، همچنین تعداد کمی از الزامات اولیه و کلی مربوط به احراز هویت کاربر و مدیریت نشست را پوشش می‌دهد. این استاندارد شامل الزامات مشخصی برای سرویس‌های از راه دور (مثلاً سرویس‌های وب) مربوط به برنامه‌ی کاربردی می‌باشد، به‌طوری‌که مجموعه‌ی محدودی از الزامات کلی مربوط به مدیریت نشست و احراز هویت را در برمی‌گیرد. بااین‌حال، بخش V1 استاندارد MASVS مشخص می‌نماید که خدمات از راه دور، باید تحت پوشش مدل تهدید کلی قرار بگیرند و با استانداردهای مناسبی همچون OWASP ASVS وارسی شوند. - -سازمان صادرکننده‌ی گواهینامه باید در هر گزارش، دامنه‌ی وارسی (به‌ویژه اگر مؤلفه‌ی کلیدی خارج از محدوده باشد) و خلاصه‌ای از یافته‌های وارسی شامل آزمون‌های موفق و ناموفق، به همراه راه‌حل‌های روشن در مورد چگونگی برطرف کردن آزمون‌های ناموفق را ارائه دهد. تهیه و نگهداری اوراق کاری حاوی جزئیات، تصاویر ضبط‌شده یا فیلم‌ها، قطعه کدهای بهره‌برداری مطمئن و قابل تکرار از آسیب‌پذیری، سوابق الکترونیکی آزمون مانند لاگ‌های شنود پروکسی و یادداشت‌های مربوطه مانند لیست پاک‌سازی، رویه‌ی استاندارد در صنعت شناخته می‌شود. اجرای یک ابزار و گزارش نقص‌ها به‌تنهایی کافی نیست؛ این امر شواهد کافی در مورد اینکه همه‌ی آسیب‌های در سطح صدور گواهینامه آزمایش شده‌اند و یا اینکه آیا این عمل به‌درستی انجام شده است، ارائه نمی‌دهد. در صورت بروز اختلاف، باید شواهد حمایتی کافی وجود داشته باشد تا مورد آزمایش قرار گرفتن هر الزام وارسی شده را اثبات نماید. - - - -### استفاده از راهنمای آزمون امنیت موبایل OWASP (استاندارد MASTG) - -استاندارد OWASP MASTG دستورالعملی برای آزمون امنیت برنامه‌های کاربردی موبایل است. این استاندارد فرآیندهای فنی را به‌منظور وارسی الزامات فهرست شده در استاندارد MASVS شرح می‌دهد. استاندارد MASTG شامل فهرستی از موارد آزمون است که هرکدام به یک الزام در استاندارد MASVS نگاشت شده‌اند. الزامات استاندارد MASVS، سطح بالا و کلی هستند درحالی‌که استاندارد MASTG بر پایه‌ی هر سیستم‌عامل موبایل، توصیه‌ها و فرآیندهای آزمون را به‌طور عمیق ارائه می‌دهد. - -### نقش ابزارهای خودکار آزمون امنیتی - -استفاده از پویشگرهای کد منبع و ابزارهای آزمون جعبه سیاه برای افزایش کارایی در هر زمان ممکنی توصیه می‌شود. با این حال، امکان وارسی الزامات استاندارد MASVS با استفاده از ابزارهای خودکار، به‌تنهایی امکان‌پذیر نیست. هر برنامه‌ی کاربردی موبایل متفاوت است و درک معماری کلی، منطق تجاری و مشکلات فنی تکنولوژی‌ها و فریمورک‌های استفاده‌شده در آن، یک الزام ضروری برای وارسی امنیت برنامۀ کاربردی است. - -## سایر کاربردها - -### به‌عنوان راهنمای تفصیلی معماری امنیتی - -یکی از کاربردهای رایج استاندارد وارسی امنیت برنامه‌ی کاربردی موبایل، فراهم آوردن منبعی برای معماران امنیت است. دو چارچوب مهم معماری امنیت، SABSA یا TOGAF، بسیاری از اطلاعاتی که برای تکمیل بازبینی‌های معماری امنیت برنامه‌های کاربردی موبایل ضروری است را در خود جای نداده‌اند. استاندارد MASVS می‌تواند برای پر کردن این‌گونه خلاءها مورد استفاده قرار گیرد و به معماران امنیت این اجازه را بدهد تا کنترل‌های بهتری را نسبت به آسیب‌های رایج برنامه‌های کاربردی موبایل اتخاذ نمایند. - -### به‌عنوان جایگزینی برای فهرست ملاحظات کدنویسی امن - -بسیاری از سازمان‌ها می‌توانند با انتخاب یکی از دو سطح استاندارد MASVS یا انشعاب گرفتن از آن و ایجاد تغییر در دامنه‌ای خاص متناسب با سطح مخاطره‌ی هر برنامه، از این استاندارد بهره‌مند گردند. ما از این نوع انشعاب تا هر زمانی که قابلیت ردیابی حفظ گرد استقبال می‌کنیم، بنابراین اگر یک برنامه‌ی کاربردی الزام 4.1 را محقق ساخته باشد، این بدان معنا است که با تکامل استاندارد نسخه‌های منشعب نیز آن الزام را رعایت می‌کنند. - -### به‌عنوان پایه‌ای برای روش‌شناسی آزمون امنیتی - -یک شیوه‌ی ارزنده‌ی آزمون امنیت برنامه‌ی کاربردی موبایل باید تمامی الزامات فهرست شده در استاندارد MASVS را پوشش دهد. راهنمای آزمون امنیتی موبایل OWASP (MASTG) موارد آزمون جعبه سیاه و جعبه سفید را برای هر الزام وارسی تشریح می نماید. - -### به‌عنوان راهنمایی برای انجام خودکار آزمون‌های واحد و یکپارچگی - -استاندارد MASVS به‌استثنای الزامات معماری، بسیار آزمون‌پذیر طراحی شده است. آزمون‌های واحد، یکپارچه‌سازی و پذیرش، می‌توانند به‌صورت خودکار و مبتنی بر الزامات استاندارد MASVS، در چرخه‌ی پیوسته‌ی توسعه گنجانده شوند. این امر نه تنها آگاهی توسعه‌دهنده را نسبت به امنیت افزایش می‌دهد، بلکه کیفیت کلی برنامه‌های کاربردی حاصله را بهبود می‌بخشد و تعداد یافته‌ها را حین آزمون امنیت، در فاز قبل از عرضه به بازار کاهش می‌دهد. - -### برای آموزش توسعه ایمن - -استاندارد MASVS می‌تواند برای تعریف مشخصه‌های یک برنامه‌ی کاربردی موبایل ایمن استفاده شود. بسیاری از دوره‌های «کد نویسی ایمن» در واقع همان دوره‌های هک قانونمند با نکات اندکی از کد نویسی هستند. این مورد به توسعه‌دهندگان کمکی نمی‌کند. در عوض، دوره‌های توسعه‌ی ایمن، به‌جای مثلاً «10 مشکل امنیتی رایج در کد نویسی»، می‌توانند از استاندارد MASVS، با تمرکز قوی بر کنترل‌های کنشگرایانه استفاده کنند. - -
diff --git a/Document-fa/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-fa/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index e5bc3695e..000000000 --- a/Document-fa/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,41 +0,0 @@ -
- -# V1: الزامات معماری، طراحی و مدل‌سازی تهدید - -## هدف کنترل - -در یک دنیای ایده‌آل، امنیت در تمام مراحل توسعه‌ی برنامه باید در نظر گرفته شود. اما در واقعیت، امنیت اغلب در مرحله‌ی آخر چرخه‌ی حیات توسعه‌ی نرم‌افزار موردتوجه قرار می‌گیرد. علاوه‌بر کنترل‌های فنی، استاندارد وارسی امنیت برنامه‌ی کاربردی موبایل، نیاز به ایجاد فرایندهایی دارد که بتوان از مورد توجه بودن امنیت در زمان برنامه‌ریزی معماری برنامه‌ی موبایل و شناخت وظیفه‌مندی‌های اصلی و امنیتی مؤلفه‌ها اطمینان حاصل نمود. از آنجایی که بسیاری از برنامه‌های موبایل به‌عنوان سرویس‌دهنده از راه دور عمل می‌کنند، باید از اعمال استانداردهای امنیتی مناسب برای آن سرویس‌ها اطمینان حاصل نمود - تست برنامه‌ی موبایل در محیط ایزوله کافی نیست. - -دسته‌بندی "V1"، الزامات مرتبط با فاز معماری و طراحی برنامه‌ی کاربردی موبایل را فهرست می‌نماید. به این ترتیب، این تنها دسته‌بندی‌ای است که به موارد آزمون فنی در راهنمای آزمودن برنامه‌ی کاربردی موبایل OWASP نگاشت نمی‌شود. برای پوشش موضوعاتی مانند مدل‌سازی تهدید، چرخه‌ی حیات توسعه‌ی امن نرم‌افزار و مدیریت کلید، خوانندگان MASVS باید به پروژه‌های مرتبط با OWASP و یا سایر استانداردهای ارائه‌شده در زیر مراجعه نمایند. - -## الزامات وارسی امنیت - -الزامات سطح یک و دو از استاندارد وارسی امنیت برنامه‌های کاربردی موبایل به‌صورت زیر فهرست شده‌اند. - -| # | MSTG-ID | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | تمامی مؤلفه‌های برنامه‌ی کاربردی مورد نیاز شناسایی و شناخته‌شده‌اند. | x | x | -| **1.2** | MSTG-ARCH-2 | کنترل‌های امنیتی هرگز فقط در سمت مشتری اعمال نمی‌شوند، بلکه در نقاط انتهایی مرتبط به کنترل از راه دور نیز اعمال می‌گردد. | x | x | -| **1.3** | MSTG-ARCH-3 | یک معماری سطح بالا در برنامه‌ی کاربردی موبایل و تمامی سرویس‌های متصل به آن تعریف شده‌است و امنیت در آن معماری در نظر گرفته شده‌است. | x | x | -| **1.4** | MSTG-ARCH-4 | داده‌هایی که در برنامه‌ی کاربردی موبایل حساس در نظر گرفته شده‌اند، به‌وضوح شناسایی شده‌اند. | x | x | -| **1.5** | MSTG-ARCH-5 | تمامی مؤلفه‌های برنامه‌ی کاربردی موبایل بر اساس عملکرد امنیتی و یا تجاری که ارائه می‌کنند، مشخص شده‌اند. | | x | -| **1.6** | MSTG-ARCH-6 | مدل‌سازی تهدیدی که برای برنامه‌ی کاربردی موبایل و تمامی سرویس‌های مرتبط از راه دور ایجاد شده است، تهدیدات بالقوه و اقدامات متقابل را شناسایی می‌نماید. | | x | -| **1.7** | MSTG-ARCH-7 | تمامی کنترل‌های امنیتی به‌صورت متمرکز پیاده‌سازی شده‌اند. | | x | -| **1.8** | MSTG-ARCH-8 | یک خط‌مشی صریح برای نحوه‎ی مدیریت کلیدهای رمزنگاری (در صورت وجود) و چرخه‌ی عمر کلیدهای رمزنگاری اعمال می‌شود. در حالت ایده آل، از یک استاندارد مدیریت کلید همانند NIST SP 800-57 پیروی نمایید. | | x | -| **1.9** | MSTG-ARCH-9 | یک سازوکار برای اجرای بروز رسانی برنامه‌ی کاربردی موبایل وجود دارد. | | x | -| **1.10** | MSTG-ARCH-10 | امنیت در تمامی مراحل چرخه‌ی حیات توسعه‌ی نرم‌افزار در نظر گرفته شده‎است. | | x | -| **1.11** | MSTG-ARCH-11 | یک سیاست افشای مسئولیت‌پذیرانه‌ی (آسیب‌پذیری) در حال اجرا است و به‌طور مؤثری اعمال می‌شود. | | x | -| **1.12** | MSTG-ARCH-12 | برنامه‌ی کاربردی موبایل باید با قوانین و مقررات حفظ حریم خصوصی مطابقت داشته باشد. | x | x | - -## مراجع - -برای دریافت اطلاعات بیشتر به آدرس‌های زیر مراجعه نمایید: - -- ده تهدید برتر موبایل (OWASP) - تهدید رتبه‎ی دهم (عملکرد نامربوط) - -- مدلسازی تهدید (OWASP) - -- راهنمای چرخه‌ی حیات توسعه‌ی امن نرم‌افزار (OWASP) - -- راهنمای چرخه‌ی حیات توسعه‌ی نرم‌افزار مایکروسافت - -- استاندارد (NIST SP 800-57) - -- (security.txt) - - -
diff --git a/Document-fa/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-fa/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 8b4fd3d80..000000000 --- a/Document-fa/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,70 +0,0 @@ -
- -# V2: الزامات ذخیره‌سازی داده و حریم خصوصی - -## هدف کنترل - -حفاظت از داده‌های حساس، از قبیل ابزارهای احراز هویت و اطلاعات خصوصی، یک نقطه تمرکز کلیدی در امنیت موبایل است. در مرحله‌ی اول اگر مکانیزم‌های سیستم عامل همانند IPC به‌طور نامناسب استفاده شوند، ممکن است اطلاعات حساس به طور سهوی در معرض دسترسی سایر برنامه‌های کاربردی موجود بر روی همان دستگاه قرار گیرند. همچنین ممکن است که داده‌ها به‌طور اشتباه بر روی حافظه ابری، پشتیبان یا حافظه نهان صفحه‌کلید نشت کنند. علاوه‌بر این، دستگاه‌های موبایل در مقایسه با سایر انواع دستگاه‌ها می‌توانند راحت‌تر مفقود شده یا مورد سرقت قرار بگیرند، بنابراین سناریوی دسترسی فیزیکی یک شخص متخاصم محتمل‌تر است. در این صورت یک سری محافظت‌های اضافی می‌توانند پیاده‌سازی شوند تا دسترسی به داده‌ها دشوارتر گردد. -توجه داشته باشید که از آنجایی که MASVS بر برنامه‌ی کاربردی متمرکز می‌باشد، این استاندارد سیاست‌های الزام شده سطح دستگاه توسط MDM را تحت پوشش قرار نمی‌دهد. - -### تعریف داده حساس - -داده‌ی حساس در چارچوب MASVS هم مربوط به ابزارهای احراز هویت کاربر است و هم هرگونه داده دیگر که در یک چارچوب خاص حساس در نظر گرفته می‌شود، مانند: - -- اطلاعات قابل شناسایی خصوصی (PII)که می‌توانند توسط سرقت هویت مورد سوء استفاده قرار بگیرند: شماره‌های تأمین اجتماعی، شماره‌های کارت اعتباری، شماره‌های حساب بانکی و اطلاعات بهداشتی. - -- اطلاعات بسیار حساس که در صورت به‌خطر افتادن می‌توانند منجر به آسیب به سابقه‎ی شخصی یا خسارت‌های مالی شوند. - -- هرگونه داده‌ای که باید توسط قانون و یا به‌دلایل مورد قبول محافظت شود. - -## الزامات وارسی امنیت - -حجم زیادی از مشکلات افشای اطلاعات می‌توانند با پیروی از قوانین ساده‌ای پیشگیری شوند. بیشتر کنترل‌های فهرست شده در این فصل برای تمام سطوح تایید الزامی هستند. - -| # | MSTG-ID | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | نیاز است تا از امکانات ذخیره‌سازی احراز هویت سیستم از قبیل PII، ابزارهای تصدیق هویت کاربر یا کلید‌های رمزنگاری به طور مناسب استفاده شده باشند. | x | x | -| **2.2** | MSTG-STORAGE-2 | هیچ اطلاعات حساسی نباید خارج از کانتینر برنامه یا امکانات ذخیره‌سازی ابزارهای احراز هویت سیستم ذخیره‌سازی شود. | x | x | -| **2.3** | MSTG-STORAGE-3 | هیچ اطلاعات حساسی نباید در لاگ‌های برنامه‌ها نوشته شود. | x | x | -| **2.4** | MSTG-STORAGE-4 | هیچ اطلاعات حساسی نباید با اشخاص ثالث به اشتراک گذاشته شود مگر اینکه بخشی ضروری از معماری باشد. | x | x | -| **2.5** | MSTG-STORAGE-5 | حافظه کش صفحه‌کلید برای ورودی‌های متنی که شامل اطلاعات حساس است غیر فعال شده باشد. | x | x | -| **2.6** | MSTG-STORAGE-6 | هیچ اطلاعات حساسی توسط مکانیزم IPC فاش نشود. | x | x | -| **2.7** | MSTG-STORAGE-7 | هیچ اطلاعات حساسی از قبیل کلمات عبور یا پین‌ها توسط رابط کاربری فاش نشوند. | x | x | -| **2.8** | MSTG-STORAGE-8 | هیچ اطلاعات حساسی در فایل‌های پشتیبان تولید شده توسط سیستم عامل موبایل وجود نداشته باشد. | | x | -| **2.9** | MSTG-STORAGE-9 | وقتی برنامه‌ی کاربردی وارد پس‌زمینه می‌شود باید اطلاعات حساس را از view ها پاک کند. | | x | -| **2.10** | MSTG-STORAGE-10 | برنامه‌ی کاربردی اطلاعات حساس را بیش از میزان ضروری در حافظه نگهداری نکند و حافظه پس از استفاده صریحا پاک شود. | | x | -| **2.11** | MSTG-STORAGE-11 | برنامه کاربردی یک سیاست device-access-security حداقلی را الزامی نماید. از جمله الزام کاربر به تنظیم یک کد عبور دستگاه. | | x | -| **2.12** | MSTG-STORAGE-12 | برنامه‌ی کاربردی کاربر را در مورد انواع اطلاعات شخصی قابل شناسایی پردازش شده و همچنین بهترین شیوه‌های امنیتی که کاربر باید در استفاده از برنامه دنبال نماید، آموزش دهد. | x | x | -| **2.13** | MSTG-STORAGE-13 | هیچ داده حساسی نباید به طور محلی بر روی دستگاه موبایل ذخیره‌سازی شود. بلکه داده در موقع نیاز باید از یک پایانه‌ی راه دور دریافت شده و فقط در حافظه‌ی غیر دائم ذخیره‌سازی شود. | | x | -| **2.14** | MSTG-STORAGE-14 | اگر هنوز لازم است که داده‌ی حساس به طور محلی ذخیره‌سازی شود، باید توسط یک کلید مشتق شده از حافظه ذخیره سازی پشتیبانی شده به‌صورت سخت‌افزاری رمزنگاری شده که نیازمند تصدیق هویت است. | | x | -| **2.15** | MSTG-STORAGE-15 | حافظه ذخیره‌سازی محلی برنامه‌ی کاربردی باید بعد از تعداد زیادی تلاش ناموفق برای تصدیق هویت پاکسازی شود. | | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل را برای تایید الزامات لیست شده در این بخش، فراهم می کند. - -- اندروید: تست محل ذخیره‌سازی داده - -- iOS: تست محل ذخیره‌سازی داده - - -همچنین برای اطلاعات بیشتر مشاهده کنید: - -- OWASP Mobile Top 10: M1 (استفاده‌ی نادرست از پلتفورم) - -- OWASP Mobile Top 10: M2 (دخیره‌ی نا‌امن داده) - -- CWE 117 (خنثی سازی خروجی‌های اشتباه برای لاگ ها) - -- CWE 200 (افشای اطلاعات) - -- CWE 276 (دسترسی‌های پیشفرض نادرست) - -- CWE 311 (عدم رمزنگاری داده‌های حساس) - -- CWE 312 (ذخیره‌سازی داده‌های حساس به صورت متن آشکار) - -- CWE 316 (دخیره‌سازی داده‌های حساس به‌صورت متن آشکار در حافظه‌ی موقت) - -- CWE 359 (افشای اطلاعات خصوصی (نقش حریم خصوصی)) - -- CWE 522 (محافظت ناکافی از احراز هویت) - -- CWE 524 (افشای اطلاعات از طریق حافظه کش) - -- CWE 530 (افشای فایل‌های پشتیبان در محیط کنترل بدون تعین سطح دسترسی) - -- CWE 532 (افشای اطلاعات از طریق فایل‌های لاگ) - -- CWE 534 (افشای اطلاعات از طریق فایل‌های لاگ اشکال زدایی) - -- CWE 634 (ضعف‌های ناشی از پردازش سیستمی) - -- CWE 798 (استفاده از احراز هویت به‌صورت هارد کد شده) - -- CWE 921 (ذخیره‌سازی اطلاعات حساس در مکانیزمی بدون کنترل دسترسی) - -- CWE 922 (ذخیره‌سازی نا‌ایمن اطلاعات حساس) - - -
diff --git a/Document-fa/0x08-V3-Cryptography_Verification_Requirements.md b/Document-fa/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index db20d2a6d..000000000 --- a/Document-fa/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,45 +0,0 @@ -
- -# V3: الزامات رمزنگاری - -## هدف کنترل - -رمزنگاری یک جزء ضروری در حفاظت از داده‌ی ذخیره شده در گوشی موبایل می‌باشد. همچنین این دسته بندی، جایی است که ممکن است همه چیز به شکل وحشتناکی اشتباه پیش برود، به خصوص هنگامی که از قرداد‌های استاندارد پیروی نشود. هدف کنترل‌ها در این بخش این است که اطمینان حاصل کنند برنامه وارسی شده، از رمزنگاری طبق بهترین روش‌های صنعتی استفاده می‌کند، که شامل موارد زیر می‌شود: - -- استفاده از کتابخانه‌های رمزنگاری ثابت شده؛ - -- انتخاب و پیکربندی مناسب اصول ابتدایی رمزنگاری؛ - -- تولید یک عدد تصادفی مناسب هرگاه که تصادفی بودن مورد نیاز است؛ - -## الزامات وارسی امنیت - -| # | MSTG-ID | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | برنامه بر رمزنگاری متقارن با کلید‌های هارد‌کد شده، به عنوان تنها روش رمزگذاری، تکیه نمی کند.| x | x | -| **3.2** | MSTG-CRYPTO-2 | برنامه از پیاده سازی‌های به اثبات رسیده‌ی ابتدایی رمزنگاری استفاده می‌کند. | x | x | -| **3.3** | MSTG-CRYPTO-3 | برنامه از اصول ابتدایی رمزنگاری استفاده می کند که برای استفاده خاص مناسب هستند و با پارامترهایی که به بهترین روش‌های صنعتی پایبند هستند، پیکربندی شده‌اند. | x | x | -| **3.4** | MSTG-CRYPTO-4 | برنامه از پروتکل‌ها یا الگوریتم‌های رمزنگاری که به دلایل امنیتی به طور گسترده منسوخ شناخته شده‌اند، استفاده نمی کند. | x | x | -| **3.5** | MSTG-CRYPTO-5 | برنامه از کلید رمزنگاری یکسان برای چندین عمل، استفاده نمی کند. | x | x | -| **3.6** | MSTG-CRYPTO-6 | تمام مقدارهای تصادفی با استفاده از یک تولید کننده عدد تصادفی به‌طور‌کافی امن تولید شده‌اند. | x | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می کند. - -- Android: تست رمزنگاری - -- iOS: تست رمزنگاری - - -برای اطلاعات بیشتر همچنین مشاهده کنید: - -- OWASP Mobile Top 10: M5 (رمزنگاری نامناسب) - -- CWE 310 (مشکلات رمزنگاری) - -- CWE 321 (استفاده از کلید رمزنگاری هارد‌کد شده) - -- CWE 326 (قدرت رمزنگاری ناکافی) - -- CWE 327 (استفاده از الگوهای رمزنگاری پرخطر یا منقضی شده) - -- CWE 329 (عدم استفاده از IV تصادفی به‌همراه حالت CBC) - -- CWE 330 (استفاده از مقادیر تصادفی نامناسب) - -- CWE 337 (جستجو قابل حدس در PRNG) - -- CWE 338 (استفاده از رمزنگاری ضعیف تولید کننده‌ی جعلی اعداد تصادفی (PRNG)) - - -
diff --git a/Document-fa/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-fa/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 0128c0792..000000000 --- a/Document-fa/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,45 +0,0 @@ -
- -# V4: الزامات تصدیق هویت و مدیریت نشست - -## هدف کنترل - -در بیشتر موارد، ورود کاربران به یک سرویس از راه‌دور بخشی جدایی ناپذیر از معماری کلی برنامه موبایل است. حتی اگر بیشتر منطق در پایانه رخ دهد. MASVS برخی الزامات پایه در مورد چگونگی مدیریت نشست‌ها و حساب‌های کاربری را تعریف می‌نماید. - -## الزامات وارسی امنیت - -| # | شناسه-آزمون امنیتی برنامه‌ی کاربردی موبایل | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | اگر برنامه‌ی کاربردی برای کاربران، دسترسی به یک سرویس از راه‌دور را فراهم می‌کند، نوعی تصدیق هویت همانند نام کاربری و کلمه عبور باید در پایانه‌ی راه‌دور انجام شود. | x | x | -| **4.2** | MSTG-AUTH-2 | اگر از مدیریت نشست حالت ‌مند (stateful) استفاده شده است، پایانه‌ی راه دور باید بدون ارسال احراز هویت کاربر از شناسه‌های نشست تولید شده به‌طور تصادفی برای تصدیق هویت درخواست‌های سمت کاربر استفاده کند. | x | x | -| **4.3** | MSTG-AUTH-3 | اگر از تصدیق هویت مبتنی بر توکن بدون حالت (stateless) استفاده شده است، سرور باید توکنی را ارائه دهد که توسط یک الگوریتم امن امضا شده باشد. | x | x | -| **4.4** | MSTG-AUTH-4 | وقتی کاربر از سیستم خارج می‌شود، پایانه‌ی راه‌دور نشست فعلی را پایان می‌دهد. | x | x | -| **4.5** | MSTG-AUTH-5 | یک سیاست کلمه عبور وجود دارد و در سمت پایانه‌ی راه‌دور اعمال می‌شود. | x | x | -| **4.6** | MSTG-AUTH-6 | پایانه‌ی راه‌دور مکانیزمی را برای محافظت در برابر وارد کردن اطلاعات احراز هویت نادرست به دفعات زیاد پیاده‌سازی می‌کند. | x | x | -| **4.7** | MSTG-AUTH-7 | نشست‌ها پس از مدتی عدم فعالیت یا منقضی شدن توکن‌های دسترسی در سمت پایانه‌ی راه‌دور نامعتبر می‌شوند. | x | x | -| **4.8** | MSTG-AUTH-8 | تصدیق هویت بیومتریک نباید محدود به یک رویداد باشد (به‌عنوان نمونه استفاده از یک API که تنها True و False را باز می‌گرداند). به‌جای این، باید بر اساس گشودن keychain یا keystore باشد. | | x | -| **4.9** | MSTG-AUTH-9 | مرحله دومی از تصدیق هویت در پایانه‌ی راه‌دور وجود داشته باشد و الزامات تصدیق هویت دو مرحله‌ای همواره الزامی باشند. | | x | -| **4.10** | MSTG-AUTH-10 | تراکنش‌های حساس نیازمند تصدیق هویت مرحله به مرحله باشند. | | x | -| **4.11** | MSTG-AUTH-11 | برنامه‌ی کاربردی کاربر را نسبت به تمام فعالیت‌های ورود به سیستم با حساب وی آگاه می‌سازد. کاربران قادرند لیستی از دستگاه‌هایی که از آن‌ها برای دسترسی به حساب استفاده شده است را مشاهده کنند و دستگاه‌های خاصی را مسدود نمایند. | | x | -| **4.12** | MSTG-AUTH-12 | مدل‌های صدور مجوز باید در سمت پایانه‌ی راه‌دور تعریف شده و اجباری شوند. | x | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می‌کند. - -- عمومی: احراز هویت و مدیریت نشست - -- Android: تست احراز هویت داخلی - -- iOS: تست احراز هویت داخلی - - -برای اطلاعات بیشتر همچنین مشاهده کنید: - -- OWASP Mobile Top 10: M4 (احراز هویت نا امن) - -- OWASP Mobile Top 10: M6 (سطح درسترسی نا امن) - -- CWE 287 (احراز هویت نامناسب) - -- CWE 307 (اعمال نامناسب منع دسترسی برای تلاش‌های زیاد) - -- CWE 308 (استفاده از تایید هویت تک مرحله‌ای) - -- CWE 521 (الزامات کلمه عبور ضعیف) - -- CWE 604 (احراز هویت سمت کاربر) - -- CWE 613 (انقضای نامناسب نشست) - - -
diff --git a/Document-fa/0x10-V5-Network_communication_requirements.md b/Document-fa/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 35d0ff98e..000000000 --- a/Document-fa/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,43 +0,0 @@ -
- -# V5: الزامات ارتباطات شبکه - -## هدف کنترل - -هدف کنترل‌های فهرست شده در این بخش، این است که از محرمانگی و یکپارچگی اطلاعات مبادله شده میان برنامه موبایل و پایانه‌های سرویس از راه دور، اطمینان حاصل گردد. در حداقل شرایط، یک برنامه موبایل باید کانالی امن و رمزنگاری شده برای ارتباطات شبکه با استفاده از پروتکل TLS با تنظیمات مناسب، ایجاد کند. سطح دو، اقدامات اضافی دفاع عمیق، مانند SSL pinning را لیست می‌کند. - -## الزامات وارسی امنیت - -| # | MSTG-ID | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | داده با استفاده از TLS روی شبکه رمزگذاری می‌شود. کانال امن در طول برنامه، همواره استفاده می‌شود. | x | x | -| **5.2** | MSTG-NETWORK-2 | تنظیمات TLS با بهترین روش‌های حال حاضر مطابقت دارند، و یا اگر سیستم عامل موبایل از استانداردهای پیشنهادی پشتیبانی نمی‌کند، تنظیمات TLS تا جای ممکن با آنها مشابهت داشته باشد. | x | x | -| **5.3** | MSTG-NETWORK-3 | برنامه، گواهینامه X.509 پایانه‌ از راه‌دور را هنگامی که کانال امن ایجاد شود، وارسی می‌کند. تنها گواهینامه‌های امضا شده توسط CA مطمئن قابل قبول می‌باشند. | x | x | -| **5.4** | MSTG-NETWORK-4 | برنامه یا از Certificate Store خودش استفاده می‌کند، یا گواهینامه‌ی پایانه یا کلید عمومی را پین می‌کند، و متعاقبا اتصالات به پایانه‌هایی که گواهینامه یا کلید متفاوتی دارند را ایجاد نمی‌کند، حتی اگر آن گواهینامه توسط CA مطمئن امضا شده باشد. | | x | -| **5.5** | MSTG-NETWORK-5 | برنامه تنها بر یک کانال ناامن ارتباطی (ایمیل یا پیامک) برای عملیات‌های بسیار مهم مانند ثبت نام‌ها و بازگردانی حساب، تکیه نمی‌کند. | | x | -| **5.6** | MSTG-NETWORK-6 | برنامه تنها بر کتابخانه‌های امنیت و اتصال که به روز می‌باشند، متکی می‌باشد. | | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می‌کند. - -- عمومی: تست ارتباطات شبکه - -- Android: تست ارتباطات شبکه - -- iOS: تست ارتباطات شبکه - - -برای اطلاعات بیشتر، مشاهده کنید: - -- OWASP Mobile Top 10: M3 (ارتباطات نا امن) - -- CWE 295 (اعتبار سنجی نادرست گواهی نامه) - -- CWE 296 (پیروی ناصحیح از زنجیره‌ی اطمینان گواهی نامه) - -- CWE 297 (صحت سنجی نادرست گواهینامه با میزبان اشتباه) - -- CWE 298 (اشتباه در اعتبار سنجی انقضاء گواهی نامه) - -- CWE 308 (استفاده از احراز هویت یک مرحله‌ای) - -- CWE 319 (انتقال اطلاعات مهم به صورت متنی واضح) - -- CWE 326 (استحکام ناکافی در رمزنگاری) - -- CWE 327 (استفاده از الگوی رمزنگاری منقضی شده یا پرخطر) - -- CWE 780 (استفاده از الگوی RSA بدون OAEP) - -- CWE 940 (اشتباه در صحت سنجی منبع کانال ارتباطی) - -- CWE 941 (مشخص سازی اشتباه منبع در یک کانال ارتباطی) - - -
diff --git a/Document-fa/0x11-V6-Interaction_with_the_environment.md b/Document-fa/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index b4aa8f06d..000000000 --- a/Document-fa/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,49 +0,0 @@ -
- -# V6: الزامات تعامل با پلتفرم - -## هدف کنترل - -کنترل‌های این گروه، اطمینان حاصل می‌کنند که برنامه‌ی کاربردی از API مربوط به پلتفرم و مؤلفه‌های استاندارد به‌صورت امن استفاده می‌کند. علاوه‌بر‌این، این کنترل‌ها ارتباطات بین برنامه‌های کاربردی (IPC) را کنترل می‌نماید. - -## الزامات وارسی امنیت - -| # | MSTG-ID | توضیحات | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | برنامه‌ی کاربردی تنها به حداقل دسترسی‌های ضروری نیاز داشته باشد. | x | x | -| **6.2** | MSTG-PLATFORM-2 | تمام ورودی‌ها از منابع خارجی و کاربر، اعتبارسنجی شده و اگر ضروری بود به خوبی بررسی شوند. این شامل داده‌های دریافت شده از رابط کاربری، مکانیزم‌های IPC از قبیل intent ها، URL های اختصاصی و منابع شبکه می‌باشد. | x | x | -| **6.3** | MSTG-PLATFORM-3 | برنامه‌ی کاربردی عملکردهای حساس را از طریق طرح‌های URL اختصاصی صادر نمی‌کند. مگر اینکه این مکانیزم‌ها به درستی محافظت شده باشند. | x | x | -| **6.4** | MSTG-PLATFORM-4 | برنامه‌ی کاربردی عملکرد حساس را از طریق امکانات IPC صادر نمی‌کند. مگر اینکه این مکانیزم‌ها به درستی محافظت شده باشند. | x | x | -| **6.5** | MSTG-PLATFORM-5 | جاوا اسکریپت در WebView ها غیر فعال شده است. مگر اینکه به صراحت مورد‌نیاز باشد. | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebView ها طوری پیکربندی شده‌اند که تنها حداقل کنترل کننده‌های پروتکل مورد نیاز را مجاز بدانند (به‌طور ایده‌آل تنها HTTPS پشتیبانی شود). کنترل کننده‌های پروتکل به‌طور بالقوه خطرناک از قبیل file ، tel و app-id غیر فعال باشند. | x | x | -| **6.7** | MSTG-PLATFORM-7 | اگر متدهای داخلی برنامه در WebView ها قابل دیدن هستند، بررسی کنید که WebView تنها جاوا اسکریپت قرار داده شده در بسته برنامه‌ی کاربردی را پردازش می‌کند. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Object ِDeserialization(توالی‌سازی اشیاء) در صورت وجود داشتن توسط API های امن توالی‌سازی پیاده‌سازی شده باشد. | x | x | -| **6.9** | MSTG-PLATFORM-9 | برنامه‌ی کاربردی از خود در برابر حملات پوشاندن صفحه نمایش محافظت می‌کند. (فقط سیستم عامل اندروید) | | x | -| **6.10** | MSTG-PLATFORM-10 | حافظه‌ی نهان، حافظه‌ی ذخیره‌سازی و منابع بارگذاری شده در WebView، (جاوا اسکریپت و غیره) باید قبل از نابود شدن WebView پاک شوند. | | x | -| **6.11** | MSTG-PLATFORM-11 | وارسی کنید که برنامه‌ی کاربردی در هنگام وارد کردن اطلاعات (فقط سیستم عامل iOS) حساس، از استفاده صفحه کلیدهای شخص ثالث جلوگیری می‌کند. | | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می‌کند. - -- Android: تست تعامل با پلتفورم - -- iOS: تست تعامل با پلتفورم - - -برای اطلاعات بیشتر همچنین مشاهده کنید: - -- OWASP Mobile Top 10: M1 (استفاده‌ی نادرست از پلتفورم) - -- OWASP Mobile Top 10: M7 (کیفیت پایین کد) - -- CWE 20 (اعتبارسنجی نادرست ورودی) - -- CWE 79 (خنثی سازی نادرست ورودی‌ها در حین تولید صفحات وب) - -- CWE 200 (افشای اطلاعات) - -- CWE 250 (اجرا با سطح دسترسی غیرضروری) - -- CWE 672 (بهره‌برداری از یک منبع بعد از منقضی شدن یا آزاد سازی آن) - -- CWE 749 (افشای متدها و توابع خطرناک) - -- CWE 772 (فراموش کردن آزادسازی یک منبع پس از اتمام عمر مفید) - -- CWE 920 (اعمال نادرست جلوگیری از مصرف قدرت) - -- CWE 925 (اعمال ناصحیح صحت سنجی هدف با منتشر کردن دریافت کننده‌ها) - -- CWE 926 (صدور نادرست اجزای برنامه‌ی اندرویدی) - -- CWE 927 (استفاده از Implicit Intent برای ارتباطات حساس) - -- CWE 939 (تعیین سطح دسترسی نادرست در کنترل کننده‌های طرح‌های اختصاصی URL) - - -
diff --git a/Document-fa/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-fa/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index f5e5cf552..000000000 --- a/Document-fa/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,46 +0,0 @@ -
- -# V7: الزامات کیفیت کد و تنظیمات ساخت - -## هدف کنترل - -هدف از این کنترل، این است که اطمینان حاصل گردد شیوه‌های کد نویسی امنیتی پایه در توسعه‌ی برنامه رعایت می‌شوند و امکانات امنیتی "رایگان" که توسط کامپایلر ارائه می‌شوند، فعال می‌باشند. - -## الزامات وارسی امنیت - -| # | MSTG-ID | شرح | سطح یک | سطح دو | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | برنامه توسط گواهینامه‌ی معتبر امضا و تامین شده است که در آن از کلید خصوصی به درستی محافظت شده است. | x | x | -| **7.2** | MSTG-CODE-2 | برنامه در حالت انتشار ساخته شده است، همراه با تنظیمات مناسب برای ساخت یک انتشار (به‌عنوان مثال غیر قابل دیباگ بودن) | x | x | -| **7.3** | MSTG-CODE-3 | علائم اشکال زدایی از باینری‌های بومی حذف شده‌اند. | x | x | -| **7.4** | MSTG-CODE-4 | کد اشکال زدایی و کد دستیار توسعه دهنده حذف شده باشد (به‌عنوان نمونه: کد آزمایشی، درب‌های پشتی، تنظیمات مخفی). برنامه استثنائات یا پیغام‌های اشکال زدایی طولانی را ثبت نمی‌کند. | x | x | -| **7.5** | MSTG-CODE-5 | تمامی مؤلفه‌های شخص ثالث مورد استفاده‌ی برنامه‌ی موبایل، همچون کتابخانه‌ها و چارچوب‌ها، شناسایی شده‌اند، و برای داشتن آسیب‌پذیری‌های شناخته شده بررسی می‌شوند. | x | x | -| **7.6** | MSTG-CODE-6 | برنامه استثنائات احتمالی را رسیدگی کرده و آنها را مدیریت می‌کند.| x | x | -| **7.7** | MSTG-CODE-7 | منطق مدیریت استثناء در کنترل‌های امنیتی، به‌صورت پیش‌فرض دسترسی را منع می‌کند. | x | x | -| **7.8** | MSTG-CODE-8 | در کد مدیریت نشده، حافظه به‌صورت ایمن اختصاص یافته، آزاد شده و استفاده می‌شود. | x | x | -| **7.9** | MSTG-CODE-9 | امکانات امنیتی رایگان ارائه شده توسط زنجیره ابزار، همچون کوچک سازی byte-code، محافظت از پشته، پشتیبانی از PIE و شمارنده ارجاع خودکار، فعال می‌باشند. | x | x | - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می‌کند. - -- Android: تست تنظیمات ساخت و کیفیت کد - -- iOS: تست تنظیمات ساخت و کیفیت کد - - -برای اطلاعات بیشتر، مشاهده کنید: - -- OWASP Mobile Top 10: M7 (کیفیت ضعیف کد) - -- CWE 20 (اعتبار سنجی نادرست ورودی) - -- CWE 89 (اعمال نادرست خنثی سازی عناصر خاص که در فرمان‌های SQL استفاده می‌شوند) - -- CWE 95 (اعمال نادرست خنثی سازی مستقیم در ارزیابی پویای کد ('Eval Injection')) - -- CWE 119 (محدودسازی نادرست عملگرها در محدوده‌ی بافر حافظه) - -- CWE 215 (افشای اطلاعات از طریق اطلاعات عیب‌یابی) - -- CWE 388 (7PK - استثنائات) - -- CWE 489 (بقایای عیب یابی کد) - -- CWE 502 (پاک‌سازی داده‌های نامطمئن) - -- CWE 511 (بمب‌های منطقی/زمانی) - -- CWE 656 (توجه به امنیت در بی توجهی) - -- CWE 676 (استفاده‌ی بالقوه‌ی توابع خطرناک) - -- CWE 937 (OWASP Top Ten 2013 دسته‌بندی A9 - استفاده از آسیب‌پذیری‌های شناخته شده) - - -
diff --git a/Document-fa/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-fa/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 514174654..000000000 --- a/Document-fa/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,74 +0,0 @@ -
- -# V8: الزامات انعطاف‌پذیری - -## هدف کنترل - -این بخش معیارهای دفاع در عمق توصیه شده برای برنامه‌های کاربردی که اطلاعات حساس را پردازش کرده یا دسترسی به عملکرد یا اطلاعات حساس را فراهم می‌کنند را پوشش می‌دهد. نبود این کنترل‌ها باعث ایجاد آسیب‌پذیری نمی‌شود بلکه این کنترل‌ها به‌منظور افزایش انعطاف‌پذیری برنامه‌ی کاربردی در مقابل مهندسی معکوس و حملات خاص سمت کاربر در نظر گرفته شده‌اند. - -کنترل‌های این بخش باید بنابه‌نیاز و بر اساس ارزیابی خطرات به‌وجود آمده توسط دستکاری غیرمجاز برنامه و یا مهندسی معکوس کد اعمال شوند. برای مشاهده لیستی از خطرات کسب و کار و همچنین تهدیدات فنی مربوطه، پیشنهاد می‌کنیم که به سند OWASP با عنوان "خطرات فنی مهندسی معکوس و مهندسی معکوس تغییر غیر مجاز کد و جلوگیری از تغییر کد" مراجعه شود. (منابع پایین را مشاهده کنید.) - -**توجه کنید که محافظت‌های نرم‌افزاری نباید هرگز به عنوان جایگزینی برای کنترل‌های امنیتی استفاده شوند. کنترل‌های فهرست شده در MASVR-R به‌منظور اضافه کردن کنترل‌های محافظتی مازاد مرتبط با تهدیدات خاص به برنامه‌هایی که الزامات امنیتی MASVS را برآورده می‌کنند قرار داده شده‌اند.** - -ملاحظات زیر قابل اجرا هستند: - -1. یک مدل تهدید باید تعریف شود که به‌طور روشن طرح کلی تهدیدات سمت کاربر که قرار است تعریف شوند را مشخص نماید. علاوه‌بر‌این، درجه محافظتی که برنامه قرار است ارائه دهد باید مشخص شود. به‌عنوان مثال، اولین هدف می‌تواند این باشد که سازندگان بدافزار هدف که به دنبال سوء استفاده از برنامه‌های کاربردی هستند را مجبور کنیم که برای مهندسی معکوس تلاش زیادی نمایند. - -2. مدل تهدید باید معتبر و مناسب باشد. به‌عنوان مثال اگر یک مهاجم بتواند به راحتی کل جعبه سفید را سرقت کند، مخفی کردن یک کلید رمزنگاری در یک پیاده‌سازی جعبه سفید ممکن است کاری زائد باشد. - -3. اثربخشی محافظت باید همیشه توسط یک متخصص انسانی دارای که داری تجربه در زمینه راه‌های جلوگیری از دستکاری برنامه و مبهم‌سازی است وارسی و تأیید شود (همچنین به بخش‌های "مهندسی معکوس" و "ارزیابی محافظت‌های نرم‌افزاری" در راهنمای آزمون امنیت موبایل مراجعه کنید). - - - -### منع تجزیه و تحلیل پویا و دستکاری برنامه - -| # | MSTG-ID | شرح | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | برنامه روت بودن یا جیلبریک بودن گوشی را تشخیص داده و پاسخ مناسبی به آن بدهد. این پاسخ می‌تواند با ارسال هشدار به کاربر یا متوقف کردن برنامه انجام شود. | x | -| **8.2** | MSTG-RESILIENCE-2 | برنامه‌ی کاربردی از عیب‌یابی (debugging) جلوگیری کرده و یا موقع اتصال یک دیباگر آن را شناسایی کرده و پاسخ مناسب نسبت به آن می‌دهد. تمام پروتکل‌های عیب‌یابی در دسترس باید تحت پوشش قرار گیرند. | x | -| **8.3** | MSTG-RESILIENCE-3 | برنامه‌ی کاربردی دستکاری فایل‌های اجرایی و داده‌های حساس درون sandbox خود را تشخیص داده و به آن پاسخ می‌دهد. | x | -| **8.4** | MSTG-RESILIENCE-4 | برنامه‌ی کاربردی، حضور ابزارها و چارچوب‌های پراستفاده مهندسی معکوس را تشخیص داده و به آن پاسخ می‌دهد.| x | -| **8.5** | MSTG-RESILIENCE-5 | برنامه‌ی کاربردی، اجرا شدن خود داخل شبیه‌ساز را تشخیص داده و به آن پاسخ می‌دهد. | x | -| **8.6** | MSTG-RESILIENCE-6 | برنامه‌ی کاربردی، تغییر کد و داده در فضای حافظه خودش را تشخیص داده و به آن پاسخ می‌دهد. | x | -| **8.7** | MSTG-RESILIENCE-7 | برنامه‌ی کاربردی، مکانیزم‌های متعددی را در هر دسته دفاعی (8.1 تا 8.6) به‌کار می‌گیرد. توجه کنید که انعطاف‌پذیری، با مقدار و تنوع اصالت مکانیزم‌های استفاده شده مقیاس می‌یابد. | x | -| **8.8** | MSTG-RESILIENCE-8 | مکانیزم‌های تشخیص از انواع مختلفی از پاسخ‌ها استفاده می‌نمایند که شامل تاخیر در پاسخ و پاسخ‌های مخفی می‌باشد. | x | -| **8.9** | MSTG-RESILIENCE-9 | عمل مبهم‌سازی (Obfuscation) به دفاع‌های برنامه‌ای اعمال شده است که باعث جلوگیری از شفاف‌سازی کد (De-obfuscation) توسط تجزیه و تحلیل پویا می‌شود. | x | - -### اتصال دستگاه - -| # | MSTG-ID | شرح | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | برنامه‌ی کاربردی، از یک اثر انگشت دستگاه، مشتق شده از ویژگی‌های متعدد یکتا مربوط به دستگاه کمک می‌گیرد و با آن یک عملکرد "اتصال دستگاه" را پیاده‌سازی می‌کند. | x | - - - -### منع درک کد - -| # | MSTG-ID | شرح | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 |تمام فایل‌های اجرایی و کتابخانه‌های متعلق به برنامه‌ی کاربردی، یا در سطح فایل رمزنگاری شده‌اند و یا قسمت‌های مهم کد و داده، درون فایل‌های اجرایی، رمزنگاری یا بسته‌بندی شده‌اند. تجزیه و تحلیل جزئی ایستا، کد یا داده مهمی را افشا نمی‌کند. | x | -| **8.12** | MSTG-RESILIENCE-12 | با توجه به تحقیقات منتشر شده‌ی فعلی، اگر هدف مبهم‌سازی (Obfuscation) محافظت از ارتباطات حساس است، از یک طرح مبهم‌سازی استفاده شود که هم برای وظیفه خاص مناسب باشد و هم در مقابل روش‌های دستی و اتوماتیک شفاف‌سازی کد (De-obfuscation) مقاوم باشد. اثربخشی طرح مبهم‌سازی باید از طریق آزمون دستی وارسی شود. توجه کنید که ویژگی‌های ایزوله‌سازی سخت‌افزاری در مقابل مبهم‌سازی در هر زمان ممکن دارای برتری هستند. | x | - -### منع استراق سمع - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | در کنار محکم‌سازی قوی طرف‌های ارتباط، رمزنگاری Payload سطح برنامه‌ی کاربردی، می‌تواند برای جلوگیری از استراق سمع بیشتر به‌عنوان یک دفاع عمیق اعمال شود. | x | - - - -## منابع - -راهنمای وارسی امنیتی موبایل OWASP، دستورالعمل‌هایی مفصل برای تایید الزامات لیست شده در این بخش، فراهم می‌کند. - -- اندروید: تست انعطاف پذیری در برابر مهندسی معکوس - -- iOS: تست انعطاف پذیری در برابر مهندسی معکوس - - -همچنین برای اطلاعات بیشتر، مشاهده کنید: - -- OWASP Mobile Top 10: M8 (دستکاری کد) - -- OWASP Mobile Top 10: M9 (مهندسی معکوس) - -- تهدیدات مهندسی معکوس (OWASP) - -- مهندسی معکوس و جلوگیری از تغییر کد (OWASP) - - -
diff --git a/Document-fa/0x90-Appendix-A_Glossary.md b/Document-fa/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 15482ac5b..000000000 --- a/Document-fa/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,61 +0,0 @@ -
- -# پیوست الف: واژه‌نامه - -- **Address Space Layout Randomization (ASLR)** – تکنیکی برای دشوارسازی بهره‌برداری از باگ‌های خرابی حافظه. -- **Application Security** – -امنیت سطح برنامه‌ی کاربردی به جای تمرکز بر به‌عنوان مثال سیستم‌عامل پایه یا شبکه‌های متصل شده، بر تجزیه و تحلیل مؤلفه‌هایی که لایه‌ی برنامه‌ی کاربردی مدل اتصال متقابل سامانه‌های باز (OSI) را تشکیل می‌دهند تمرکز دارد. -- **(وارسی امنیت برنامه) Application Security Verification** – یک ارزیابی فنی از برنامه‌ی کاربردی در برابر OWASP MASVS. -- **Application Security Verification Report** – گزارشی که نتایج نهایی و تجزیه و تحلیل پشتیبان تولید شده توسط تأیید کننده برای یک برنامه‌ کاربردی خاص را مستند سازی می‌کند. -- **Authentication** – وارسی هویت ادعا شده توسط کاربر یک برنامه‌ی کاربردی. -- **Automated Verification** – -استفاده از ابزارهای اتوماتیک (ابزارهای تجزیه و تحلیل پویا و ایستا و یا هر دو) که از امضاهای آسیب‌پذیری جهت یافتن مشکلات استفاده می‌کنند. -- **Black Box Testing** – یک روش آزمودن نرم‌افزار است که عملکرد یک برنامه‌ی کاربردی را بدون دانستن ساختار و نحوه‌ی عملکرد داخلی آن بررسی می‌کند. -- **Component** – یک واحد کد جامع همراه با رابط‌های دیسک و شبکه مربوطه که با سایر مؤلفه‌ها ارتباط برقرار می‌کند. -- **Cross-Site Scripting (XSS)** – یک آسیب‌پذیری امنیتی که معمولاً در برنامه‌های تحت وب یافت می‌شود و تزریق اسکریپت‌های سمت کاربر به محتوا را امکان‌پذیر می‌سازد. -- **Cryptographic Module** – نرم‌افزار، سخت افزار و یا میان‌افزار که الگوریتم‌های رمزنگاری را پیاده‌سازی می‌کند و یا کلید‌های رمزنگاری را تولید می‌کند. -- **CWE** – یک لیست توسعه یافته شده توسط جامعه‌ی کاربری از ضعف‌های رایج امنیتی نرم‌افزارها است. CWE به‌عنوان یک زبان مشترک، یک معیار اندازه‌گیری برای ابزارهای امنیت نرم‌افزار و به‌عنوان یک خط پایه جهت تلاش برای شناسایی ضعف، کاهش و جلوگیری از آن‌ها است. -- **Dynamic Application Security Testing (DAST)** – -فناوری‌های آزمودن پویای امنیت برنامه‌ی کاربردی (DAST)، جهت شناسایی شرایط نشان دهنده‌ی یک آسیب‌پذیری امنیتی در یک برنامه‌ی کاربردی که در حالت اجرایی خود قرار دارد طراحی شده‌اند. -- **Design Verification** – ارزیابی فنی معماری امنیت یک برنامه‌ی کاربردی. -- **Dynamic Verification** – استفاده از ابزارهای خودکار که از امضاهای آسیب‌پذیری جهت یافتن مشکلات در حین اجرای یک برنامه استفاده می‌کنند. -- **Globally Unique Identifier (GUID)** – یک شماره‌ی مرجع یکتا که به‌عنوان یک کد شناسایی در نرم‌افزار مورد استفاده قرار می‌گیرد. -- **Hyper Text Transfer Protocol (HTTP)** – -یک پروتکل برنامه‌ کاربردی است که برای سیستم‌های توزیع شده، مبتنی بر همکاری و سیستم‌های اطلاعات ابر رسانه مورد استفاده قرار می‌گیرد. HTTP بنیان ارتباط داده برای شبکه‌ی جهانی وب است. -- **Hardcoded Keys** – کلیدهای رمزنگاری که بر روی خود دستگاه ذخیره شده‌اند. -- **IPC** – ارتباطلات بین پروسه‌ای، در IPC پروسه‌ها با یکدیگر و کرنل ارتباط برقرار کرده تا فعالیتهای آن‌ها را هماهنگ سازند. -- **Input Validation** – استاندارد سازی و اعتبارسنجی ورودی غیر مطمئن کاربر. -- **Java Bytecode** – -بایت کد جاوا مجموعه‌ی دستورات ماشین مجازی جاوا (JVM) است. هر بایت کد متشکل از یک یا در برخی موارد دو بایت است که نمایانگر دستورات (کد عملیاتی) هستند و همچنین صفر یا تعداد بیشتری بایت که برای گذر پارامترها هستند. -- **Malicious Code** – -کد ارائه شده همراه برنامه در طول توسعه بدون اطلاعات صاحب برنامه‌ی کاربردی که سیاست امنیتی مطلوب برنامه را دور می‌زند. این با بدافزار (malware) همانند ویروس یا کرم (worm) تفاوت دارد. -- **Malware** – کد اجرایی که در طی زمان اجرای برنامه به آن وارد می‌شود بدون اینکه کاربر برنامه کاربردی یا مدیر از آن خبر داشته باشد. -- **Open Web Application Security Project (OWASP)** – پروژه‌ی امنیت برنامه‌ی کاربردی باز (OWASP) یک جامعه‌ی آزاد در سطح جهانی است که بر بهبود امنیت نرم‌افزار تمرکز دارد.مـأموریت ما "قابل رویت" ساختن امنیت برنامه‌ی کاربردی است، به طوری که مردم و سازمان‌ها بتوانند تصمیمات آگاهانه‌ای درباره‌ی مخاطرات امنیت برنامه‌ی کاربردی بگیرند. مشاهده کنید: -- **Personally Identifiable Information (PII)** – - (اطلاعات قابل شناسایی خصوصی) اطلاعاتی است که می‌تواند به خودی خود و یا همراه با سایر اطلاعات جهت شناسایی، برقراری ارتباط یا یافتن مکان یک شخص و یا شناسایی شرایط یک فرد مورد استفاده قرار گیرد. -- **Position-Independent Executable (PIE)** – اجرایی مستقل از مکان، یک بدنه کد زبان ماشین است که جایی در حافظه‌ی اصلی قرار می‌گیرد و بدون توجه به آدرس مطلق آن اجرا می‎شود. -- **Public Key Infrastructure (PKI)** – -یک PKI آرایشی است که کلیدهای عمومی را با هویت مربوط به موجودیت‌ها تحت انقیاد در می‌آورد. انقیاد از طریق یک فرایند ثبت نام و صدور گواهینامه‌ها در یک مرجع صدور گواهینامه (CA) و توسط آن انجام می‌شود. -- **Static Application Security Testing (SAST)** – آزمون امنیت برنامه‌ی ایستا (SAST) مجموعه‌ای از فناوری‌ها است که برای تجزیه و تحلیل کد منبع برنامه‌ی کاربردی، بایت کد و باینری‌ها، برای کد نویسی و طراحی شرایطی که نمایانگر آسیب‌پذیری‌های امنیتی هستند طراحی شده است. راه حل‌های SAST، یک برنامه‌ی کاربردی را از پشت و رو، در حالتی که برنامه در حال اجرا نیست تجزیه و تحلیل می‌کنند. -- **SDLC** – چرخه‌ی حیات توسعه‌ی نرم‌افزار. -- **Security Architecture** – -انتزاعی از طراحی یک برنامه‌ی کاربردی است که شناسایی و توصیف می‌کند که کنترل‌های امنیتی چگونه استفاده شده‌اند و همچنین مکان و حساسیت هر دو کاربر و داده‌ی برنامه را شناسایی و توصیف می‌کند . -- **Security Configuration** – پیکربندی زمان اجرای یک برنامه‌ی کاربردی که چگونگی استفاده از کنترل‌های امنیتی را تحت تأثیر قرار می‌دهد. -- **Security Control** – -تابع یا مؤلفه‌ای که یک ارزیابی امنیتی انجام می‌دهد (به‌عنوان مثال یک چک کردن کنترل دسترسی) و یا موقع فراخوانی موجب یک اثر امنیتی می‌شود. (به‌عنوان مثال تولید یک دنباله‌ی حسابرسی) -- **SQL Injection (SQLi)** – -یک تکنیک تزریق کد که جهت حمله به برنامه‌های کاربردی مبتنی‌بر داده استفاده می‌شود، در این حمله عبارات SQL مخرب به یک نقطه‌ی ورودی تزریق می‌شوند. -- **SSO Authentication** – -شناسایی یگانه (SSO) وقتی رخ می‌دهد که یک کاربر وارد یک سیستم می‌شود و سپس به‌طور خودکار وارد سایر سیستم‌ها می‌شود، بدون توجه به پلتفرم، فناوری یا دامنه‌ای که کاربر استفاده می‌کند. به عنوان مثال وقتی که شما به حساب گوگل خود وارد می‌شوید، به طور خودکار به حساب یوتیوب، docs و سرویس ایمیل خود نیز وارد می‌شوید. -- **Threat Modeling** – -تکنیکی متشکل از توسعه‌ی معماری‌های تصفیه شده امنیت جهت شناسایی عوامل تهدید، حوزه‌های امنیتی، کنترل‌های امنیتی و دارایی‌های فنی و تجاری مهم. -- **Transport Layer Security** – پروتکل‌های رمزنگاری که امنیت ارتباط بر روی اینترنت را تأمین می‌کنند. -- **URI and URL** – -یک شناسانه منبع یکسان، یک رشته از کاراکترها است که برای شناسایی یک نام یا یک منبع استفاده می‌شود. یک شناسانه منبع یکسان گاهی به‌عنوان یک مرجع به یک منبع استفاده می‌شود. -- **User Acceptance Testing (UAT)** – -به‌طور سنتی یک محیط آزمون است که همانند محیط تولید عمل می‌کند. یعنی جایی که تمام آزمون‌های نرم‌افزاری قبل از عملیاتی شدن انجام می‌شوند. -- **Verifier** – یک فرد یا یک تیم که برنامه‌ی کاربردی را در برابر الزامات OWASP MASVS بازبینی می‌کند. -- **Whitelist** – فهرستی از عملیات یا داده‌های مجاز، به‌عنوان مثال فهرستی از کاراکترها که اجازه اعتبار سنجی ورودی دارند. -- **X.509 Certificate** – یک گواهینامه X.509 یک گواهی دیجیتال است که از استاندارد بین الملی X.509 زیرساخت کلید عمومی (PKI) استفاده می‌کند تا بتواند تأیید کند که یک کلید عمومی متعلق به کاربر، کامپیوتر یا هویت سرویس موجود در داخل گواهینامه است. - -
diff --git a/Document-fa/0x91-Appendix-B_References.md b/Document-fa/0x91-Appendix-B_References.md deleted file mode 100644 index f19065ace..000000000 --- a/Document-fa/0x91-Appendix-B_References.md +++ /dev/null @@ -1,18 +0,0 @@ -
- -# پیوست ب: منابع - -پروژه‌های OWASP زیر ممکن است برای کاربران و پذیرندگان این استاندارد مفید باشند. - -- پروژه‌ی امنیت موبایل (OWASP) - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- راهنمای تست امنیت موبایل (OWASP) - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- 10 مخاطره‌ی برتر موبایل (OWASP) - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- جلوگیری از مهندسی معکوس و دستکاری کد (OWASP) - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -به‌طور مشابه، وب‌سایت‌های زیر ممکن است برای کاربران و پذیرندگان این استاندارد مفید باشند: - -- شمارش نقاط ضعف مرسوم (MITRE) - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- انجمن استانداردهای امنیتی (PCI) - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- الزامات استاندارد امنیت داده (DSS) ورژن 3 و فرآیند ممیزی امنیت - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) - -
diff --git a/Document-fa/CHANGELOG.md b/Document-fa/CHANGELOG.md deleted file mode 100644 index ff4f24b4c..000000000 --- a/Document-fa/CHANGELOG.md +++ /dev/null @@ -1,97 +0,0 @@ -
- -# تغییرات - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 March 2020 - انتشار بین المللی - -تغییرات پیش رو قسمتی از انتشار 1.2 می‌باشند: - -- ترجمه ی چینی MASVS در دسترس می‌باشد. -- تغییر عنوان کاور کتاب MASVS. -- حذف Mobile Top 10 و CWE از MSTG و ادغام آن با منابع موجود در MASVS. - -## V1.2-RC - 5 October 2019 - پیش انتشار (فقط انگلیسی) - -تغییرات پیش رو قسمتی از انتشار 1.2 می‌باشند: - -- ارتقاء به وضعیت پرچمدار. -- تغییر الزامات: MSTG-STORAGE-1 نیاز به استفاده شدن دارد. -- الزامات MSTG-STORAGE-13, MSTG-STORAGE-14, و MSTG-STORAGE-15 با تمرکز بر حافظت از داده اضافه شدند. -- الزامات MSTG-AUTH-11 برای نگهداری از اطلاعات وابسته به محتوا به‌روز‌رسانی گردید. -- الزامات MSTG-CODE-4 برای پوشش دادن مباحث بیشتر (نه فقط عیب یابی) به‌روز‌رسانی گردید. -- الزامات MSTG-PLATFORM-10 برای امنیت بیشتر استفاده از WebView اضافه گردید. -- الزامات MSTG-AUTH-12 جهت یادآوری به توسعه‌دهندگان برای داشتن مجوز‌های سطح دسترسی، مخصوصا برای برنامه‌های چند کاربره اضافه گردید . -- اضافه شدن توضیحات بیشتر درخصوص اینکه چگونه از MASVS در ممیزی مخاطره داده شده استفاده شود. -- اضافه کردن توضیحات بیشتر در خصوص محتوای پرداخت. -- الزامات MSTG-ARCH-11 اضافه گردید که شامل یک سیاست پاسخگویی به افشای اطلاعات برای لایه‌ی دوم برنامه‌های کاربردی می‌باشد. -- الزامات MSTG-ARCH-12 اضافه شد تا به توسعه‌دهندگان نرم‌افزار کاربردی، قوانین خط مشی‌های بین المللی که باید دنبال شوند را نشان دهد. -- ساخت یک سبک ثابت برای تمامی منابع در نسخه‌ی انگلیسی. -- الزامات MSTG-PLATFORM-11 جهت شمارش جاسوسی با صفحه‌کلیدهای سوم شخص اضافه گردید. -- الزامات MSTG-MSTG-RESILIENCE-13 جهت جلوگیری از استراق سمع در برنامه‌های کاربردی اضافه گردید. - -## V1.1.4 - 4 July 2019 - ویرایش برتر - -تغییرات پیش رو قسمتی از انتشار 1.1.4 می‌باشند: - -- رفع تمامی مشکلات Markdown. -- به‌روز‌رسانی در ترجم‌های اسپانیایی و فرانسوی. -- ترجمه‌ی تغییرات به چینی (ZHTW) و اسپانیایی. -- وارسی خودکار سینتکس Markdown و در دسترس بودن URL‌ها. -- اضافه شدن کدهای شناسایی برای الزاماتی که به نسخه‌های بعدی MSTG اضافه خواهد شد تا توصیه‌ها و تست‌کیس‌ها راحت تر پیدا شوند. -- کاهش حجم repo و اضافه کردن Generated به .gitignore. -- اضافه کردن یک کد جریان و همکاری راهنما. -- اضافه کردن تمپلیت Pull-Request. -- به‌روز‌رسانی همگام سازی با repo در استفاده توسط میزبانان وبسایت Gitbook. -- به‌روز‌رسانی اسکریپت‌ها برای تولید XML/JSON/CVS برای تمامی ترجمه‌ها. -- ترجمه‌ی پیشگفتار به چینی(ZHTW). - -## V1.1.3 - 9 January 2019 - تعمیرات کوچک - -- رفع مشکلات ترجمه‌ی الزامات 7.1 در نسخه‌ی اسپانیایی -- آماده‌سازی جدید ترجمه‌کنندگان در تصدیق‌ها - -## V1.1.2 - 3 January 2019 - حمایت مالی و بین المللی سازی - -تغییرات پیش رو قسمتی از انتشار 1.1.2 می‌باشند: - -- اضافه کردن متن تشکر برای خریداران کتاب الکترونیکی -- اضافه کردن تاییدیه لینک‌های از دست رفته و لینک‌های به‌روز‌شده‌ی تصدیق‌های منقضی شده در نسخه 4. -- رفع مشکل swap در نسخه‌های 4.7 و 4.8 انگلیسی. -- اولین انتشار بین المللی! - - بهبودسازی ترجمه‌ی اسپانیایی. ترجمه در حال حاضر با انگلیسی همگام سازی گردیده (1.1.2). - - بهبودسازی ترجمه‌ی روسی. ترجمه در حال حاضر با انگلیسی همگام سازی گردیده (1.1.2). - - اضافه شدن اولین انتشار چینی (ZHTW) ، فرانسوی، آلمانی و ژاپنی! -- ساده‌سازی مستندات برای سهولت در ترجمه. -- اضافه شدن دستورالعمل‌هایی برای انتشار خودکار. - -## V1.1.0 - 14 July 2018 - -تغییرات پیش رو قسمتی از انتشار 1.1.0 می‌باشند: - -- الزامات 2.6 "غیر فعال سازی کلیپ بورد در زمینه‌های متنی که ممکن است حاوی اطلاعات حساس باشند" حذف گردید. -- الزامات 2.2 "هیچ اطلاعات حساسی نباید در مخازن خارجی کانتینر برنامه یا امکانات ذخیره‌سازی گواهی‌نامه سیستم ذخیره گردد" اضافه گردید. -- الزامات 2.1 به‌شکل "امکانات ذخیره‌سازی گواهی سیستم به‌صورت اختصاصی برای ذخیره‌ی اطلاعات حساس مانند PII، گواهی کاربر و کلیدهای رمزنگاری استفاده می‌گردد" تغییر پیدا کرد. - -## V1.0 12 - January 2018 - -تغییرات پیش رو قسمتی از انتشار 1.0 می‌باشند: - -- حذف 8.9 همانند 8.12 -- عمومی سازی 4.6 -- بهبودهای کوچک (نگارشی) diff --git a/Document-fa/GLOSSARY.md b/Document-fa/GLOSSARY.md deleted file mode 100644 index 0837b51d3..000000000 --- a/Document-fa/GLOSSARY.md +++ /dev/null @@ -1,165 +0,0 @@ -
- -# پیوست الف - واژه نامه - -## Address Space Layout Randomization (ASLR) - -تکنیکی برای دشوارسازی بهره‌برداری از باگ‌های خرابی حافظه - -## Application Security - -امنیت سطح برنامه کاربردی به جای تمرکز بر به عنوان مثال سیستم عامل پایه یا شبکه‌های متصل شده، بر تجزیه و تحلیل مؤلفه‌هایی که لایه برنامه کاربردی مدل اتصال متقابل سامانه‌های باز (OSI) را تشکیل می‌دهند، تمرکز دارد. - -## Application Security Verification - -یک ارزیابی فنی از برنامه کاربردی در برابر OWASP MASVS - -## Application Security Verification Report - -گزارشی که نتایج نهایی و تجزیه و تحلیل پشتیبان تولید شده توسط تأیید کننده را برای یک برنامه کاربردی خاص مستند سازی می‌کند. - -## Authentication - -وارسی هویت ادعا شده توسط کاربر یک برنامه کاربردی - -## Automated Verification - -استفاده از ابزارهای اتوماتیک (ابزارهای تجزیه و تحلیل پویا و ایستا و یا هر دو) که از امضاهای آسیب‌پذیری جهت یافتن مشکلات استفاده می‌کنند. - -## Black box testing - -یک روش آزمودن نرم‌افزار است که عملکرد یک برنامه کاربردی را بدون دانستن ساختار و نحوه عملکرد داخلی آن بررسی می‌کند. - -## Component - -یک واحد کد جامع همراه با رابط‌های دیسک و شبکه مربوطه که با سایر مؤلفه‌ها ارتباط برقرار می‌کند. - -## Cross-Site Scripting (XSS) - -یک آسیب‌پذیری امنیتی که معمولاً در برنامه‌های تحت وب یافت می‌شود و تزریق اسکریپت‌های سمت کاربر به محتوا را امکان‌پذیر می‌سازد. - -## Cryptographic module - -نرم‌افزار، سخت افزار و یا میان‌افزار که الگوریتم‌های رمزنگاری را پیاده سازی می‌کند و یا کلید‌های رمزنگاری را تولید می‌کند. - -## CWE - -CWE یک لیست توسعه یافته شده توسط جامعه کاربری از ضعف‌های رایج امنیتی نرم‌افزارها است. CWE به عنوان یک زبان مشترک، یک معیار اندازه گیری برای ابزارهای امنیت نرم‌افزار و به عنوان یک خط پایه جهت تلاش برای شناسایی ضعف، کاهش و جلوگیری از آن‌ها است. - -## DAST - -فناوری‌های آزمودن پویای امنیت برنامه کاربردی (DAST) جهت شناسایی شرایط نشان دهنده یک آسیب‌پذیری امنیتی در یک برنامه کاربردی که در حالت اجرایی خود قرار دارد طراحی شده‌اند. - -## Design Verification - -ارزیابی فنی معماری امنیت یک برنامه کاربردی - -## Dynamic Verification - -استفاده از ابزارهای خودکار که از امضاهای آسیب‌پذیری جهت یافتن مشکلات در حین اجرای یک برنامه استفاده می‌کنند. - -## Globally Unique Identifier(GUID) - -یک شماره مرجع یکتا که به عنوان یک کد شناسایی در نرم‌افزار مورد استفاده قرار می‌گیرد. - -## Hyper Text Transfer Protocol(HTTP) - -یک پروتکل برنامه کاربردی است که برای سیستم‌های توزیع شده، مبتنی بر همکاری و سیستم‌های اطلاعات ابر رسانه مورد استفاده قرار می‌گیرد. HTTP بنیان ارتباط داده برای شبکه جهانی وب است. - -## Hardcoded keys - -کلیدهای رمزنگاری که بر روی خود دستگاه ذخیره شده‌اند. - -## IPC - -ارتباطات بین پروسه‌ای، در IPC پروسه‌ها با یکدیگر و کرنل ارتباط برقرار کرده تا فعالیتهای آن‌ها را هماهنگ سازند. - -## Input Validation - -استاندارد سازی و اعتبارسنجی ورودی غیر مطمئن کاربر. - -## JAVA Bytecode - -بایت کد جاوا مجموعه دستورات ماشین مجازی جاوا (JVM) است. هر بایت کد متشکل از یک یا در برخی موارد دو بایت است که نمایانگر دستورات (کد عملیاتی) هستند و همچنین صفر یا تعداد بیشتری بایت که برای گذر پارامترها هستند. - -## Malicious Code - -کد ارائه شده همراه برنامه در طول توسعه بدون اطلاعات صاحب برنامه کاربردی که سیاست امنیتی مطلوب برنامه را دور می‌زند. این با بدافزار (malware) همانند ویروس یا کرم (worm) تفاوت دارد. - -## Malware - -کد اجرایی که در طی زمان اجرای برنامه به آن وارد می‌شود بدون اینکه کاربر برنامه کاربردی یا مدیر از آن خبر داشته باشد. - -## Open Web Application Security Project (OWASP) - -پروژه امنیت برنامه کاربردی باز (OWASP) یک جامعه آزاد در سطح جهانی است که بر بهبود امنیت نرم‌افزار تمرکز دارد.مـأموریت ما "قابل رویت" ساختن امنیت برنامه کاربردی است، به طوری که مردم و سازمان‌ها بتوانند تصمیمات آگاهانه‌ای درباره مخاطرات امنیت برنامه کاربردی بگیرند. مشاهده کنید: - -## Personally Identifiable Information (PII) - -PII (اطلاعات قابل شناسایی خصوصی) اطلاعاتی است که می‌تواند به خودی خود و یا همراه با سایر اطلاعات جهت شناسایی، برقراری ارتباط یا یافتن مکان یک شخص و یا شناسایی شرایط یک فرد مورد استفاده قرار بگیرند. - -## PIE - -اجرایی مستقل از مکان یک بدنه کد زبان ماشین است که جایی در حافظه اصلی قرار می‌گیرد و بدون توجه به آدرس مطلق آن اجرا می‎شود. - -## PKI - -یک PKI مقرراتی است که کلیدهای عمومی را به هویت مربوط به موجودیت‌ها متصل می‌نماید. اتصال از طریق یک فرایند ثبت نام و صدور گواهینامه‌ها در یک مرجع صدور گواهینامه (CA) و توسط آن انجام می‌شود. - -## SAST - -آزمون امنیت برنامه‌ی ایستا (SAST) مجموعه‌ای از فناوری‌ها است که برای تجزیه و تحلیل کد منبع برنامه‌ی کاربردی، بایت کد و باینری‌ها برای کد نویسی و طراحی شرایطی که نمایانگر آسیب‌پذیری‌های امنیتی هستند طراحی شده است. راه حل‌های SAST یک برنامه‌ی کاربردی را از پشت و رو در حالتی که برنامه‌ی در حال اجرا نیست تجزیه و تحلیل می‌کنند. - -## SDLC - -چرخه‌ی حیات توسعه‌ی نرم‌افزار - -## Security Architecture - -انتزاعی از طراحی یک برنامه‌ی کاربردی است که شناسایی و توصیف می‌کند که کنترل‌های امنیتی چگونه استفاده شده‌اند و همچنین مکان و حساسیت هر دو کاربر و داده‌ی برنامه را شناسایی و توصیف می‌کند . - -## Security Configuration - -پیکربندی زمان اجرای یک برنامه‌ی کاربردی که چگونگی استفاده از کنترل‌های امنیتی را تحت تأثیر قرار می‌دهد. - -## Security Control - -تابع یا مؤلفه‌ای که یک ارزیابی امنیتی انجام می‌دهد (به‌عنوان مثال یک چک کردن کنترل دسترسی) و یا در هنگام فراخوانی موجب یک اثر امنیتی می‌شود. (به‌عنوان مثال تولید یک دنباله حسابرسی) - -## SQL Injection (SQLi) - -یک تکنیک تزریق کد که جهت حمله به برنامه‌های کاربردی مبتنی بر داده استفاده می‌شود، در این حمله عبارات SQL مخرب به یک نقطه‌ی ورودی تزریق می‌شوند. - -## SSO Authentication - -شناسایی یگانه (SSO) وقتی رخ می‌دهد که یک کاربر وارد یک سیستم می‌شود و سپس به‌طور خودکار وارد سایر سیستم‌ها می‌شود بدون توجه به پلتفرم، فناوری یا دامنه‌ای که کاربر استفاده می‌کند. به‌عنوان مثال وقتی که شما به حساب گوگل خود وارد می‌شوید، به‌طور خودکار به حساب یوتیوب، docs و سرویس ایمیل خود نیز وارد می‌شوید. - -## Threat Modeling - -تکنیکی متشکل از توسعه‌ی معماری‌های تصفیه شده امنیت جهت شناسایی عوامل تهدید، حوزه‌های امنیتی، کنترل‌های امنیتی و دارایی‌های فنی و تجاری مهم. - -## Transport Layer Security - -پروتکل‌های رمزنگاری که امنیت ارتباط بر روی اینترنت را تأمین می‌کنند. - -## URI and URL - -یک شناسانه‌ی منبع یکسان یک رشته از کاراکترها است که برای شناسایی یک نام یا یک منبع استفاده می‌شود. یک شناسانه منبع یکسان گاهی به‌عنوان یک مرجع به یک منبع استفاده می‌شود. - -## User acceptance testing (UAT) - -به‌طور سنتی، یک محیط آزمون است که همانند محیط تولید عمل می‌کند یعنی جایی که تمام آزمون‌های نرم‌افزاری قبل از عملیاتی شدن انجام می‌شوند. - -## Verifier - -یک فرد یا یک تیم که برنامه‌ی کاربردی را در برابر الزامات OWASP MASVS بازبینی می‌کند. - -## Whitelist - -فهرستی از عملیات یا داده‌های مجاز، به‌عنوان مثال فهرستی از کاراکترها که اجازه‌ی اعتبار سنجی ورودی دارند. - -## X.509 Certificate - -یک گواهینامه X.509، یک گواهی دیجیتال است که از استاندارد بین الملی X.509 زیرساخت کلید عمومی (PKI) استفاده می‌کند تا بتواند تأیید کند که یک کلید عمومی متعلق به کاربر، کامپیوتر یا هویت سرویس موجود در داخل گواهینامه است. - -
diff --git a/Document-fa/SUMMARY.md b/Document-fa/SUMMARY.md deleted file mode 100644 index 8cfa5bcf8..000000000 --- a/Document-fa/SUMMARY.md +++ /dev/null @@ -1,27 +0,0 @@ -
- -# فهرست مطالب - -- [تاریخچه‌ی تغییرات](CHANGELOG.md) -- [پیش گفتار](0x01-Foreword.md) -- [درباره‌ی استاندارد](0x02-Frontispiece.md) -- [استفاده از MASVS](0x03-Using_the_MASVS.md) -- [ارزیابی و گواهینامه](0x04-Assessment_and_Certification.md) - -## الزامات امنیتی - -- [V1: الزامات معماری، طراحی و مدل‌سازی تهدید](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: الزامات ذخیره‌ی داده و حریم خصوصی](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: الزامات رمزنگاری](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: الزامات تصدیق هویت و مدیریت نشست](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: الزامات ارتباطات شبکه](0x10-V5-Network_communication_requirements.md) -- [V6: الزامات تعامل با پلتفرم](0x11-V6-Interaction_with_the_environment.md) -- [V7: الزامات کیفیت کد و تنظیمات ساخت](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: الزامات انعطاف‌پذیری](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## پیوست - -- [پیوست الف - واژه نامه](GLOSSARY.md) -- [پیوست ب - منابع](0x91-Appendix-B_References.md) - -
diff --git a/Document-fa/book.json b/Document-fa/book.json deleted file mode 100644 index 85bb6c7f0..000000000 --- a/Document-fa/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "fa" -} diff --git a/Document-fa/images/CC-license.png b/Document-fa/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-fa/images/CC-license.png and /dev/null differ diff --git a/Document-fa/images/MASVS-levels.png b/Document-fa/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-fa/images/MASVS-levels.png and /dev/null differ diff --git a/Document-fa/images/OWASP_logo.png b/Document-fa/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-fa/images/OWASP_logo.png and /dev/null differ diff --git a/Document-fa/images/license.png b/Document-fa/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-fa/images/license.png and /dev/null differ diff --git a/Document-fa/images/masvs-levels-new.jpg b/Document-fa/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-fa/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-fa/images/masvs-mini-cover.jpg b/Document-fa/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-fa/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-fa/images/masvs-mini-cover.png b/Document-fa/images/masvs-mini-cover.png deleted file mode 100644 index 1e3d72f72..000000000 Binary files a/Document-fa/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-fa/metadata.md b/Document-fa/metadata.md deleted file mode 100644 index 7f51b07bc..000000000 --- a/Document-fa/metadata.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'fa' # bug in the eisvogel template, switch back to english -languagetext: '(Persian Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: 'Table of Content' - -# -# The Nazli font also embeds latin characters -# BUT it does not contain dash ( - ) and tick ( x ) -# -# see https://fontlibrary.org/fr/font/nazli -# -# This means these characters must replaced in the Persian -# translation -# -mainfont: 'Nazli' -sansfont: 'Nazli' -monofont: 'Noto Sans Mono' - ---- diff --git a/Document-fr/0x01-Foreword.md b/Document-fr/0x01-Foreword.md deleted file mode 100644 index 51f510a40..000000000 --- a/Document-fr/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Avant-propos - -Les révolutions technologiques peuvent arriver vite. Il y a moins de dix ans, les smartphones n'étaient que des appareils poussifs avec de petits claviers - des jouets onéreux pour hommes d'affaire passionés par la tech. Pourtant, aujourd'hui, les smartphones font partie intégrante de notre vie. Nous dépendons d'eux pour les informations, la navigation et la communication, et ils sont omniprésents aussi bien dans notre vie professionnelle que dans notre vie sociale. - -Chaque nouvelle technologie introduit de nouveaux risques liés à la sécurité, et se maintenir à l'état de l'art est l'un des principaux défis de l'industrie de la sécurité. Le côté défensif est toujours un peu en retard. Par exemple, le réflexe naturel de beaucoup est d'appliquer toujours les mêmes recettes : les smartphones ressemblant à de petits ordinateurs et les applications mobiles étant du logiciel assez classique, les exigences de sécurité doivent donc être à peu près identiques? Hélas, cela ne marche pas comme ça. Les systèmes d'exploitation des smartphones sont différents de ceux des ordinateurs traditionnels et les applications mobiles sont différentes des applications web. Par exemple, la méthode classique consistant à scanner un appareil à la recherche de virus en se basant sur leur signature n'a pas de sens dans les environnements mobiles modernes : ceci est non seulement incompatible avec le modèle de distribution des applications mobiles, mais c'est aussi techniquement impossible à réaliser en raison des restrictions "bac à sable". Par ailleurs, certaines classes de vulnérabilité telles que les débordements de tampon et autres failles XSS, sont moins pertinentes dans le contexte des applications mobiles ordinaires que, disons, pour les applications PC ou web (toutefois avec certaines exceptions). - -Au fil du temps, notre industrie a progressé sur la connaissance de l'écosystème de menaces dans le mobile. En fait, la sécurité mobile est centrée sur la protection des données : les applications stockent nos données personnelles, nos photos, nos enregistrements, nos notes, les données concernant nos différents comptes, de l'information professionnelle, notre localisation et bien plus. Elles se comportent comme des clients qui nous connectent aux services que nous utilisons chaque jour et centralisent tous les messages que nous échangeons avec les autres. Parvenir à pirater un smartphone revient à avoir un accès illimité à la vie d'une personne. En prenant en compte que les appareils mobiles sont plus couramment perdus ou volés et que les logiciels malveillants sur mobile sont en augmentation, le besoin de protection des données devient d'autant plus important. - -Un standard de sécurité pour les applications mobiles doit donc se focaliser sur la manière dont les applications mobiles gèrent, stockent et protectent les informations sensibles. Même si les systèmes d'exploitation mobiles modernes comme iOS et Android offrent de bonnes APIs concernant la sécurité du stockage des données et la communication, celles-ci doivent toutefois être correctement implémentées et utilisées afin d'être efficaces. Le stockage de données, la communication inter-processus, la bonne utilisation des API de cryptographie et la sécurité des communications réseau sont seulement quelques aspects sur lesquels il convient de se concentrer. - -Une question importante en souffrance d'un consensus de la part de l'industrie de la sécurité est de savoir jusqu'à quel point il faut protéger la confidentialité et l'intégrité des données. Par exemple, la plupart d'entre nous serait d'accord sur la nécessité pour l'application mobile de vérifier le certificat délivré par un serveur lors d'un échange TLS. Mais qu'en est-il concernant l'épinglage des certificats? Ne pas le faire entraîne t-il une vulnérabilité? Cela doit-t-il être une exigence si une application comporte des données sensibles, ou est-ce même contre-productif? A-t-on besoin de crypter les données stockées dans des bases de données SQLite, même si le système d'exploitation exécute l'application dans un bac à sable? Ce qui est pertinent pour une application peut être irréaliste pour une autre. Le MASVS est un essai pour standardiser ces exigences en utilisant des niveaux de validation différents pour différents scenarii de menaces. - -De plus, l'apparition de logiciels malveillants de niveau système et autres outils d'administration à distance a entraîné la prise de conscience que les systèmes d'exploitation mobiles ont eux aussi des failles de sécurité exploitables, contribuant à la hausse de l'utilisation de stratégies de compartementalisation pour la mise en place de protections supplémentaires pour la sauvegarde des données sensibles et contre la manipulation côté client. Et c'est là que les choses deviennent compliquées : les mécanismes de sécurité matériels et les solutions de compartementalisation au niveau du système d'exploitation, telles que Android for Work et Samsung Knox, existent, mais ne sont pas disponibles pour tous les types d'appareils. Une solution de secours est d'implémenter des mesures de protection logicielles, mais il n'y a malheureusement pas de standard ou de processus de test pour valider ce genre de protections. - -Par conséquent, les rapports de test de sécurité des applications mobiles vont dans tous les sens : par exemple, certains testeurs considèrent un manque d'obscurcissement ou de détection de rootage dans une application Android en tant que "faille de sécurité". Par ailleurs, des mesures telles que le cryptage des chaînes de texte, la détection de déboggage ou l'obscurcissement du contrôle du flux ne sont pas considérées obligatoires. Pourtant, cette façon binaire de voir les choses n'a pas de sens dans la mesure où la résilience n'est pas une proposition binaire : elle dépend des menaces spécifiques côté client contre lesquelles se défendre. Les protections de niveau logiciel ne sont pas inutiles mais peuvent toujours être contournées ; elles ne doivent donc pas être utilisées en tant que substitut aux contrôles de sécurité. - -Le but général du MASVS est de proposer un cadre de base pour la sécurité des applications mobiles (MASVS- L1), tout en permettant le rajout de mesures de défense en profondeur (MASVS-L2) et de protections contre les menaces côté client (MASVS-R). Le MASVS a les buts suivants : - -- Fournir des exigences aux architectes logiciels et aux développeurs ayant pour but de développer des applications mobiles avec un bon niveau de sécurité ; -- Proposer un standard pouvant être utilisé comme référence lors de la revue de la sécurité des applications mobiles ; -- Clarifier le rôle des mécanismes de protection logiciels pour la sécurité mobile et fournir des exigences pour valider leur efficacité ; -- Fournir des recommendations spécifiques concernant le niveau de sécurité à viser en fonction du cas d'utilisation. - -Nous sommes conscients du fait qu'un consensus à 100% de la part de l'industrie est impossible à atteindre. Néanmoins, nous espérons que le MASVS sera utile dans les directions qu'il fournit le long de toutes les phases de développement et de test des applications mobiles. En tant que standard ouvert, le MASVS évoluera au fil du temps et toutes les contributions et les suggestions sont les bienvenues. - -Par Bernhard Mueller diff --git a/Document-fr/0x02-Frontispiece.md b/Document-fr/0x02-Frontispiece.md deleted file mode 100644 index 50e56842e..000000000 --- a/Document-fr/0x02-Frontispiece.md +++ /dev/null @@ -1,52 +0,0 @@ -# A Propos du Standard - -![OWASP Logo](images/OWASP_logo.png) - -Bienvenue sur le Mobile Application Security Verification Standard (MASVS), le Standard de Validation de la Sécurité des Applications Mobiles. Le MASVS est un effort communautaire dont le but est d'établir un cadre concernant les exigences de sécurité pour le design, le développement et le test de sécurité des applications mobiles sur iOS et Android. - -Le MASVS est l'aboutissement d'un effort communautaire et de retours d'expérience venant du monde de l'industrie. Le but de ce standard est d'évoluer dans le temps et, dans ce cadre, tout retour est le bienvenu. Le meilleur moyen de rentrer en contact avec nous est via le canal Slack OWASP Mobile Project: - -Un compte peut être créé à l'endroit suivant: . - -## Copyright et Licence - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Ce document est publié sous la licence Creative Commons Attribution ShareAlike 4.0 International. Pour toute ré-utilisation ou distribution, il est obligatoire d'attribuer la licence de ce travail aux auteurs. - - - -## Remerciements - -| Chef de Projet | Auteur Principal | Contributeurs et Relecteurs -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| La langue | Traducteurs et relecteurs | -| --------------- | ------------------------------------------------------------ | -| Allemand | Rocco Gränitz, Sven Schleier (Review) | -| Chinois (Traditionnel) | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| Chinois (Simplifié) | Bob Peng, Harold Zang, Jack S | -| Coréen | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| Espagnol | Martin Marsicano, Carlos Holguera | -| Français | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| Japonais | Koki Takeyama, Riotaro Okada (Review) | -| Persane | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| Portugais | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Portugais brésilien | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Russe | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Turc | Anıl Baş, Haktan Emik | -| Grec | Panagiotis Yialouris | - -Ce document est basé sur le Standard de Validation de la Sécurité Applicative de l'OWASP, le OWASP Application Security Verification Standard écrit par Jim Manico. - -## Sponsors - -Tant le MASVS que le MASTG ont été créés et sont maintenus par la communauté sur le principe du bénévolat ; ceci dit, un peu d'aide extérieure est parfois nécessaire. Par conséquent, nous remercions nos sponsors de nous avoir fourni les fonds pour pouvoir employer des éditeurs techniques. Il est toutefois important de souligner que leur aide financière n'influence pas le contenu des documents MASVS et MASTG de quelque manière que ce soit. Les conditions de parrainage sont décrites sur le [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -Enfin, nous voudrions remercier toutes les personnes qui ont acheté le livre à [Leanpub](https://leanpub.com/mobile-security-testing-guide) et qui nous ont parrainé de cette manière. diff --git a/Document-fr/0x03-Using_the_MASVS.md b/Document-fr/0x03-Using_the_MASVS.md deleted file mode 100644 index 18ddf7d69..000000000 --- a/Document-fr/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,85 +0,0 @@ -# Le Standard de Validation de la Sécurité des Applications Mobiles - -Le MASVS peut être utilisé pour établir un niveau de confiance dans la sécurité des applications mobiles. Les exigences ont été développées avec les objectifs suivants à l'esprit : - -- Utilisation en tant que métrique - Fournir un standard de sécurité pouvant servir de mesure aux développeurs d'applications mobiles et à ceux qui en sont responsables ; -- Utilisation en tant que référence - Donner des points de repère pendant toutes les phases de développement de test et de développement d'applications mobiles ; -- Utilisation en phase d'achat - Permettre de définir un niveau de sécurité minimal attendu lors de la validation de la sécurité d'applications mobiles. - -## Modèle de Sécurité Applicative Mobile - -Le MASVS définit deux niveaux distincts de validation de la sécurité (L1 et L2) ainsi qu'un ensemble flexible d'exigences concernant la protection contre la rétro-ingénierie (MASVS-R), c'est-à-dire adaptable au modèle de menaces d'une application. MASVS-L1 et MASVS-L2 comprennent des exigences de sécurité génériques et sont recommandés pour toute application mobile (L1) ainsi que pour celles qui gèrent des données hautement sensibles (L2). MASVS-R couvre des contrôles de protection supplémentaires qui peuvent être mis en oeuvre dans le cas où la protection contre les menaces côté client est l'un des buts du design. - -Atteindre les exigences du niveau MASVS-L1 amène à une application qui suit les bonnes pratiques de sécurité et ne souffre pas des vulnérabilités couramment rencontrées. MASVS-L2 ajoute de nouveaux contrôles en profondeur tels que le SSL pinning, permettant de rendre l'application résistante à des attaques plus sophistiquées - en supposant que les contrôles de sécurité du système d'exploitation mobile sont intacts et que l'utilisateur final n'est pas considéré en tant que l'attaquant potentiel. Implémenter tout ou partie des exigences de protection logicielles de la partie MASVS-R aide à réduire les menaces côté client où l'utilisateur final serait malicieux et/ou lorsque le système d'exploitation mobile serait corrompu. - -**I: Il convient de noter que les contrôles de protection logiciels listés dans le MASVS-R et décrits dans le Guide de Test Mobile de l'OWASP (OWASP Mobile Application Security Testing Guide) peuvent toujours être contournés et ne doivent jamais être utilisés en tant que substituts aux contrôles de sécurité. Leur but est d'apporter des contrôles de protection supplémentaires spécifiques aux menaces d'applications qui remplissent aussi les exigences MASVS L1 ou L2.** - -**II: Il faut noter que les contrôles de protection des logiciels présentés dans le MASVS-R et décrits dans l'OWASP MASTG peuvent finalement être contournés et ne doivent jamais être utilisés comme alternative aux contrôles de sécurité. Par contre, ils sont conçus pour ajouter des contrôles supplémentaires envers des menaces spécifiques pour les applications qui satisfont aux exigences de MASVS-L1 et MASVS-L2.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### Structure du Document - -La première partie du MASVS contient une description du modèle de sécurité et des niveaux de validation disponibles, suivis par des recommandations sur l'utilisation du standard en pratique. Les exigences de sécurité détaillées, ainsi que leurs associations aux niveaux de validation, sont listées dans la seconde partie. Les exigences ont été groupées en huit catégories (V1 à V8) en fonction des objectifs et des périmètres techniques. La nomenclature suivanteest utilisée tout au long du MASVS et du MASTG: - -- *Catégorie de l'exigence :* MASVS-Vx, e.g. MASVS-V2: Stockage de Données et Vie Privée -- *Exigence :* MASVS-Vx.y, e.g. MASVS-V2.2: "Aucune donnée sensible n'est écrite dans les journaux applicatifs." - -### Niveaux de Validation en Détail - -#### MASVS-L1: Sécurité Standard - -Une application mobile qui remplit les exigences de niveau MASVS-L1 implémente les bonnes pratiques de sécurité de développement d'applications mobiles. Elle implémente les exigences de base en termes de qualité de code, de gestion de données sensibles et d'intéraction avec l'environnement mobile. Un processus de test doit être en place pour valider la bonne implémentation des contrôles de sécurité. Ce niveau convient à tout type d'application mobile. - -#### MASVS-L2: Défense en Profondeur - -MASVS-L2 introduit des contrôles de sécurité plus poussés qui vont au delà des exigences courantes. Pour atteindre le niveau L2, un modèle de menaces doit exister et la sécurité doit faire partie intégrale de l'architecture de l'application et de son design. Ce niveau est approprié pour des applications qui manipulent des données sensibles telles que les applications mobiles bancaires. - -#### MASVS-R: Résistance à la Rétro-Ingénierie et à la Manipulation - -L'application implémente des contrôles au niveau de l'état de l'art en matière de sécurité, et est aussi résistante à des attaques clairement spécifiques au côté client telles que la manipulation, le moddage ou la rétro-ingénierie visant à extraire des parties de code ou des données sensibles. Une telle application met en oeuvre des fonctions de sécurité matérielles ou des techniques de protection logicielles vérifiables et offrant un bon niveau de robustesse. MASVS-R est applicable aux applications qui gèrent des données sensibles et peut servir de moyen de protection de propriété intellectuelle ou contre la manipulation d'une application. - -### Utilisation Recommandée - -Les applications peuvent être validées par rapport à MASVS L1 ou L2 en fonction des évaluations de risque précédentes et du niveau de sécurité requis. L1 s'applique à tout type d'application mobile tandis que L2 est générallement recommandé pour des applications qui gèrent des données ou des fonctionnalités plus sensibles. MASVS-R (ou du moins une partie) peut être appliqué pour la validation de la résistance à des menaces spécifiques telles que le ré-empaquetage ou l'extraction de données sensibles, *en plus* d'une validation de sécurité appropriée. - -En résumé, les typologies de validation suivantes sont disponibles : - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Les différents combinaisons reflètent différents niveaux de sécurité et de résistance. Le but est de permettre une certaine flexibilité : par exemple, un jeu sur mobile pourrait se permettre de ne pas ajouter les contrôles de sécurité MASVS-L2 tels que l'authentification à 2 facteurs pour des considérations de facilité d'utilisation mais pourrait avoir de forts besoins commerciaux concernant la protection contre la manipulation. - -#### Determiner la Typologie de Validation à Utiliser - -L'implémentation des exigences MASVS L2 améliore la sécurité, mais peut en même temps augmenter les coûts de développement et dégrader potentiellement l'expérience utilisateur (un compromis classique). En général, L2 devrait être utilisé pour toute application où l'analyse risques vs coûts démontre le besoin d'atteindre ce niveau (i.e. lorsque les pertes potentielles causées par la compromission de la confidentialité ou de l'intégrité sont supérieures au coût induit par l'implémentation des contrôles de sécurité supplémentaires). L'évaluation des risques devrait être la première étape avant l'implémentation du MASVS. - - - -##### Exemples - -###### MASVS-L1 - -- Pour tout type d'application mobile. MASVS-L1 liste les bonnes pratiques de sécurité qui peuvent être suivies avec un impact raisonnable sur les coûts de développement et l'expérience utilisateur. Il est conseillé d'appliquer les exigences de MASVS-L1 pour toute application qui n'a pas vocation à implémenter les exigences des niveaux supérieurs. - -###### MASVS-L2 - -- Industrie de la Santé : Applications mobiles qui stockent des données personnelles (PII) pouvant être utilisées pour du vol d'identité, des paiements frauduleux ou tout autre type de fraude. Pour le secteur de la santé américain, les considérations de conformité incluent Health Insurance Portability and Accountability Act (HIPAA) ainsi que les règlementations sur le respect de la vie privée, la sécurité, la notification des pertes de données et la sûreté des patients. - -- Industrie Financière : Applications mobiles qui donnent accès à des informations hautement sensibles telles que des numéros de cartes de crédit, des informations personnelles ou permettent des mouvements de fonds. Ces applications justifient l'implémentation de contrôles de sécurité additionnels pour contrer la fraude. Les applications du monde de la finance doivent être conformes au standard Payment Card Industry Data Security Standard (PCI DSS), au Gramm Leech Bliley Act et au Sarbanes-Oxley Act (SOX). - -###### MASVS L1+R - -- Applications mobiles où la protection de la propriété intellectuelle est un objectif commercial. Les contrôles contribuant à la résistance listés dans MASVS-R peuvent être utilisés pour augmenter la quantité d'effort requis pour obtenir le code source d'origine et pour entraver les possibilités de manipulation / de piratage. - -- Industrie du Jeu : Jeux présentant un fort besoin d'empêcher le moddage et la triche, tels que les jeux de compétition en ligne. La triche est un problème majeur pour les jeux en ligne dans la mesure où un nombre important de tricheurs peut amener à mécontenter la majorité des joueurs et peut entraîner l'échec d'un jeu. MASVS-R fournit des contrôles de base contre la manipulation pour rendre la possibilité de triche plus compliquée. - -###### MASVS L2+R - -- Industrie Financière : Applications de banque en ligne permettant aux utilisateurs de transférer des fonds et où les techniques d'injection de code et d'instrumentation sur des appareils mobiles compromis entraînent un risque. Dans ce cas, les contrôles du MASVS-R peuvent être mis en oeuvre pour empêcher la manipulation et rendre la vie des créateurs de logiciels malveillants (malwares) plus compliquée. - -- Toute application mobile qui, par design, doit stocker des données sensibles sur l'appareil mobile tout en devant fonctionner pour une large game d'appareils et de versions de systèmes d'exploitation. Dans ce cas, des contrôles de résistance peuvent être utilisés en tant que mesures de défense en profondeur pour augmenter la quantité d'effort que doivent fournir les attaquants voulant extraire les données sensibles. - -- Les applications avec des fonctionnalités d'achat intégrées doivent idéalement utiliser le côté serveur et les exigences MASVS-L2 pour protéger le contenu payant. Néanmoins, dans quelques cas il est impossible d'utiliser la protection côté serveur. Dans ce cas, les exigences MASVS+R doivent être appliquées en plus des exigences de base pour augmenter les efforts de la rétro-ingénierie et / ou de la manipulation de code. diff --git a/Document-fr/0x04-Assessment_and_Certification.md b/Document-fr/0x04-Assessment_and_Certification.md deleted file mode 100644 index 9b7aa1eca..000000000 --- a/Document-fr/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# Evaluation et Certification - -## Position de l'OWASP Concernant la Certification selon le MASVS et les Labels de Confiance - -L'OWASP, en tant qu'organisation à but non-lucratif et indépendante de toute influence commerciale, ne certifie aucun fournisseur, aucun organisme de référence ni aucun logiciel. - -Toute sorte de garantie de confiance, label ou autre certification n'est pas cautionnée, soutenue ou donnée par l'OWASP ; ainsi toute organisation se reposant sur une telle approche doit être attentive à la confiance accordée à une tierce partie ou à un label de confiance affirmant avoir la certification ASVS. - -Ceci ne doit pas empêcher les organisations d'offrir de tels services concernant la confiance, tant qu'elles ne revendiquent pas une certification officielle de la part de l'OWASP. - -## Conseils pour la Certification d'Applications Mobiles - -La façon recommandée pour vérifier la conformité d'une application mobile par rapport au MASVS est d'efffectuer une revue en mode "livre ouvert", ce qui signifie que les testeurs ont accès aux ressources clés telles que les architectes et les développeurs de l'application, la documentation du projet, le code source et un accès authentifié aux points terminaux, comprenant au moins un accès à un compte pour chaque rôle. - -Il est important de noter que le MASVS ne couvre que les (côtés clients des) applications mobiles et leur communication avec les points terminaux distants, ainsi que quelques exigences génériques liées à l'authentification des utilisateurs et à la gestion des sessions. Il ne contient pas d'exigence spécifique aux services distants (e.g. services web) associés à l'application, à l'exception d'un nombre limité d'exigences génériques ayant trait à l'authentification et à la gestion des sessions. Ceci dit, le MASVS V1 spécifie le fait que les services distants doivent être couverts par un modèle de menaces d'ensemble et doivent être validés par des standards appropriés tels que l'ASVS de l'OWASP. - -Une organisation certifiante doit inclure dans tout rapport le périmètre de la validation (en particulier quand un composant clé est hors de ce périmètre), un résumé des points principaux, incluant les tests passés avec succès ou en échec, avec de claires indications sur la manière de résoudre les tests en échec. La conservation de documents de travail détaillés, de copies d'écran ou de vidéos, de scripts permettant d'exploiter une vulnérabilité de façon fiable et répétée ainsi que de documents électroniques liés aux tests, tels que les journaux d'interception de proxies et les notes associées telles que les listes d'actions, est considérée comme une pratique standard de l'industrie. Il n'est pas suffisant de lancer simplement un outil et de faire un rapport sur les défauts signalés ; ceci n'amène pas suffisamment de preuves que tous les points pour un niveau de certification donné ont été testés de façon adéquate. En cas de désaccord, il devrait assez de preuves pour démontrer que chaque exigence validée a bien été testée. - -### Utiliser le Guide de Test de Sécurité Mobile OWASP Mobile Application Security Testing Guide (MASTG) - -Le MASTG de l'OWASP est un manuel pour tester la sécurité des applications mobiles. Il décrit les processus techniques pour valider les exigences listées dans le MASVS. Le MASTG comporte une liste de cas de tests, chacun relié à une exigence du MASVS. Tandis que les exigences du MASVS sont de haut niveau et génériques, le MASTG fournit des recommandations en profondeur et des procédures de test par type de système d'exploitation mobile. - -### Le Role des Outils de Test Automatique - -L'utilisation d'outils d'analyse de code source ou de test en boîte noire est encouragé dans le but d'améliorer l'efficacité dès que cela est possible. Cependant, il n'est pas possible de mener à bien toute la validation proposée par le MASVS en utilisant seulement des outils automatiques : chaque application mobile a ses spécificités et la compréhension de l'architecture d'ensemble, la logique d'affaire et les limites techniques des technologies et frameworks utilisés est obligatoire pour valider la sécurité d'une application. - -## Autres Cas d'Utilisation - -### En tant que Source de Conseils Détaillés pour l'Architecture de Sécurité - -L'une des utilisations les plus courantes du MASVS est en tant que ressource pour les arhitectes de sécurité. Les deux référentiels principaux d'architecture de sécurité, SABSA et TOGAF, ne fournissent pas beaucoup d'information qui serait nécessaire à la revue de l'architecture de sécurité des applications mobiles. Le MASVS peut être utilisé pour combler ces manques en permettant aux architectes de sécurité de choisir de meilleurs contrôles par rapport aux problèmes courants des applications mobiles. - -### En tant que Substitut aux Listes de Contrôle pour le Codage de Sécurité - -Un certain nombre d'organisations peuvent bénéficier de l'adoption du MASVS en choisissant l'un des deux niveaux, ou en s'appropriant le MASVS et en adaptant ce qui est nécessaire à chaque niveau de risque en fonction du domaine d'application ciblé. Nous encourageons ce type d'appropriation tant que la traçabilité est maintenue, de telle manière que si une application a passé l'exigence 4.1 la signification reste la même pour chaque copie lorsque le standard évolue. - -### En tant que Base Méthodologique pour le Test de Sécurité - -Une bonne méthodologie de test de sécurité pour application mobile devrait couvrir l'ensemble des exigences listées dans le MASVS. Le Mobile Application Security Testing Guide (MASTG) de l'OWASP fournit des cas de test en boîte noire et en boîte blanche pour la validation de chaque exigence. - -### En tant que Guide pour les Tests Automatisés et les Tests d'Intégration - -Le MASVS a été créé pour être hautement testable, à la seule exception des exigences architecturales. Les tests unitaires, d'intégration et d'acceptation basés sur lex exigences du MASVS peuvent être intégrés dans le cycle de développement continu. Ceci permet d'une part d'améliorer la sensibilisation à la sécurité des développeurs, mais aussi d'autre part d'améliorer la qualité globale de l'application cible et de réduire la quantité de défauts détectés pendant la phase de tests de sécurité avant la mise sur le marché. - -### Pour la Formation au Développement de Sécurité - -Le MASVS peut aussi être utilisé pour définir les caractéristiques de sécurité des applications mobiles. Un certain nombre de cours de "codage de sécurité" sont juste des cours de piratage éthique avec un soupçon de développement. Ceci n'est pas en faveur des développeurs. Au lieu de cela, les cours de développement de sécurité peuvent utiliser le MASVS, en se focalisant sur les contrôles proactifs documentés dans le MASVS, plutôt que par exemple sur les 10 principales erreurs de sécurité en développement. diff --git a/Document-fr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-fr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index e8e64c6a6..000000000 --- a/Document-fr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: Exigences Concernant l'Architecture, le Design et le Modèle de Menaces - -## Objectif de Contrôle - -Dans un monde parfait, la sécurité serait prise en compte tout au long du cycle de développement. Cependant, en réalité la sécurité n'est une considération que tardivement dans le SDLC. Au delà des contrôles techniques, le MASVS exige que des processus soient en place pour garantir que la sécurité a bien été explicitement prise en compte lors de la préparation de l'architecture de l'application mobile et que, pour l'ensemble des composants, les roles fonctionnels et liés à la sécurité sont connus. Dans la mesure où la plupart des applications mobiles agissent en tant que clients de services distants, il est nécessaire de s'assurer que des standards de sécurité pertinents sont aussi appliqués à ces services - tester l'application mobile de manière isolée n'est pas suffisant. - -La catégorie “V1” liste les exigences relatives à l'architecture et au design de l'application. Par conséquent, c'est la seule catégorie qui n'est pas reliée à des cas de test techniques dans le Mobile Testing Guide de l'OWASP. Afin de traiter des sujets tels que le modèle de menaces, le SDLC de sécurité, la gestion des clés, le lecteur du MASVS est invité à consulter les projets de l'OWASP dédiés à ces sujets et/ou d'autres standards tel que ceux listés ci-dessous. - -## Exigences pour la Validation de la Sécurité - -Les exigences pour MASVS-L1 et MASVS-L2 sont listées ci-dessous. - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Tous les composants de l'application sont identifiés et leur besoin est confirmé. | x | x | -| **1.2** | MSTG-ARCH-2 | Les contrôles de sécurité ne sont jamais mis en oeuvre seulement côté client, mais aussi sur les points terminaux distants. | x | x | -| **1.3** | MSTG-ARCH-3 | Une architecture de haut niveau concernant l'application mobile et tous les services distants utilisés a été définie et la sécurité a été prise en compte dans cette architecture. | x | x | -| **1.4** | MSTG-ARCH-4 | Les données considérées comme sensibles dans le contexte de l'application mobile sont clairement identifiées. | x | x | -| **1.5** | MSTG-ARCH-5 | Tous les composants de l'application sont définis en termes des fonctions métier et/ou de sécurité qu'ils apportent. | | x | -| **1.6** | MSTG-ARCH-6 | Un modèle de menaces pour l'application mobile et les services distants associés a été livré et définit les menaces potentielles et les contre-mesures associées. | | x | -| **1.7** | MSTG-ARCH-7 | Tous les contrôles de sécurité ont une implémentation centralisée. | | x | -| **1.8** | MSTG-ARCH-8 | Il existe une politique explicite sur la façon de gérer les clés de cryptographie (dès qu'elles existent) tout au long de leur cycle de vie. Idéalement, un standard de gestion des clés est suivi (tel que NIST SP 800-57). | | x | -| **1.9** | MSTG-ARCH-9 | Un mécanisme pour permettre les mises à jour de l'application mobile existe. | | x | -| **1.10** | MSTG-ARCH-10 | La sécurité est prise en compte tout au long du cycle de développement. | | x | -| **1.11** | MSTG-ARCH-11 | Une politique de divulgation responsable est mise en place et appliquée d'une manière efficiente. | | x | -| **1.12** | MSTG-ARCH-12 | L'application doit se conformer aux lois et règlementations de confidentialité. | x | x | - -## Références - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M10 (Fonctions superflues) - -- OWASP Thread modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-fr/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-fr/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 74339646a..000000000 --- a/Document-fr/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Exigences Concernant le Stockage des Données et le Respect de la Vie Privée - -## Objectif de Contrôle - -La protection des données sensibles telles que les références utilisateurs et autres informations privées est un point d'attention central dans la sécurité mobile. Tout d'abord, les données sensibles peuvent être accidentellement exposées à d'autres applications fonctionnant sur le même appareil si des mécanismes du système d'exploitation tels que la communication inter-processus sont utilisés d'une mauvaise manière. Des données peuvent aussi accidentellement fuiter vers le stockage en nuage, les sauvegardes ou le cache. Aussi, les appareils mobiles peuvent être perdus ou volés plus facilement que les autres types d'appareils, renforçant la probabilité qu'un attaquant ait un accès physique à l'appareil. Dans ce cas, des protections supplémentaires peuvent être implémentées pour rendre l'accès aux données sensibles plus difficile. - -Il faut noter que, dans la mesure où le MASVS se concentre sur l'application, il ne couvre pas les politiques du niveau de l'appareil telles que celles mises en oeuvre par les solutions de MDM (Mobile Device Management). L'utilisation de telles politiques est encouragée dans le contexte de l'entreprise pour améliorer la sécurité des données. - -### Définition des Données Sensibles - -Dans le contexte du MASVS, les données sensibles ont trait aux deux aspects que sont les références utilisateurs ainsi que toute autre donnée considérée comme sensible dans un contexte particulier tel que : - -- Information personnellement identifiable (PII) qui peut être utilisée pour un vol d'identité : numéros de sécurité sociale, numéros de carte de crédit, numéros de comptes bancaires, information de santé ; -- Information hautement sensible pouvant amener à une perte de réputation et/ou un coût financier si elle était divulguée : information contractuelle, information sous le coup de clauses de non-divulgation, information de gestion ; -- Toute information devant être protégée légalement ou pour des raisons de conformité. - -## Exigences pour la Validation de la Sécurité - -La grande majorité des problèmes de divulgation de données peuvent être empêchés en suivant des règles simples. La plupart des contrôles listés dans ce chapitre sont obligatoires pour tous les niveaux de validation. - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Les fonctions de stockage sécurisées proposées par les systèmes doivent être utilisées de manière appropriée pour stocker les données sensibles tels que les informations personnellement identifiables (PII), les références des utilisateurs ou les clés cryptographiques. | x | x | -| **2.2** | MSTG-STORAGE-2 | Aucune donnée sensible ne devrait être stockée hors du conteneur de l'application ou des fonctions de stockage sécurisées proposées par le système. | x | x | -| **2.3** | MSTG-STORAGE-3 | Aucune donnée sensible n'est écrite dans les journaux applicatifs. | x | x | -| **2.4** | MSTG-STORAGE-4 | Aucune donnée sensible n'est partagée avec des tierces parties à moins que cela ne soit un besoin de l'architecture. | x | x | -| **2.5** | MSTG-STORAGE-5 | Le cache du clavier est désactivé sur les champs d'entrée textuels qui traitent de données sensibles. | x | x | -| **2.6** | MSTG-STORAGE-6 | Aucune donnée sensible n'est exposée par les mécanismes d'IPC. | x | x | -| **2.7** | MSTG-STORAGE-7 | Aucune donnée sensible, tels que les mots de passe ou les codes PIN, n'est exposée à travers l'interface utilisateur. | x | x | -| **2.8** | MSTG-STORAGE-8 | Aucune donnée sensible n'est incluse dans les sauvegardes générées par le système d'exploitation mobile. | | x | -| **2.9** | MSTG-STORAGE-9 | L'application enlève les données sensibles des vues lors de son passage en arrière-plan. | | x | -| **2.10** | MSTG-STORAGE-10 | L'application ne garde pas les données sensibles en mémoire plus longtemps que nécessaire et la mémoire est explicitement nettoyée après son utilisation. | | x | -| **2.11** | MSTG-STORAGE-11 | L'application met en oeuvre un minimum de politique concernant la sécurité de l'accès à l'appareil tel que l'obligation pour l'utilisateur de définir un code d'accès à l'appareil. | | x | -| **2.12** | MSTG-STORAGE-12 | L'application instruit l'utilisateur sur les types d'information personnellement identifiable traités ainsi que sur les bonnes pratiques que l'utilisateur devrait suivre en utilisant l'application. | x | x | -| **2.13** | MSTG-STORAGE-13 | Aucune donnée sensible ne doit être stockée localement sur l'appareil mobile. Par contre, les données doivent être extraites à partir d'un point terminal distant et stockées seulement en mémoire. | | x | -| **2.14** | MSTG-STORAGE-14 | Si le stockage des données sensibles localement est encore exigé, ces dernières doivent être chiffrées par une clé dérivée d'un stockage matériel qui exige l'authentification. | | x | -| **2.15** | MSTG-STORAGE-15 | Le stockage local de l'application doit être effacé après un nombre excessif de tentatives d'authentification erronées. | | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP donne des instructions détaillées pour valider les exigences listées dans cette section. - -- Pour Android - -- Pour iOS - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-fr/0x08-V3-Cryptography_Verification_Requirements.md b/Document-fr/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index d8b4612cf..000000000 --- a/Document-fr/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Exigences Concernant la Cryptographie - -## Objectif de Contrôle - -La cryptographie est un ingrédient essentiel pour la protection des données stockées sur un appareil mobile. C'est aussi une catégorie pour laquelle les choses peuvent très mal se passer, en particulier quand les conventions standards ne sont pas suivies. Le but des contrôles de ce chapitre est de garantir que les applications à valider implémentent la cryptographie en suivant les bonnes pratiques de l'industrie, notamment : - -- L'utilisation de librairies cryptographiques éprouvées ; -- Le choix et la configuration pertinents des primitives cryptographiques ; -- L'utilisation d'un générateur de nombres aléatoires convenable lorsque cela est nécessaire. - -## Exigences pour la Validation de la Sécurité - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | L'application n'utilise pas la cryptographie symétrique avec des clés codées en dur comme seule méthode de chiffrement.| x | x | -| **3.2** | MSTG-CRYPTO-2 | L'application utilise des implémentations de primitives cryptographiques éprouvées. | x | x | -| **3.3** | MSTG-CRYPTO-3 | L'application utilise des primitives cryptographiques appropriées au cas d'utilisation, configurées en adéquation avec les bonnes pratiques de l'industrie. | x | x | -| **3.4** | MSTG-CRYPTO-4 | L'application n'utilise pas de protocole ou d'algorithme de cryptographie considéré par la communauté comme déprécié pour des raisons de sécurité. | x | x | -| **3.5** | MSTG-CRYPTO-5 | L'application ne ré-utilise pas la même clé de cryptographie à des fins différentes. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Toute valeur aléatoire est générée par un générateur de nombres aléatoires offrant un bon niveau de sécurité. | x | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP donne des instructions détaillées pour valider les exigences listées dans cette section. - -- Android - -- iOS - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-fr/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-fr/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 9867ebde3..000000000 --- a/Document-fr/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Exigences Concernant l'Authentification et la Gestion des Sessions - -## Objectif de Contrôle - -Dans la plupart des cas, la connexion des utilisateurs à un service distant doit être appréhendée au niveau de l'architecture générale des applications mobiles. Même si la majorité de la logique se passe sur le point terminal, le MASVS définit des exigences de base concernant la manière de gérer les comptes et les sessions des utilisateurs. - -## Exigences pour la Validation de la Sécurité - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Si l'application donne accès aux utilisateurs à un service distant, un certain niveau d'authentification, tel que l'authentification par nom d'utilisateur / mot de passe, est faite sur le point terminal distant. | x | x | -| **4.2** | MSTG-AUTH-2 | Si des sessions avec état sont utilisées, le point terminal distant utilise des identifiants de session aléatoirement générés pour authentifier les requêtes des clients sans avoir à envoyer les références des utilisateurs. | x | x | -| **4.3** | MSTG-AUTH-3 | Si l'authentification sans état basée sur des jetons est utilisée, le serveur fournit des jetons qui ont été signés par un algorithme à la sécurité éprouvée. | x | x | -| **4.4** | MSTG-AUTH-4 | Le point terminal distant met fin à la session existante lorsque l'utilisateur se déconnecte. | x | x | -| **4.5** | MSTG-AUTH-5 | Une politique de mot de passe existe et est appliquée sur le point terminal distant. | x | x | -| **4.6** | MSTG-AUTH-6 | Le point terminal distant implémente un mécanisme permettant la protection contre les essais répétés de références utilisateurs. | x | x | -| **4.7** | MSTG-AUTH-7 | Les sessions sont dévalidées sur le point terminal distant après une période d'inactivité donnée et les jetons d'accès associés expirent. | x | x | -| **4.8** | MSTG-AUTH-8 | L'authentification biométrique, lorsqu'elle est utilisée, n'est pas basée sur des évènements (c'est-à-dire l'utilisation d'une API qui retourne simplement "vrai" ou "faux"). A la place, son utilisation est basée sur le déverrouillage du trousseau d'accès / du magasin de clé (keychain / keystore). | | x | -| **4.9** | MSTG-AUTH-9 | Un second facteur d'authentification est disponible sur le point terminal distant et l'exigence d'authentification à deux facteurs est mise en application de façon systématique. | | x | -| **4.10** | MSTG-AUTH-10 | Les transactions sensibles requièrent une authentification améliorée. | | x | -| **4.11** | MSTG-AUTH-11 | L'application informe les utilisateurs de toutes les activités critiques sur leurs comptes. Les utilisateurs ont accès à la liste des appareils utilisés pour accéder à leurs comptes, accès aux informations contextuelles (adresse IP, localisation, etc...), et peuvent bloquer certains appareils. | | x | -| **4.12** | MSTG-AUTH-12 | Des modèles d'autorisation doivent être définis et mis en oeuvre au niveau du point terminal distant. | x | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP (guide de test de la Sécurité mobile) fournit des instructions détaillées pour valider les exigences listées dans cette section. - -- Général : Authentification et gestion des sessions - -- Pour Android : Tester l'authentification locale - -- Pour iOS : Tester l'authentification locale - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-fr/0x10-V5-Network_communication_requirements.md b/Document-fr/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index e3a619e2f..000000000 --- a/Document-fr/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Exigences Concernant la Communication Réseau - -## Objectif de Contrôle - -Le but des contrôles listés dans cette section est de garantir la confidentialité et l'intégrité de l'information échangée entre l'application mobile et les services des points terminaux distants. A minima, une application mobile doit mettre en place un canal sécurisé crypté pour la communication réseau en utilisant le protocole TLS avec les bons paramètres. Le niveau 2 liste des mesures additionnelles de défense en profondeur telles que l'épinglage SSL (SSL pinning). - -## Exigences pour la Validation de la Sécurité - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Les données sont cryptées sur le réseau en utilisant TLS. Le canal sécurisé est utilisé systématiquement à travers toute l'application. | x | x | -| **5.2** | MSTG-NETWORK-2 | Les réglages de TLS sont en ligne avec les meilleures pratiques, ou aussi proches que possible dans le cas où le système d'exploitation ne supporte pas les standards recommandés. | x | x | -| **5.3** | MSTG-NETWORK-3 | L'application valide le certificat X.509 du point terminal distant lors de l'établissement du canal sécurisé. Seuls les certificats signés par une CA de confiance sont acceptés. | x | x | -| **5.4** | MSTG-NETWORK-4 | Soit l'application utilise son propre magasin de certificats, ou bien elle épingle le certificat du point terminal ou sa clé publique, et par là n'établit pas de connexion avec des points terminaux qui proposent des certificats ou des clés différents, même s'ils sont signés par des CA de confiance. | | x | -| **5.5** | MSTG-NETWORK-5 | L'application ne repose pas sur un canal de communication non-sécurisé unique (e-mail ou SMS) pour les opérations critiques telles que l'enregistrement ou la récupération de compte. | | x | -| **5.6** | MSTG-NETWORK-6 | L'application implémente l'état de l'art en termes de connectivité et de librairies de sécurité. | | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP (guide de test de la Sécurité mobile) fournit des instructions détaillées pour valider les exigences listées dans cette section. - -- Général : Tester la communication réseau - -- Android : Tester la communication réseau - -- iOS : Tester la communication réseau - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-fr/0x11-V6-Interaction_with_the_environment.md b/Document-fr/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 382137806..000000000 --- a/Document-fr/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Exigences Concernant les Interactions avec la Plateforme - -## Objectif de Contrôle - -Le but des contrôles de ce groupe est de garantir que l'application utilise les API de la plateforme ainsi que ses composants standards d'une façon compatible avec la sécurité. De plus, les contrôles couvrent la communication entre les applications (IPC). - -## Exigences pour la Validation de la Sécurité - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | L'application ne demande qu'une série minimum de permissions nécessaires. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Toutes les entrées provenant de sources externes ainsi que des utilisateurs sont validées et si nécessaire assainies. Ceci inclut les données reçues via l'interface utilisateur, les mécanismes IPC tel que les intentions, les URL propres à l'application et les sources sur le réseau.| x | x | -| **6.3** | MSTG-PLATFORM-3 | L'application n'exporte pas de fonctionnalité sensible via des schémas d'URL propres à l'application, à moins que ces mécanismes ne soient correctement protégés. | x | x | -| **6.4** | MSTG-PLATFORM-4 | L'application n'exporte pas de fonctionnalité sensible à travers les possibilités IPC, à moins que ces mécanismes ne soient correctement protégés. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript est désactivé dans les WebViews à moins qu'il ne soit explicitement requis. | x | x | -| **6.6** | MSTG-PLATFORM-6 | Les WebViews sont configurées pour ne permettre que le jeu minimum de gestionnaires de protocoles requis (idéalement, seul https est supporté). Les gestionnaires potentiellement dangereux, tels que ceux pour les fichiers, les appels téléphoniques ou l'identifiant de l'application sont désactivés. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Dans le cas où des méthodes natives de l'application sont exposées à une WebView, il convient de valider que la WebView ne rend que le JavaScript contenu dans le package de l'application. | x | x | -| **6.8** | MSTG-PLATFORM-8 | La désérialisation des objets, s'il en existe, est implémentée à l'aide d'API de sérialisation de confiance. | x | x | -| **6.9** | MSTG-PLATFORM-9 | L'application doit se protéger contre les attaques par recouvrement. (Android seulement) | | x | -| **6.10** | MSTG-PLATFORM-10 | Le cache, le stockage et les ressources téléchargées (JavaScript, etc.) d'une WebView doivent être supprimés avant que la WebView soit détruite. | | x | -| **6.11** | MSTG-PLATFORM-11 | Vérifier que l'application n'autorise pas l'utilisation des claviers tiers personnalisés lors de la saisie des données sensibles. (iOS seulement) | | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP (guide de test de la Sécurité mobile) fournit des instructions détaillées pour valider les exigences listées dans cette section. - -- Android : Tester les interactions avec la plateforme - -- iOS : Tester les interactions avec la plateforme - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-fr/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-fr/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 544e19e4d..000000000 --- a/Document-fr/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Exigences Concernant la Qualité du Code et les Paramètres de Génération - -## Objectif de Contrôle - -Le but de ce contrôle est d'assurer que les pratiques de codage de base concernant la sécurité sont suivies pendant le développement de l'application et que les fonctionnalités de sécurité "gratuites" fournies par le compilateur sont activées. - -## Exigences pour la Validation de la Sécurité - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | L'application est signée et livrée avec un certificat en cours de validité, dont la clé privée est correctement protégée. | x | x | -| **7.2** | MSTG-CODE-2 | L'application a été générée en mode release avec des réglages appropriés à ce mode (c.a.d. sans les possibilités de déboggage). | x | x | -| **7.3** | MSTG-CODE-3 | Les symboles pour le déboggage ont été enlevés des binaires natifs. | x | x | -| **7.4** | MSTG-CODE-4 | Le code de déboggage et le code d'assistance au développement (e.g. code de test, portes dérobées, paramètres cachés) ont été enlevés de l'application et celle-ci ne journalise ni de messages d'erreur inutilement longs ni de messages de déboggage. | x | x | -| **7.5** | MSTG-CODE-5 | Tous les composants utilisés par l'application provenant de sources externes, notamment les librairies et les frameworks, ont été identifiés et analysés à la recherche de vulnérabilités connues. | x | x | -| **7.6** | MSTG-CODE-6 | L'application intercepte et gère les exceptions potentielles.| x | x | -| **7.7** | MSTG-CODE-7 | La logique de gestion des erreurs dans les contrôles de sécurité refuse tout accès par défaut. | x | x | -| **7.8** | MSTG-CODE-8 | Dans le code non-géré, la mémoire est allouée, libérée et utilisée de façon sécurisée. | x | x | -| **7.9** | MSTG-CODE-9 | Les fonctionnalités de sécurité intégrées dans les outils de la chaîne de génération, par exemple ceux pour la minification de byte-code, pour la protection de la pile, pour le support PIE ou le comptage de références automatiques, sont activées. | x | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP (guide de test de la Sécurité mobile) fournit des instructions détaillées pour valider les exigences listées dans cette section. - -- Android : Tester la qualité du code et les paramètres de génération - -- iOS : Tester la qualité du code et les paramètres de génération - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-fr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-fr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index dc53deae3..000000000 --- a/Document-fr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V8: Exigences Concernant la Résilience - -## Objectif de Contrôle - -Cette section couvre des mesures de défense en profondeur recommandées dans les cas d'applications qui traitent ou donnent accès à des données ou des fonctionnalités sensibles. L'absence de l'un de ces contrôles n'entraîne pas une vulnérabilité dans la mesure où ils ont pour seul but d'améliorer la résilience de l'application envers la rétro-ingénierie et autres attaques spécifiques côté client. - -Les contrôles de cette section devraient être mis en oeuvre autant qu'il est nécessaire, c'est-à-dire tel que requis par une évaluation des risques dûs à une modification non-autorisée de l'application et /ou une rétro-ingénierie du code. Nous ne pouvons que suggérer la consultation du document de l'OWASP "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" ("Risques Techniques Liés à la Rétro-Ingénierie et Modification de Code Non-Autorisée Rétro-Ingénierie et Prévention de Modification de Code", voir les références ci-dessous) pour une liste des risques liés aux affaires et des menaces techniques associées. - -**Il convient de noter que les mécanismes de protection logiciels ne doivent jamais être utilisés en tant que substituts aux contrôles de sécurité. Les contrôles listés dans le MASVR-R ont pour intention de rajouter aux applications des mécanismes de protection supplémentaires, spécifiques à une menace donnée, qui sont compatibles avec les exigences de sécurité du MASVS.** - -Il convient de prendre en compte les considérations suivantes : - -1. Un modèle de menace doit exister et souligner clairement les menaces côté client contre lesquelles il faut se défendre. De plus, le niveau de protection à atteindre doit être spécifié. Par exemple, un but bien défini pourrait être de forcer les auteurs d'un logiciel malveillant ciblant une application et cherchant à l'instrumenter de devoir investir un effort significatif de rétro-ingénierie manuelle. - -2. Le modèle de menaces doit être porteur de sens. Par exemple, cacher une clé de cryptographie dans une implémentation en boîte-blanche n'est pas cohérent dans le cas où l'attaquant a la possiblité de récupérer l'ensemble du code et de l'analyser dans son ensemble. - -3. L'efficacité de la protection devrait toujours être validée par un expert humain ayant l'expérience du test des moyens particuliers mis en oeuvre contre la modification du code ou son obscurcissement (voir aussi les chapitres liés à la "rétro-ingénierie" et à la "validation des protections logicielles" dans le Mobile Application Security Testing Guide). - -### Entraver l'Analyse Dynamique et la Modification - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | L'application détecte et réagit à la présence d'appareils rootés ou jailbreakés soit en alertant l'utilisateur ou en mettant fin à l'application. | x | -| **8.2** | MSTG-RESILIENCE-2 | L'application empêche le déboggage et / ou réagit à la présence d'un déboggeur. Tous les protocoles de déboggage disponibles doivent être couverts. | x | -| **8.3** | MSTG-RESILIENCE-3 | L'application détecte et réagit à la modification de fichiers exécutables et de données critiques au sein de son bac à sable. | x | -| **8.4** | MSTG-RESILIENCE-4 | L'application détecte et réagit à la présence d'outils et de frameworks de rétro-ingénierie courants sur l'appareil.| x | -| **8.5** | MSTG-RESILIENCE-5 | L'application détecte et réagit à son exécution dans un émulateur. | x | -| **8.6** | MSTG-RESILIENCE-6 | L'application détecte et réagit à la modification de code et de données dans son espace mémoire. | x | -| **8.7** | MSTG-RESILIENCE-7 | L'application implémente plusieurs mécanismes parmi les catégories de défense (8.1 à 8.6). Il convient de noter que la résilience augmente avec la quantité et la diversité de l'originalité des mécanismes utilisés. | x | -| **8.8** | MSTG-RESILIENCE-8 | Les mécanismes de détection déclenchent des réponses de différents types, notamment des réponses invisibles de retardement de l'attaque. | x | -| **8.9** | MSTG-RESILIENCE-9 | L'obscurcissement est mis en oeuvre par des défenses programmatiques qui, à leur tour, entravent le dé-obscurcissement via l'analyse dynamique. | x | - -### Liaison avec un Appareil - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | L'application implémente un mécanisme de 'liaison avec l'appareil' utilisant une empreinte de l'appareil dérivée de multiples propriétés uniques à cet appareil. | x | - -### Entraver la Compréhension - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 |Tous les fichiers exécutables et les librairies appartenant à l'application sont soit chiffrés au niveau du fichier et / ou le code important et les segments de données à l'intérieur des exécutables sont chiffrés ou compactés. Une analyse statique triviale ne révèle pas de code important ou de données. | x | -| **8.12** | MSTG-RESILIENCE-12 | Si le but de l'obscurcissement est de protéger des traitements sensibles, le schéma d'obscurcissement utilisé est à la fois approprié à la tâche considérée et est résistant envers les méthodes de dé-obscurcissement manuelles et automatiques, en prenant en considération les recherches disponibles. L'efficacité du schéma d'obscurcissement doit être validée à travers du test manuel. Il convient de noter que les fonctionnalités d'isolation au niveau matériel doivent être mises en pratique de préférence à l'obscurcissement toutes les fois que cela est possible. | x | - -### Entraver l'écoute - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Pour une défense en profondeur, en plus d'avoir un durcissement efficace des parties communicantes, le chiffrement des données utilisées au niveau de l'application peut être appliqué pour entraver l'écoute. | x | - -## Références - -Le Mobile Application Security Testing Guide de l'OWASP (guide de test de la Sécurité mobile) fournit des instructions détaillées pour valider les exigences listées dans cette section. - -- Android : Tester la résilience contre la rétro-ingénierie - -- iOS : Tester la résilience contre la rétro-ingénierie - - -Pour de plus amples informations, il est possible de consulter aussi : - -- OWASP Mobile Top 10: M8 (Modification du Code) - -- OWASP Mobile Top 10: M9 (Rétro-Ingénierie) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-fr/0x90-Appendix-A_Glossary.md b/Document-fr/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 0fff6b574..000000000 --- a/Document-fr/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Annexe A: Glossaire - -- **Distribution Aléatoire de l'Espace D'adressage (ASLR)** – Une technique rendant plus difficiles l'exploitation de défauts permettant la corruption de la mémoire. -- **Sécurité Applicative** – La sécurité de niveau applicatif se focalise sur l'analyse des composants qui constituent la couche applicative du modèle OSI (the Open Systems Interconnection Reference Model), plutôt que de se focaliser par exemple sur le système d'exploitation sous-jacent ou sur les réseaux connectés. -- **Validation de la Sécurité Applicative** – Evaluation technique d'une application par rapport au MASVS de l'OWASP. -- **Rapport de Validation de Sécurité Applicative** – Rapport qui documente les résultats dans leur ensemble ainsi que l'analyse sous-jacente réalisée par le validateur de l'application considérée. -- **Authentification** – Vérification de l'identité clamée par l'utilisateur de l'application. -- **Validation Automatique** – Utilisation d'outils automatisés (outils d'analyse dynamique ou outils d'analyse statique, ou les deux) qui utilisent les signatures des vulnérabilités pour identifier les problèmes. -- **Test en Boîte Noire** – Méthode de test logiciel permettant l'analyse d'une application via ses fonctionnalités, sans avoir connaissance de ses structures internes ou de son fonctionnement. -- **Composant** – Unité de code autonome avec ses interfaces de stockage et de réseau et qui communique avec d'autres composants. -- **Cross-Site Scripting (XSS)** – Vulnérabilité de sécurité typiquement présente dans les applications web et permettant l'injection de script dans le contenu côté client. -- **Module Cryptographique** – Matériel, logiciel et/ou micrologiciel qui implémente des algorithmes cryptographiques et/ou qui génère des clés de cryptographie. -- **CWE** – Liste communautaire des faiblesses en sécurité communes dans le logiciel. Sert à établir un langage commun, de barème aux outils de sécurité logiciels et en tant que référentiel aux efforts d'identification, de réduction et de prévention des faiblesses. -- **DAST** – Les technologies de test de sécurité des applications en mode dynamique sont conçues pour détecter les conditions indicatives d'une vulnérabilité de sécurité dans une application lors de son exécution. -- **Validation du Design** – Evaluation technique de la sécurité de l'architecture d'une application. -- **Validation Dynamique** – Utilisation d'outils automatisés qui utilisent les signatures des vulnérabilités pour identifier les problèmes pendant l'exécution d'une application. -- **Globally Unique Identifier (GUID)** – Numéro de référence unique utilisé en tant qu'identifiant en logiciel. -- **Hyper Text Transfer Protocol (HTTP)** – Prototole de niveau applicatif pour les systèmes d'information distribués, collaboratifs et hypermedia. Fondateur pour la communication de données sur le World Wide Web. -- **Clés Codées en Dur** – Clés de cryptographie stockées sur l'appareil même. -- **IPC** – Acronyme de Inter Process Communications. Sert aux processus à communiquer entre eux et avec le noyau pour coordonner leurs activités. -- **Validation des Entrées** – Canonicalisation et validation de données considérées comme non-fiables saisies par l'utilisateur. -- **Bytecode JAVA** – Le bytecode Java correspond au jeu d'instructions de la machine virtuelle Java (JVM). Chaque bytecode est composé d'un, ou parfois deux, octet(s) qui représente(nt) l'instruction (opcode), accompagné(s) de zéro octet ou plus pour le passage de paramètres. -- **Code Malicieux** – Code introduit dans une application pendant son développement à l'insu du responsable de l'application et qui a pour finalité de contourner la politique de sécurité visée. Différent des logiciels malveillants tels que les virus ou les vers! -- **Logiciel Malveillant (Malware)** – Code exécutable introduit dans une application au cours de son fonctionnement sans le consentement de l'utilisateur de l'application ou de son administrateur. -- **Open Web Application Security Project(OWASP)** – L'Open Web Application Security Project (OWASP) est une communauté mondiale indépendante et gratuite oeuvrant pour l'amélioration de la sécurité des applications logicielles. Notre mission est de rendre la sécurité applicative "visible" afin que les particuliers et les organisations puissent prendre les bonnes décisions en incluant les risques liés à la sécurité applicative . Voir : -- **PIE** – Position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. -- **Informations d'Identification Personnelles (PII)** – Informations pouvant, directement ou indirectement, mener à l'identification d'un individu ou permettre de contacter ou de localiser une personne dans un contexte donné. -- **PKI** – Une PKI est une infrastructure permettant de lier une clé publique à l'identité de l'entité la possédant. Le lien est établi grâce à un processus d'enregistrement et de délivrance de certificats par une autorité de certification (CA). -- **SDLC** – Software development lifecycle. -- **SAST** – Les technologies de test de sécurité des applications en mode statique (SAST) ont pour but d'analyser le code source d'une application, son bytecode ou son binaire afin de repérer les conditions indicatives de vulnérabilités de sécurité dans le code ou le design. Les solutions de SAST analysent les applications de l'intérieur et au repos. -- **Architecture de Sécurité** – Abstraction du design de l'application qui identifie et décrit où et comment les contrôles de sécurité sont mis en oeuvre et identifie et décrit l'emplacement et le niveau de sensibilité des données de l'utilisateur et de l'application. -- **Configuration de Sécurité** – Configuration de l'application lors de son exécution impactant directement la façon dont les contrôles de sécurité sont mis en oeuvre. -- **Contrôle de Sécurité** – Fonction ou composant exécutant une vérification liée à la sécurité (par exemple une validation des droits d'accès) ou ayant un impact sur la sécurité (par exemple génération d'un enregistrement dans un journal). -- **Injection SQL (SQLi)** – Technique d'injection de code utilisée dans l'attaque d'applications fortement consommatrices de données où des expressions SQL malicieuses sont insérées à des points d'entrée. -- **Authentification par SSO** – L'authentification unique (SSO) intervient lorsqu'un utilisateur s'authentifie sur un client donné et est ensuite authentifié automatiquement sur d'autres clients indépendemment de la plateforme, de la technologie ou du domaine utilisé par l'utilisateur. Par exemple, lorsque vous vous authentifiez sous Google, vous êtes automatiquement authentifiés par la suite sous les services YouTube, Docs et Gmail. -- **Modèle de Menaces** – Technique consistant dans le développement incrémental d'architectures de sécurité de plus en plus raffinées ayant pour but l'identification d'agents menaçants, de zones de sécurité, de contrôles de sécurité et des éléments importants concernant la technique et les affaires. -- **Transport Layer Security** – Protocoles de cryptographie pour les communications sécurisées à travers Internet. -- **Fragments URI/URL** – Un Uniform Resource Identifier (URI) est une chaîne de caractères utilisée pour l'identification d'un nom ou d'une ressource sur le web. Un Uniform Resource Locator (URL) est en général utilisé pour faire référence à une ressource. -- **Tests d'Acceptance Utilisateur (UAT)** – Correspond traditionnellement à un environnement de test ayant les mêmes comportements que l'environnement de production et où les tests logiciels sont réalisés avant le passage en production. -- **Validateur** – La personne ou l'équipe qui évalue une application par rapport aux exigences du MASVS de l'OWASP. -- **Liste Blanche** – Liste de données ou d'opérations permises, par exemple une liste de caractères acceptés lors de la validation des entrées. -- **Certificat X.509** – Un certificat X.509 est un certificat digital qui implémente le standard international largement utilisé concernant les infrastructures à clés publiques (PKI) X.509 dans le but de vérifier qu'une clé publique correspond bien à l'identité de l'utilisateur, de l'ordinateur ou du service indiqué sur le certificat. diff --git a/Document-fr/0x91-Appendix-B_References.md b/Document-fr/0x91-Appendix-B_References.md deleted file mode 100644 index b5bc55344..000000000 --- a/Document-fr/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Annexe B: Références - -Les projets de l'OWASP suivants sont susceptibles d'être utiles aux utilisateurs / ceux qui vont adopter ce standard : - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -De la même manière, les sites web suivants sont susceptibles d'être utiles aux utilisateurs / ceux qui vont adopter ce standard : - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-fr/CHANGELOG.md b/Document-fr/CHANGELOG.md deleted file mode 100644 index 08ad90491..000000000 --- a/Document-fr/CHANGELOG.md +++ /dev/null @@ -1,97 +0,0 @@ -# Changelog - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 Mars 2020 - Edition Internationale - -Les changements suivants ont été intégrés dans la version 1.2: - -- Traduction du MASVS en chinois simplifié disponible. -- Changement du titre en couverture du livre sur le MASVS. -- Suppression du Top 10 Mobile et de CWE du MSTG et fusion avec les références existantes dans le MASVS. - -## V1.2-RC - 5 Octobre 2019 - Pre-release - -Les changement suivants font partie de la livraison 1.2: - -- Mise à jour des traductions du MASVS dans les langues suivantes: chinoise (ZHTW), anglaise, allemande, française, russe, espagnole et japonaise. -- Promu au statut flagship. -- Exigence changée : MSTG-STORAGE-1 "doivent être utilisées". -- Les exigences MSTG-STORAGE-13, MSTG-STORAGE-14, MSTG-STORAGE-15 sont ajoutées avec un accent sur la protection des données. -- Exigence MSTG-AUTH-11 mise à jour pour garder les informations contextuelles. -- Exigence MSTG-CODE-4 mise à jour pour avoir une couverture plus large que le déboggage seulement. -- Exigence MSTG-PLATFORM-10 ajoutée pour offrir une protection plus large à l'utilisation des WebViews. -- Exigence MSTG-AUTH-12 ajoutée pour rappeler aux développeurs d'implémenter l'autorisation, surtout pour les applications multi-utilisateurs. -- Ajout de quelques éléments concernant l'utilisation du MASVS pour une évaluation de risque. -- Ajout de quelques éléments concernant la sécurisation du contenu payant. -- Exigence MSTG-ARCH-11 ajoutée pour inclure une politique de divulgation responsable pour les applications L2. -- Exigence MSTG-ARCH-12 ajoutée pour rappeler les exigences provenant des lois et réglementations à travers le monde. -- Création d'un style cohérent pour toutes les références. -- Exigence MSTG-PLATFORM-11 ajoutée pour contrer les menaces pouvant provenir des claviers tiers. -- Exigence MSTG-RESILIENCE-13 pour offrir un niveau de contrôle supplémentaire avec du chiffrement au niveau applicatif afin d'entraver l'écoute par un attaquant. - -## V1.1.4 - 4 Juillet 2019 - Summit edition - -- Corrections d'erreurs de markdown. -- Mise à jour des traductions française et espagnole. -- Ajout d'une traduction chinoise et japonaise du journal des modifications. -- Vérification automatisée de la syntaxe markdown et de l'accessibilité des URLs. -- Ajout de codes d'identification aux exigences, qui seront inclus dans la future version du MSTG afin de trouver plus facilement les recommandations et les cas de test. -- Réduction de la taille du référentiel et ajout de Generated au .gitignore. -- Ajout d'un code de conduite et de directives contributives. -- Ajout d'un modèle de PR. -- Mise à jour de la synchronisation avec le référentiel utilisé pour l'hébergement du site Web sur Gitbook. -- Mise à jour des scripts pour générer les fichiers XML / JSON / CSV pour toutes les traductions. -- Traduit de l'avant-propos en chinois (ZHTW). - -## V1.1.3 - Janvier 2019 - Quelques Améliorations - -Les changements suivants font partie de la livraison 1.1.3 : - -- Corrections d'erreurs de traduction de l'exigence 7.1 dans la version espagnole -- Nouvelle présentation des traducteurs dans les Remerciements -- Petites corrections pour la version japonaise. - -## V1.1.2 - Janvier 2019 - Parrainage et internationalisation - -Les changements suivants font partie de la livraison 1.1.2 : - -- Ajout d'une note de remerciement pour les acheteurs de l'e-book. -- Ajout d'un lien d'authentification manquant & mise à jour d'un lien d'authentification obsolète dans la V4. -- Correction d'une inversion de 4.7 et de 4.8 en anglais. -- Premières livraisons internationales! - - Corrections dans la traduction en espagnol. La traduction est dorénavant en phase avec la version anglaise (1.1.2). - - Corrections dans la traduction en russe. La traduction est dorénavant en phase avec la version anglaise (1.1.2). - - Ajout des premières livraisons en chinois (ZHTW), français, allemand et japonais! -- Simplification du document afin de faciliter la traduction. -- Ajout d'instructions pour les livraisons automatisées. - -## V1.1.0 - 14 Juillet 2018 - -Les changements suivants font partie de la livraison 1.1 : - -- L'exigence 2.6 "Le presse-papier est désactivé sur les champs de texte qui peuvent contenir des données sensibles." a été enlevée. -- L'exigence 2.2 "Aucune donnée sensible ne devrait être stockée hors du container de l'application ou des services de stockage de références fournis par le système." a été ajouté. -- L'exigence 2.1 a été reformulée vers "Les services de stockage de références fournis par le système sont utilisés de façon appropriée pour le stockage de données sensibles telles que les PII, les références des utilisateurs ou les clés de cryptographie.". - -## V1.0 - 12 Janvier 2018 - -Les changements suivants font partie de la livraison 1.0 : - -- Suppression de 8.9 en raison d'une redondance avec 8.12 -- Reformulation de 4.6 pour la rendre plus générique -- Quelques améliorations (typos, etc.) diff --git a/Document-fr/GLOSSARY.md b/Document-fr/GLOSSARY.md deleted file mode 100644 index c06917cfa..000000000 --- a/Document-fr/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Annexe A: Glossaire - -## Distribution Aléatoire de l'Espace D'adressage (ASLR) - -Une technique rendant plus difficiles l'exploitation de défauts permettant la corruption de la mémoire. - -## Sécurité Applicative - -La sécurité de niveau applicatif se focalise sur l'analyse des composants qui constituent la couche applicative du modèle OSI (the Open Systems Interconnection Reference Model), plutôt que de se focaliser par exemple sur le système d'exploitation sous-jacent ou sur les réseaux connectés. - -## Validation de la Sécurité Applicative - -Evaluation technique d'une application par rapport au MASVS de l'OWASP. - -## Rapport de Validation de Sécurité Applicative - -Rapport qui documente les résultats dans leur ensemble ainsi que l'analyse sous-jacente réalisée par le validateur de l'application considérée. - -## Authentification - -Vérification de l'identité clamée par l'utilisateur de l'application. - -## Validation Automatique - -Utilisation d'outils automatisés (outils d'analyse dynamique ou outils d'analyse statique, ou les deux) qui utilisent les signatures des vulnérabilités pour identifier les problèmes. - -## Test en Boîte Noire - -Méthode de test logiciel permettant l'analyse d'une application via ses fonctionnalités, sans avoir connaissance de ses structures internes ou de son fonctionnement. - -## Composant - -Unité de code autonome avec ses interfaces de stockage et de réseau et qui communique avec d'autres composants. - -## Cross-Site Scripting (XSS) - -Vulnérabilité de sécurité typiquement présente dans les applications web et permettant l'injection de script dans le contenu côté client. - -## Module Cryptographique - -Matériel, logiciel et/ou micrologiciel qui implémente des algorithmes cryptographiques et/ou qui génère des clés de cryptographie. - -## CWE - -Liste communautaire des faiblesses en sécurité communes dans le logiciel. Sert à établir un langage commun, de barème aux outils de sécurité logiciels et en tant que référentiel aux efforts d'identification, de réduction et de prévention des faiblesses. - -## DAST - -Les technologies de test de sécurité des applications en mode dynamique sont conçues pour détecter les conditions indicatives d'une vulnérabilité de sécurité dans une application lors de son exécution. - -## Validation du Design - -Evaluation technique de la sécurité de l'architecture d'une application. - -## Validation Dynamique - -Utilisation d'outils automatisés qui utilisent les signatures des vulnérabilités pour identifier les problèmes pendant l'exécution d'une application. - -## Globally Unique Identifier (GUID) - -Numéro de référence unique utilisé en tant qu'identifiant en logiciel. - -## Hyper Text Transfer Protocol (HTTP) - -Prototole de niveau applicatif pour les systèmes d'information distribués, collaboratifs et hypermedia. Fondateur pour la communication de données sur le World Wide Web. - -## Clés Codées en Dur - -Clés de cryptographie stockées sur l'appareil même. - -## IPC - -Acronyme de Inter Process Communications. Sert aux processus à communiquer entre eux et avec le noyau pour coordonner leurs activités. - -## Validation des Entrées - -Canonicalisation et validation de données considérées comme non-fiables saisies par l'utilisateur. - -## Bytecode JAVA - -Le bytecode Java correspond au jeu d'instructions de la machine virtuelle Java (JVM). Chaque bytecode est composé d'un, ou parfois deux, octet(s) qui représente(nt) l'instruction (opcode), accompagné(s) de zéro octet ou plus pour le passage de paramètres. - -## Code Malicieux - -Code introduit dans une application pendant son développement à l'insu du responsable de l'application et qui a pour finalité de contourner la politique de sécurité visée. Différent des logiciels malveillants tels que les virus ou les vers! - -## Logiciel Malveillant (Malware) - -Code exécutable introduit dans une application au cours de son fonctionnement sans le consentement de l'utilisateur de l'application ou de son administrateur. - -## Open Web Application Security Project(OWASP) - -L'Open Web Application Security Project (OWASP) est une communauté mondiale indépendante et gratuite oeuvrant pour l'amélioration de la sécurité des applications logicielles. Notre mission est de rendre la sécurité applicative "visible" afin que les particuliers et les organisations puissent prendre les bonnes décisions en incluant les risques liés à la sécurité applicative . Voir : - -## PIE - -Position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. - -## Informations d'Identification Personnelles (PII) - -Informations pouvant, directement ou indirectement, mener à l'identification d'un individu ou permettre de contacter ou de localiser une personne dans un contexte donné. - -## PKI - -Une PKI est une infrastructure permettant de lier une clé publique à l'identité de l'entité la possédant. Le lien est établi grâce à un processus d'enregistrement et de délivrance de certificats par une autorité de certification (CA). - -## SDLC - -Software development lifecycle. - -## SAST - -Les technologies de test de sécurité des applications en mode statique (SAST) ont pour but d'analyser le code source d'une application, son bytecode ou son binaire afin de repérer les conditions indicatives de vulnérabilités de sécurité dans le code ou le design. Les solutions de SAST analysent les applications de l'intérieur et au repos. - -## Architecture de Sécurité - -Abstraction du design de l'application qui identifie et décrit où et comment les contrôles de sécurité sont mis en oeuvre et identifie et décrit l'emplacement et le niveau de sensibilité des données de l'utilisateur et de l'application. - -## Configuration de Sécurité - -Configuration de l'application lors de son exécution impactant directement la façon dont les contrôles de sécurité sont mis en oeuvre. - -## Contrôle de Sécurité - -Fonction ou composant exécutant une vérification liée à la sécurité (par exemple une validation des droits d'accès) ou ayant un impact sur la sécurité (par exemple génération d'un enregistrement dans un journal). - -## Injection SQL (SQLi) - -Technique d'injection de code utilisée dans l'attaque d'applications fortement consommatrices de données où des expressions SQL malicieuses sont insérées à des points d'entrée. - -## Authentification par SSO - -L'authentification unique (SSO) intervient lorsqu'un utilisateur s'authentifie sur un client donné et est ensuite authentifié automatiquement sur d'autres clients indépendemment de la plateforme, de la technologie ou du domaine utilisé par l'utilisateur. Par exemple, lorsque vous vous authentifiez sous Google, vous êtes automatiquement authentifiés par la suite sous les services YouTube, Docs et Gmail. - -## Modèle de Menaces - -Technique consistant dans le développement incrémental d'architectures de sécurité de plus en plus raffinées ayant pour but l'identification d'agents menaçants, de zones de sécurité, de contrôles de sécurité et des éléments importants concernant la technique et les affaires. - -## Transport Layer Security - -Protocoles de cryptographie pour les communications sécurisées à travers Internet. - -## Fragments URI/URL - -Un Uniform Resource Identifier (URI) est une chaîne de caractères utilisée pour l'identification d'un nom ou d'une ressource sur le web. Un Uniform Resource Locator (URL) est en général utilisé pour faire référence à une ressource. - -## Tests d'Acceptance Utilisateur (UAT) - -Correspond traditionnellement à un environnement de test ayant les mêmes comportements que l'environnement de production et où les tests logiciels sont réalisés avant le passage en production. - -## Validateur - -La personne ou l'équipe qui évalue une application par rapport aux exigences du MASVS de l'OWASP. - -## Liste Blanche - -Liste de données ou d'opérations permises, par exemple une liste de caractères acceptés lors de la validation des entrées. - -## Certificat X.509 - -Un certificat X.509 est un certificat digital qui implémente le standard international largement utilisé concernant les infrastructures à clés publiques (PKI) X.509 dans le but de vérifier qu'une clé publique correspond bien à l'identité de l'utilisateur, de l'ordinateur ou du service indiqué sur le certificat. diff --git a/Document-fr/SUMMARY.md b/Document-fr/SUMMARY.md deleted file mode 100644 index a34f083a1..000000000 --- a/Document-fr/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Résumé - -- [Avant-Propos](0x01-Foreword.md) -- [Changelog](CHANGELOG.md) -- [Frontispice](0x02-Frontispiece.md) -- [Utiliser le MASVS](0x03-Using_the_MASVS.md) -- [Evaluation et Certification](0x04-Assessment_and_Certification.md) - -## Exigences Concernant Securite - -- [V1: Exigences Concernant l'Architecture, le Design et le Modèle de Menaces](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Exigences Concernant le Stockage des Données et le Respect de la Vie Privée](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Exigences Concernant la Cryptographie](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Exigences Concernant l'Authentification et la Gestion des Sessions](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Exigences Concernant la Communication Réseau](0x10-V5-Network_communication_requirements.md) -- [V6: Exigences Concernant les Interactions avec la Plateforme](0x11-V6-Interaction_with_the_environment.md) -- [V7: Exigences Concernant la Qualité du Code et les Paramètres de Génération](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Exigences Concernant la Résilience](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Annexes - -- [Annexe A - Glossaire](GLOSSARY.md) -- [Annexe B - Références](0x91-Appendix-B_References.md) diff --git a/Document-fr/book.json b/Document-fr/book.json deleted file mode 100644 index f29418dff..000000000 --- a/Document-fr/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "fr" -} diff --git a/Document-fr/images/CC-license.png b/Document-fr/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-fr/images/CC-license.png and /dev/null differ diff --git a/Document-fr/images/MASVS-levels.png b/Document-fr/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-fr/images/MASVS-levels.png and /dev/null differ diff --git a/Document-fr/images/OWASP_logo.png b/Document-fr/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-fr/images/OWASP_logo.png and /dev/null differ diff --git a/Document-fr/images/license.png b/Document-fr/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-fr/images/license.png and /dev/null differ diff --git a/Document-fr/images/masvs-cover-1.1.xcf b/Document-fr/images/masvs-cover-1.1.xcf deleted file mode 100644 index 7e4ddd1e0..000000000 Binary files a/Document-fr/images/masvs-cover-1.1.xcf and /dev/null differ diff --git a/Document-fr/images/masvs-levels-new.jpg b/Document-fr/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-fr/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-fr/images/masvs-levels-new_fr.jpg b/Document-fr/images/masvs-levels-new_fr.jpg deleted file mode 100644 index 199055ab2..000000000 Binary files a/Document-fr/images/masvs-levels-new_fr.jpg and /dev/null differ diff --git a/Document-fr/images/masvs-mini-cover.jpg b/Document-fr/images/masvs-mini-cover.jpg deleted file mode 100644 index bae43fdf8..000000000 Binary files a/Document-fr/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-fr/images/masvs-mini-cover.png b/Document-fr/images/masvs-mini-cover.png deleted file mode 100644 index 15d07d0c2..000000000 Binary files a/Document-fr/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-fr/metadata.md b/Document-fr/metadata.md deleted file mode 100644 index 3da35dcc7..000000000 --- a/Document-fr/metadata.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -# This overide the main Document/metadata.md file -lang: 'fr' -languagetext: '(French Translation)' - -# toc-title is translated when `lang` is correctly defined -#toc-title: 'Sommaire' - ---- diff --git a/Document-gr/0x01-Foreword.md b/Document-gr/0x01-Foreword.md deleted file mode 100644 index d76c311fb..000000000 --- a/Document-gr/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Πρόλογος - -Οι τεχνολογικές επαναστάσεις μπορούν να συμβούν γρήγορα. Λιγότερο από μια δεκαετία πριν, τα smartphones ήταν αδέξιες συσκευές με μικρά πληκτρολόγια - ακριβά παιχνίδια για γκατζετάκιδες εργαζόμενους σε επιχειρήσεις. Σήμερα, τα smartphones είναι ένα ουσιαστικό μέρος της ζωής μας. Εξαρτόμαστε από αυτό για πληροφόρηση, πλοήγηση και επικοινωνία, και είναι παντού στην εργασία καθώς και στη προσωπική μας ζωή. - -Κάθε νέα τεχνολογία εισάγει νέους κινδύνους για την ασφάλεια και η παρακολούθηση αυτών των αλλαγών είναι μία από τις κυριότερες προκλήσεις που αντιμετωπίζει ο κλάδος της Ασφάλειας. Η αμυντική πλευρά είναι πάντα λίγα βήματα πίσω. Για παράδειγμα, το αυτόματο αντανακλαστικό για πολλούς ήταν να εφαρμόσουν παλιούς τρόπους σχετικά με το πως χειρίζεσαι τα πράγματα: τα smartphone είναι σαν μικρούς υπολογιστές και οι mobile εφαρμογές είναι ακριβώς όπως το κλασικό λογισμικό, οπότε είναι σίγουρα οι απαιτήσεις ασφαλείας παρόμοιες; Όμως δεν λειτουργεί έτσι. Τα λειτουργικά συστήματα για smartphone διαφέρουν από τα λειτουργικά συστήματα για κλασικούς υπολογιστές και οι mobile εφαρμογές διαφέρουν από τις web εφαρμογές. Για παράδειγμα, η κλασική μέθοδος σάρωσης-ανίχνευσης ιών που βασίζεται σε υπογραφές δεν έχει νόημα σε σύγχρονα περιβάλλοντα λειτουργικού συστήματος για κινητά: Όχι μόνο δεν είναι συμβατή με το μοντέλο διανομής εφαρμογών για κινητά, αλλά είναι επίσης τεχνικά αδύνατη λόγω περιορισμών στο sandboxing. Επίσης, ορισμένες κατηγορίες ευπαθειών, όπως buffer overflows και XSS, είναι λιγότερο σχετικές στο πλαίσιο των συνηθισμένων mobile εφαρμογών σε σύγκριση για παράδειγμα, με τις desktop και web εφαρμογές (ισχύουν εξαιρέσεις). - -Με την πάροδο του χρόνου, ο κλάδος μας έχει καταλάβει καλύτερα το τοπίο απειλών για κινητά. Όπως αποδεικνύεται, η ασφάλεια των κινητών έχει να κάνει με την προστασία δεδομένων: Οι εφαρμογές αποθηκεύουν τις προσωπικές μας πληροφορίες, φωτογραφίες, ηχογραφήσεις, σημειώσεις, δεδομένα λογαριασμών, επιχειρησιακές πληροφορίες, τοποθεσία και πολλά άλλα. Λειτουργούν ως clients που μας συνδέουν με υπηρεσίες που χρησιμοποιούμε σε καθημερινή βάση και ως κόμβοι επικοινωνίας που επεξεργάζονται κάθε μήνυμα που ανταλλάσσουμε με άλλους. Υποκλέψτε το smartphone ενός ατόμου, και θα έχετε αφιλτράριστη πρόσβαση στη ζωή αυτού του ατόμου. Αν σκεφτούμε ότι οι κινητές συσκευές χάνονται ή κλέβονται πιο εύκολα και ότι το κακόβουλο λογισμικό για κινητά αυξάνεται, η ανάγκη για προστασία δεδομένων γίνεται ακόμη πιο εμφανής. - -Ένα πρότυπο ασφαλείας για mobile εφαρμογές πρέπει επομένως να επικεντρώνεται στον τρόπο με τον οποίο οι εφαρμογές αυτές χειρίζονται, αποθηκεύουν και προστατεύουν ευαίσθητες πληροφορίες. Παρόλο που τα σύγχρονα λειτουργικά συστήματα για κινητά όπως το iOS και το Android προσφέρουν καλά APIs για ασφαλή αποθήκευση και επικοινωνία δεδομένων, αυτά πρέπει να εφαρμοστούν και να χρησιμοποιηθούν σωστά για να είναι αποτελεσματικά. Η αποθήκευση δεδομένων, η επικοινωνία μεταξύ εφαρμογών, η σωστή χρήση κρυπτογραφικών APIs και η ασφαλής επικοινωνία δικτύου είναι μόνο μερικές από τις πτυχές που απαιτούν προσεκτική εξέταση. - -Ένα σημαντικό ερώτημα που χρειάζεται συναίνεση του κλάδου είναι πόσο μακριά πρέπει να φτάσει κάποιος για την προστασία της εμπιστευτικότητας και της ακεραιότητας των δεδομένων. Για παράδειγμα, οι περισσότεροι από εμάς θα συμφωνούσαν ότι μια εφαρμογή για κινητά θα πρέπει να επαληθεύει το πιστοποιητικό του server σε μια επικοινωνία TLS. Τι γίνεται όμως με το pinning του πιστοποιητικού SSL; Αν δεν το κάνετε αυτό οδηγεί σε ευπάθεια; Θα πρέπει αυτό να είναι απαίτηση εάν μια εφαρμογή χειρίζεται ευαίσθητα δεδομένα ή είναι ίσως ακόμη και αντιπαραγωγικό; Χρειάζεται να κρυπτογραφήσουμε δεδομένα που είναι αποθηκευμένα σε βάσεις δεδομένων SQLite, παρόλο που το λειτουργικό σύστημα περικλείει την εφαρμογή; Αυτό που είναι κατάλληλο για μια εφαρμογή μπορεί να είναι μη ρεαλιστικό για μια άλλη. Το MASVS είναι μια προσπάθεια τυποποίησης αυτών των απαιτήσεων χρησιμοποιώντας επίπεδα επαλήθευσης που ταιριάζουν σε διαφορετικά σενάρια απειλών. - -Επιπλέον, η εμφάνιση κακόβουλου λογισμικού σε επίπεδο root, και εργαλείων απομακρυσμένης διαχείρισης έχει δημιουργήσει επίγνωση του γεγονότος ότι τα ίδια τα λειτουργικά συστήματα κινητών έχουν εκμεταλλεύσιμα ελαττώματα, επομένως οι στρατηγικές χρήσης container χρησιμοποιούνται ολοένα και περισσότερο για την παροχή πρόσθετης προστασίας σε ευαίσθητα δεδομένα και την αποτροπή παραβίασης από την πλευρά του client. Εδώ είναι που τα πράγματα περιπλέκονται. Υπάρχουν δυνατότητες ασφαλείας που υποστηρίζονται από υλικό και λύσεις container σε επίπεδο λειτουργικού συστήματος, όπως το Android for Work και το Samsung Knox, αλλά δεν είναι σταθερά διαθέσιμες σε διαφορετικές συσκευές. Ως ενίσχυση, είναι δυνατή η εφαρμογή μέτρων προστασίας που βασίζονται σε λογισμικό - αλλά δυστυχώς, δεν υπάρχουν πρότυπα ή διαδικασίες test για την επαλήθευση αυτού του είδους προστασίας. - -Ως αποτέλεσμα, αναφορές από τεστ ασφαλείας mobile εφαρμογών είναι παντού: Για παράδειγμα, ορισμένοι αναφέρουν την έλλειψη obfuscation ή εντοπισμού root σε μια εφαρμογή Android ως "ελάττωμα ασφαλείας". Από την άλλη πλευρά, μέτρα όπως η κρυπτογράφηση τιμών, ο εντοπισμός του debugger, ή το control flow obfuscation δεν θεωρούνται υποχρεωτικά. Ωστόσο, αυτός ο δυαδικός τρόπος εξέτασης των πραγμάτων δεν βγάζει νόημα, επειδή η ανθεκτικότητα δεν είναι μια δυαδική πρόταση: Εξαρτάται από τις συγκεκριμένες απειλές από την πλευρά του client από τις οποίες στοχεύει κανείς να αμυνθεί. Οι προστασίες λογισμικού δεν είναι άχρηστες, αλλά μπορούν τελικά να παρακαμφθούν, επομένως δεν πρέπει ποτέ να χρησιμοποιούνται ως αντικατάσταση των μηχανισμών ασφαλείας. - -Ο γενικός στόχος του MASVS είναι να προσφέρει μια βάση για την ασφάλεια mobile εφαρμογών (MASVS-L1), επιτρέποντας επίσης τη συμπερίληψη μέτρων άμυνας σε βάθος (MASVS-L2) και προστασίας έναντι απειλών από την πλευρά του client (MASVS-R). Το MASVS προορίζεται να επιτύχει τα ακόλουθα: - -- Παροχή απαιτήσεων (requirements) για Software Architects και προγραμματιστές που επιδιώκουν να αναπτύξουν ασφαλείς mobile εφαρμογές. -- Η συνεισφορά ενός προτύπου που να μπορεί να τεσταριστεί στα πλαίσια μια αξιολόγησης ασφάλειας mobile εφαρμογής. -- Αποσαφήνιση του ρόλου των μηχανισμών προστασίας λογισμικού στην ασφάλεια κινητών και παροχή απαιτήσεων για την επαλήθευση της αποτελεσματικότητάς τους. -- Παροχή συγκεκριμένων συστάσεων σχετικά με το επίπεδο ασφάλειας που συνιστάται για διαφορετικές περιπτώσεις χρήσης. - -Γνωρίζουμε ότι είναι αδύνατο να επιτευχθεί 100% συναίνεση του κλάδου. Ωστόσο, ελπίζουμε ότι το MASVS είναι χρήσιμο για την παροχή καθοδήγησης σε όλες τις φάσεις ανάπτυξης και δοκιμής mobile εφαρμογών. Ως πρότυπο ανοιχτού κώδικα, το MASVS θα εξελίσσεται με την πάροδο του χρόνου και καλωσορίζουμε κάθε συνεισφορά και πρόταση. - -Από τον Bernhard Mueller diff --git a/Document-gr/0x02-Frontispiece.md b/Document-gr/0x02-Frontispiece.md deleted file mode 100644 index dd81b64de..000000000 --- a/Document-gr/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Σχετικά με το Πρότυπο - -![OWASP Logo](images/OWASP_logo.png) - -Καλώς ήρθατε στο Μοbile Application Security Verification Standard (MASVS). Το MASVS είναι μια προσπάθεια της κοινότητας για τη δημιουργία ενός πλαισίου απαιτήσεων ασφαλείας που απαιτούνται για το σχεδιασμό, την ανάπτυξη και τη δοκιμή ασφαλών mobile εφαρμογών σε iOS και Android. - -Το MASVS είναι το επιστέγασμα της προσπάθειας της κοινότητας και του feedback από το κλάδο. Αναμένουμε ότι αυτό το πρότυπο θα εξελιχθεί με την πάροδο του χρόνου και καλωσορίζουμε τα σχόλια από την κοινότητα. - -Ο καλύτερος τρόπος για να έρθετε σε επαφή μαζί μας είναι μέσω του καναλιού OWASP Mobile Project Slack: . - -Λογαριασμοί μπορούν να δημιουργηθούν σε παρακάτω URL: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Πνευματικά Δικαιώματα και Άδεια Χρήσης - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Η προσπάθεια αυτή υπόκειται στην ακόλουθη άδεια [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). Για οποιαδήποτε επαναχρησιμοποίηση ή διανομή, πρέπει να καταστήσετε σαφή στους άλλους τους όρους/άδειας χρήσης αυτού του έργου. - - - -## Ευχαριστίες - -| Επικεφαλής Έργου | Επικεφαλής Συγγραφέας | Συντελεστές και Κριτές -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Γλώσσα | Μεταφραστές & Κριτές | -| --------------- | ------------------------------------------------------------ | -| Brazilian Portuguese | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Chinese (Traditonal) | Peter Chi, 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) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Kunwar Atul Singh, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 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, Milad Khoshdel | -| Portuguese | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Russian | Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Review), Oprya Egor (Review), Tereshin Dmitry (Review) | -| Spanish | Martin Marsicano, Carlos Holguera | -| Turkish | Anıl Baş, Haktan Emik | -| Greek | Panagiotis Yialouris | - -Αυτό το έγγραφο ξεκίνησε σαν ένα fork του OWASP Application Security Verification Standard γραμμένο από το Jim Manico. - -### Δωρεές - -Ενώ τόσο το MASVS όσο και το MSTG δημιουργούνται και διατηρούνται από την κοινότητα σε εθελοντική βάση, μερικές φορές απαιτείται λίγη εξωτερική βοήθεια. Ως εκ τούτου, ευχαριστούμε τους δωρητές μας που παρείχαν τα κεφάλαια για να μπορέσουμε να προσλάβουμε τεχνικούς συντάκτες. Να σημειωθεί ότι η δωρεά τους δεν επηρεάζει με κανέναν τρόπο το περιεχόμενο του MASVS ή του MSTG. Τα πακέτα από δωρεές περιγράφονται στο [OWASP Project Wiki](https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide#tab=Sponsorship_Packages "OWASP Mobile Security Testing Guide Donation Packages"). - - - -Θα θέλαμε να ευχαριστήσουμε όσου αγόρασαν το βιβλίο από το [Leanpub](https://leanpub.com/mobile-security-testing-guide) και μας στήριξαν με αυτό το τρόπο. diff --git a/Document-gr/0x03-Using_the_MASVS.md b/Document-gr/0x03-Using_the_MASVS.md deleted file mode 100644 index 766e48bb8..000000000 --- a/Document-gr/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,82 +0,0 @@ -# Το Mobile Application Security Verification Standard - -Το MASVS μπορεί να χρησιμοποιηθεί για να δημιουργήσει ένα επίπεδο εμπιστοσύνης στην ασφάλεια των mobile εφαρμογών. Οι απαιτήσεις αναπτύχθηκαν έχοντας κατά νου τους ακόλουθους στόχους: - -- Χρήση ως metric - Για την παροχή ενός προτύπου ασφαλείας με το οποίο οι υπάρχουσες mobile εφαρμογές μπορούν να συγκριθούν από προγραμματιστές και κατόχους εφαρμογών. -- Χρήση ως καθοδήγηση - Για παροχή καθοδήγησης σε όλες τις φάσεις ανάπτυξης και δοκιμής εφαρμογών για κινητά. -- Χρήση κατά την προμήθεια - Παροχή βασικής γραμμής για επαλήθευση ασφάλειας mobile εφαρμογών. - -## Μοντέλο Ασφάλειας Mobile Εφαρμογών - -Το MASVS ορίζει δύο επίπεδα επαλήθευσης ασφαλείας (MASVS-L1 και MASVS-L2), καθώς και ένα σύνολο απαιτήσεων ανθεκτικότητας απέναντι σε reverse engineering (MASVS-R). Το MASVS-L1 περιέχει γενικές απαιτήσεις ασφαλείας που συνιστώνται για όλες τις mobile εφαρμογές, ενώ το MASVS-L2 θα πρέπει να εφαρμόζεται σε εφαρμογές που χειρίζονται εξαιρετικά ευαίσθητα δεδομένα. Το MASVS-R καλύπτει πρόσθετους προστατευτικούς ελέγχους που μπορούν να εφαρμοστούν εάν η αποτροπή απειλών από την πλευρά του client αποτελεί στόχο κατα το Design. - -Η εκπλήρωση των απαιτήσεων στο MASVS-L1 οδηγεί σε μια ασφαλή εφαρμογή που ακολουθεί τις βέλτιστες πρακτικές ασφαλείας και δεν αντιμετωπίζει πρόβλημα από κοινά τρωτά σημεία. Το MASVS-L2 προσθέτει πρόσθετους ελέγχους με βάθος άμυνας, όπως το SSL pinning, με αποτέλεσμα μια εφαρμογή που είναι ανθεκτική σε πιο εξελιγμένες επιθέσεις - με την προϋπόθεση ότι οι μηχανισμοί ασφαλείας του λειτουργικού συστήματος του κινητού είναι άθικτοι και ο τελικός χρήστης δεν θεωρείται κακόβουλος. Η εκπλήρωση όλων ή υποσυνόλων των απαιτήσεων προστασίας λογισμικού στο MASVS-R συμβάλλει στην παρεμπόδιση συγκεκριμένων απειλών από την πλευρά του client όπου ο τελικός χρήστης είναι κακόβουλος ή/και το λειτουργικό σύστημα του κινητού είναι σε κίνδυνο. - -**I: Αν και συνιστούμε την υλοποίηση των μηχανισμών του MASVS-L1 σε κάθε εφαρμογή, η υλοποίηση ενός μηχανισμού ή όχι θα πρέπει τελικά να είναι μια απόφαση βασισμένη στον ρίσκο, η οποία κοινοποιείται στους business owners και λαμβάνεται αντίστοιχα.** - -**II: Να σημειωθεί ότι οι μηχανισμοί ελέγχου προστασίας λογισμικού που αναφέρονται στο MASVS-R και περιγράφονται στο OWASP Mobile Security Testing Guide μπορούν τελικά να παρακαμφθούν και δεν πρέπει ποτέ να χρησιμοποιηθούν ως αντικατάσταση των μηχανισμών ελέγχου ασφαλείας. Αντίθετα, προορίζονται να προσθέσουν έξτρα μηχανισμούς προστασίας βασισμένους σε απειλές, σε εφαρμογές που πληρούν επίσης τις απαιτήσεις MASVS στο MASVS-L1 ή στο MASVS-L2.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### Δομή Εγγράφου - -Το πρώτο μέρος του MASVS περιέχει μια περιγραφή του μοντέλου ασφαλείας και των διαθέσιμων επιπέδων επαλήθευσης, ακολουθούμενα από συστάσεις σχετικά με τον τρόπο χρήσης του προτύπου στην πράξη. Οι λεπτομερείς απαιτήσεις ασφαλείας, μαζί με μια αντιστοίχιση στα επίπεδα επαλήθευσης, παρατίθενται στο δεύτερο μέρος. Οι απαιτήσεις έχουν ομαδοποιηθεί σε οκτώ κατηγορίες (V1 έως V8) με βάση τον τεχνικό στόχο / πεδίο εφαρμογής. Η ακόλουθη ονοματολογία χρησιμοποιείται σε όλο το MASVS και το MSTG: - -- *Κατηγορία Απαίτησης:* MASVS-Vx, e.g. MASVS-V2: Αποθήκευση Δεδομένων and Ιδιωτικότητα -- *Απαίτηση:* MASVS-Vx.y, e.g. MASVS-V2.2: "Στα αρχεία καταγραφής (logs) της εφαρμογής, δεν καταγράφονται ευαίσθητα δεδομένα." - -### Επίπεδα Επαλήθευσης σε Λεπτομέρεια - -#### MASVS-L1: Τυπική Ασφάλεια - -Μια mobile εφαρμογή που επιτυγχάνει το MASVS-L1 συμμορφώνεται με τις βέλτιστες πρακτικές ασφάλειας mobile εφαρμογών. Πληροί βασικές απαιτήσεις όσον αφορά την ποιότητα του κώδικα, το χειρισμό ευαίσθητων δεδομένων και την αλληλεπίδραση με το περιβάλλον κινητής τηλεφωνίας. Πρέπει να υπάρχει μια διαδικασία δοκιμής για την επαλήθευση των ελέγχων ασφαλείας. Αυτό το επίπεδο είναι κατάλληλο για όλες τις εφαρμογές για κινητές συσκευές. - -#### MASVS-L2: Άμυνα σε Βάθος - -Το MASVS-L2 εισάγει προηγμένους ελέγχους ασφαλείας που υπερβαίνουν τις τυπικές απαιτήσεις. Για να εκπληρωθεί το MASVS-L2, πρέπει να υπάρχει ένα μοντέλο απειλής (threat model) και η ασφάλεια πρέπει να αποτελεί αναπόσπαστο μέρος της αρχιτεκτονικής και του σχεδιασμού της εφαρμογής. Με βάση το μοντέλο απειλής, τα σωστά στοιχεία ελέγχου MASVS-L2 θα έπρεπε να έχουν επιλεγεί και υλοποιηθεί με επιτυχία. Αυτό το επίπεδο είναι κατάλληλο για εφαρμογές που χειρίζονται εξαιρετικά ευαίσθητα δεδομένα, όπως εφαρμογές mobile banking. - -#### MASVS-R: Ανθεκτικότητα απέναντι σε Reverse Engineering και Παραποίηση (Tampering) - -Η εφαρμογή διαθέτει ασφάλεια αιχμής και είναι επίσης ανθεκτική σε συγκεκριμένες, σαφώς καθορισμένες επιθέσεις από την πλευρά του client, όπως παραποίηση, τροποποίηση ή reverse engineering για την εξαγωγή ευαίσθητου κώδικα ή δεδομένων. Μια τέτοια εφαρμογή είτε αξιοποιεί hardware χαρακτηριστικά ασφαλείας, είτε επαρκώς ισχυρές και επαληθεύσιμες τεχνικές προστασίας λογισμικού. Το MASVS-R εφαρμόζεται σε εφαρμογές που χειρίζονται εξαιρετικά ευαίσθητα δεδομένα και μπορεί να χρησιμεύσει ως μέσο προστασίας της πνευματικής ιδιοκτησίας ή προστασίας από παραβιάσεις. - -### Προτεινόμενη Χρήση - -Οι εφαρμογές μπορούν να επαληθευτούν έναντι του MASVS L1 ή L2 με βάση την προηγούμενη αξιολόγηση κινδύνου και το συνολικό επίπεδο ασφάλειας που απαιτείται. Το L1 ισχύει για όλες τις mobile εφαρμογές, ενώ το L2 συνιστάται γενικά για εφαρμογές που χειρίζονται πιο ευαίσθητα δεδομένα ή/και λειτουργίες. Το MASVS-R (ή μέρη του) μπορεί να εφαρμοστεί για την επαλήθευση της ανθεκτικότητας έναντι συγκεκριμένων απειλών, όπως το repackaging ή η εξαγωγή ευαίσθητων δεδομένων, *επιπλέον* της κατάλληλης επαλήθευση ασφαλείας. - -Συνοπτικά, είναι διαθέσιμοι οι ακόλουθοι τύποι επαλήθευσης: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Οι διαφορετικοί συνδυασμοί αντικατοπτρίζουν διαφορετικούς βαθμούς ασφάλειας και ανθεκτικότητας. Ο στόχος είναι να επιτραπεί η ευελιξία: Για παράδειγμα, ένα παιχνίδι για κινητά μπορεί να μην δικαιολογεί την προσθήκη στοιχείων ελέγχου ασφαλείας MASVS-L2, όπως ο έλεγχος ταυτότητας 2 παραγόντων (2-FA) για λόγους χρηστικότητας, αλλά έχει έντονη επιχειρησιακή ανάγκη για πρόληψη παραποιήσης. - -#### Ποιο τύπο επαλήθευσης να επιλέξω - -Η εφαρμογή των απαιτήσεων του MASVS L2 αυξάνει την ασφάλεια, ενώ ταυτόχρονα αυξάνει το κόστος ανάπτυξης και δυνητικά επιδεινώνει την εμπειρία του τελικού χρήστη (σύνηθες trade-off). Γενικά, το L2 θα πρέπει να χρησιμοποιείται για εφαρμογές όποτε έχει νόημα από την άποψη του κινδύνου έναντι του κόστους (δηλαδή, όταν η πιθανή απώλεια που προκαλείται από παραβίαση εμπιστευτικότητας ή ακεραιότητας είναι υψηλότερη από το κόστος που προκύπτει από τους πρόσθετους μηχανισμούς ασφαλείας). Η αποτίμηση κινδύνου (risk assessment) θα πρέπει να είναι το πρώτο βήμα πριν από την εφαρμογή του MASVS. - -##### Παραδείγματα - -###### MASVS-L1 - -- Όλες οι εφαρμογές για κινητά. Το MASVS-L1 παραθέτει τις βέλτιστες πρακτικές ασφαλείας που μπορούν να ακολουθηθούν με εύλογο αντίκτυπο στο κόστος ανάπτυξης και στην εμπειρία χρήστη. Εφαρμόστε τις απαιτήσεις στο MASVS-L1 για οποιαδήποτε εφαρμογή που δεν πληροί τις προϋποθέσεις για ένα από τα υψηλότερα επίπεδα. - -###### MASVS-L2 - -- Κλάδος Υγειονομικής/Ιατρικής Περίθαλψης: Εφαρμογές για κινητά που αποθηκεύουν προσωπικά αναγνωρίσιμες πληροφορίες (PII) που μπορούν να χρησιμοποιηθούν για κλοπή ταυτότητας, πλαστές πληρωμές ή μια ποικιλία σχεδίων απάτης. Για τον τομέα της Περίθαλψης των Η.Π.Α., τα ζητήματα συμμόρφωσης περιλαμβάνουν τον Νόμο περί Φορητότητας και Λογοδοσίας Ασφάλισης Υγείας (HIPAA) για το απόρρητο, την ασφάλεια, τους κανόνες ειδοποίησης παραβίασης και τον κανόνα ασφάλειας ασθενών. -- Χρηματοοικονομικός Κλάδος: Εφαρμογές που επιτρέπουν την πρόσβαση σε εξαιρετικά ευαίσθητες πληροφορίες, όπως αριθμούς πιστωτικών καρτών, προσωπικά στοιχεία ή επιτρέπουν στον χρήστη να μετακινεί χρήματα. Αυτές οι εφαρμογές εγγυώνται πρόσθετους ελέγχους ασφαλείας για την αποφυγή απάτης. Οι οικονομικές εφαρμογές πρέπει να διασφαλίζουν τη συμμόρφωση με το Πρότυπο Ασφάλειας Δεδομένων του Κλάδου Πληρωμής (PCI DSS), το νόμο Gramm Leech Bliley και τον νόμο Sarbanes-Oxley (SOX). - -###### MASVS L1+R - -- Εφαρμογές για κινητά όπου η προστασία πνευματικής ιδιοκτησίας (IP) αποτελεί επιχειρηματικό στόχο. Τα στοιχεία ελέγχου ελαστικότητας που αναφέρονται στο MASVS-R μπορούν να χρησιμοποιηθούν για να αυξηθεί η προσπάθεια που απαιτείται για την απόκτηση του αρχικού πηγαίο κώδικα και να παρεμποδιστεί η παραβίαση/σπάσιμο. - -- Κλάδος Οnline Παιχνιδιών: Παιχνίδια με ουσιαστική ανάγκη να αποφευχθεί η τροποποίηση και η εξαπάτηση, όπως τα ανταγωνιστικά διαδικτυακά παιχνίδια. Η εξαπάτηση είναι ένα σημαντικό ζήτημα στα διαδικτυακά παιχνίδια, καθώς ένας μεγάλος αριθμός απατεώνων οδηγεί σε μια δυσαρεστημένη βάση παικτών και μπορεί τελικά να προκαλέσει την αποτυχία ενός παιχνιδιού. Το MASVS-R παρέχει βασικούς ελέγχους κατά της παραβίασης που βοηθούν στην αύξηση της προσπάθειας για τους απατεώνες. - -###### MASVS L2+R - -- Χρηματοοικονομικός Κλάδος: Εφαρμογές ηλεκτρονικής τραπεζικής που επιτρέπουν στον χρήστη να μετακινεί κεφάλαια, όπου τεχνικές όπως το code injection και instrumentation ενέχουν κίνδυνο. Σε αυτήν την περίπτωση, οι μηχανισμοί ελέγχου από το MASVS-R μπορούν να χρησιμοποιηθούν για να εμποδίσουν την παραβίαση, ανεβάζοντας τον πήχη για τους δημιουργούς κακόβουλου λογισμικού. - -- Όλες οι εφαρμογές για κινητά οι οποίες εκ κατασκευής, πρέπει να αποθηκεύουν ευαίσθητα δεδομένα στη φορητή συσκευή και ταυτόχρονα πρέπει να υποστηρίζουν ένα ευρύ φάσμα συσκευών και εκδόσεων λειτουργικού συστήματος. Σε αυτήν την περίπτωση, οι έλεγχοι ανθεκτικότητας μπορούν να χρησιμοποιηθούν ως μέτρο Άμυνας σε Βάθος (Defence in depth) για να αυξήσουν την προσπάθεια των επιτιθέμενων που στοχεύουν στην εξαγωγή των ευαίσθητων δεδομένων. - -- Οι εφαρμογές που υποστηρίζουν αγορές εντός εφαρμογής θα πρέπει ιδανικά να χρησιμοποιούν μηχανισμούς ελέγχου από την πλευρά του server και MASVS-L2 για την προστασία του επί πληρωμή περιεχομένου (paid content). Ωστόσο, ενδέχεται να υπάρχουν περιπτώσεις όπου δεν υπάρχει δυνατότητα χρήσης προστασίας από την πλευρά του server. Σε αυτές τις περιπτώσεις, οι μηχανισμοί MASVS-R θα πρέπει να εφαρμόζονται σαν έξτρα, προκειμένου να αυξηθεί η απαιτούμενα προσπάθεια του επιτιθέμενου για reversing ή tampering. diff --git a/Document-gr/0x04-Assessment_and_Certification.md b/Document-gr/0x04-Assessment_and_Certification.md deleted file mode 100644 index dd3e200ce..000000000 --- a/Document-gr/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# Αποτίμηση και Πιστοποίηση - -## Η θέση του OWASP's σχετικά με τις Πιστοποιήσεις MASVS and Σήματα Εμπιστοσύνης - -O OWASP, ως μη κερδοσκοπικός οργανισμός ουδέτερος ως προς τους προμηθευτές (vendor-neutral), δεν πιστοποιεί κανέναν vendor, verifier ή λογισμικό. - -Όλες αυτές οι διαβεβαιώσεις διασφάλισης, σήματα εμπιστοσύνης ή πιστοποιήσεις δεν ελέγχονται επίσημα, καταχωρούνται ή πιστοποιούνται από την OWASP, επομένως ένας οργανισμός που βασίζεται σε μια τέτοια άποψη πρέπει να είναι προσεκτικός όσον αφορά την εμπιστοσύνη που τίθεται σε οποιοδήποτε τρίτο μέρος ή σήμα εμπιστοσύνης που διεκδικεί (M)ASVS πιστοποίηση. - -Αυτό δεν θα πρέπει να εμποδίζει τους οργανισμούς να προσφέρουν τέτοιες υπηρεσίες διασφάλισης, εφόσον δεν διεκδικούν επίσημη πιστοποίηση OWASP. - -## Καθοδήγηση για Πιστοποίηση Mobile Εφαρμογών - -Ο συνιστώμενος τρόπος επαλήθευσης της συμμόρφωσης μιας mobile εφαρμογής με το MASVS είναι η εκτέλεση μιας ανασκόπησης "ανοιχτού βιβλίου", που σημαίνει ότι παρέχεται στους testers πρόσβαση σε σημαντικούς πόρους όπως Architects και Developers της εφαρμογής, project documentation, πηγαίος κώδικας και αυθεντικοποιήμενη πρόβαση σε endpoints, συμπεριλαμβανομένης της πρόσβασης σε τουλάχιστον έναν λογαριασμό χρήστη για κάθε ρόλο. - -Είναι σημαντικό να σημειωθεί ότι το MASVS καλύπτει μόνο την ασφάλεια της mobile εφαρμογής (από την πλευρά του client) και την επικοινωνία δικτύου μεταξύ της εφαρμογής και των απομακρυσμένων endpoints της, καθώς και μερικές βασικές και γενικές απαιτήσεις που σχετίζονται με τον έλεγχο ταυτότητας χρήστη και το session management. Δεν περιέχει συγκεκριμένες απαιτήσεις για τις απομακρυσμένες υπηρεσίες (π.χ. web services) που σχετίζονται με την εφαρμογή εκτός από ένα περιορισμένο σύνολο γενικών απαιτήσεων που σχετίζονται με την εξουσιοδότηση, τον έλεγχο ταυτότητας, την επαλήθευση μηχανισμών, και το session management. Ωστόσο, το MASVS V1 καθορίζει ότι οι απομακρυσμένες υπηρεσίες πρέπει να καλύπτονται από το συνολικό μοντέλο απειλών και να επαληθεύονται σύμφωνα με τα κατάλληλα πρότυπα, όπως το OWASP ASVS. - -Ένας οργανισμός πιστοποίησης πρέπει να περιλαμβάνει σε κάθε αναφορά το εύρος της επαλήθευσης (ιδιαίτερα εάν ένα βασικό συστατικό είναι out of scope), μια σύνοψη των ευρημάτων επαλήθευσης, συμπεριλαμβανομένων των επιτυχών και αποτυχημένων δοκιμών, με σαφείς ενδείξεις για τον τρόπο επίλυσης των αποτυχημένων δοκιμών. Η διατήρηση λεπτομερών εγγράφων εργασίας, στιγμιότυπων οθόνης (screenshots) ή screen records, σεναρίων για αξιόπιστη και επανειλημμένη εκμετάλλευση ενός ζητήματος και ηλεκτρονικών αρχείων δοκιμών, όπως η παρακολούθηση αρχείων καταγραφής διακομιστή μεσολάβησης (intercepting proxy logs) και σχετικών σημειώσεων, όπως μια λίστα εκκαθάρισης, θεωρείται τυπική πρακτική του κλάδου. Δεν αρκεί απλώς να εκτελείτε ένα εργαλείο και να αναφέρετε τις αστοχίες. Αυτό δεν παρέχει επαρκή στοιχεία ότι όλα τα ζητήματα σε επίπεδο πιστοποίησης έχουν ελεγχθεί και δοκιμαστεί διεξοδικά. Σε περίπτωση διαφωνίας, θα πρέπει να υπάρχουν επαρκή υποστηρικτικά στοιχεία που να αποδεικνύουν ότι κάθε επαληθευμένη απαίτηση έχει πράγματι δοκιμαστεί. - -### Χρησιμοποιώντας το OWASP Mobile Security Testing Guide (MSTG) - -Το OWASP MSTG είναι ένα εγχειρίδιο για τον έλεγχο της ασφάλειας των εφαρμογών για κινητά. Περιγράφει τις τεχνικές διαδικασίες για την επαλήθευση των απαιτήσεων που αναφέρονται στο MASVS. Το MSTG περιλαμβάνει μια λίστα δοκιμαστικών περιπτώσεων, καθεμία από τις οποίες αντιστοιχεί σε μια απαίτηση στο MASVS. Ενώ οι απαιτήσεις του MASVS είναι υψηλού επιπέδου και γενικές, το MSTG παρέχει εις βάθος συστάσεις και διαδικασίες δοκιμών σε βάση λειτουργικού συστήματος ανά κινητό. - -### Ο ρόλος των εργαλείων αυτοματοποιμένου testing ασφάλειας - -Η χρήση scanners πηγαίου κώδικα και εργαλείων black-box testing ενθαρρύνεται προκειμένου να αυξηθεί η αποτελεσματικότητα όποτε είναι δυνατόν. Ωστόσο, δεν είναι δυνατή η ολοκλήρωση της επαλήθευσης MASVS χρησιμοποιώντας μόνο αυτοματοποιημένα εργαλεία: Κάθε mobile εφαρμογή είναι διαφορετική και η κατανόηση της συνολικής αρχιτεκτονικής, business logic και τεχνικών παγίδων των συγκεκριμένων τεχνολογιών και frameworks που χρησιμοποιούνται, είναι υποχρεωτική απαίτηση για την επαλήθευση της ασφάλειας της εφαρμογής. - -## Άλλες χρήσεις - -### Ως λεπτομερή καθοδήγηση Αρχιτεκτονικής Ασφάλειας - -Μία από τις πιο κοινές χρήσεις του Mobile Application Security Verification Standard είναι ως πόρος για Security Architects. Από τα δύο κύρια πλαίσια αρχιτεκτονικής ασφαλείας, το SABSA ή το TOGAF, λείπουν πολλές πληροφορίες που είναι απαραίτητες για την ολοκλήρωση των ελέγχων αρχιτεκτονικής ασφάλειας mobile εφαρμογών. Το MASVS μπορεί να χρησιμοποιηθεί για να καλύψει αυτά τα κενά, επιτρέποντας στους Security Architects να επιλέγουν καλύτερα στοιχεία ελέγχου για ζητήματα κοινά σε εφαρμογές για κινητά. - -### Ως αντικαταστάτη σε έτοιμες λίστες για έλεγχο Ασφαλούς Κώδικα - -Πολλοί οργανισμοί μπορούν να επωφεληθούν από την υιοθέτηση του MASVS, επιλέγοντας ένα από τα δύο επίπεδα ή διαχωρίζοντας το MASVS και αλλάζοντας αυτό που απαιτείται για το επίπεδο ρίσκου κάθε εφαρμογής με έναν συγκεκριμένο τομέα. Ενθαρρύνουμε αυτόν τον τύπο forking, εφόσον διατηρείται η ιχνηλασιμότητα, έτσι ώστε εάν μια εφαρμογή έχει περάσει την απαίτηση 4.1, αυτό σημαίνει το ίδιο πράγμα για τα forked αντίγραφα όπως εξελίσσεται το πρότυπο. - -### Ως μια βάση Μεθοδολογίας για Τεστ Ασφάλειας - -Μια καλή μεθοδολογία δοκιμής ασφάλειας mobile εφαρμογών θα πρέπει να καλύπτει όλες τις απαιτήσεις που αναφέρονται στο MASVS. To OWASP Mobile Security Testing Guide (MSTG) περιγράφει περιπτώσεις δοκιμών black-box και white-box για κάθε απαίτηση επαλήθευσης. - -### Ως ένας οδηγός για αυτοματοποιημένο Unit και Integration testing - -Το MASVS έχει σχεδιαστεί για να είναι εξαιρετικά ελεγχόμενο, με μόνη εξαίρεση τις αρχιτεκτονικές απαιτήσεις. Τα αυτοματοποιημένα unit, integration και acceptance tests βάσει των απαιτήσεων MASVS μπορούν να ενσωματωθούν στον κύκλο ζωής συνεχούς ανάπτυξης. Αυτό όχι μόνο αυξάνει την ευαισθητοποίηση για την ασφάλεια των προγραμματιστών, αλλά βελτιώνει επίσης τη συνολική ποιότητα των εφαρμογών που προκύπτουν και μειώνει τον αριθμό των ευρημάτων κατά τη διάρκεια δοκιμών ασφαλείας στη pre-release φάση. - -### Για εκπαίδευση Ασφαλούς Ανάπτυξης - -Το MASVS μπορεί επίσης να χρησιμοποιηθεί για τον καθορισμό χαρακτηριστικών ασφαλών mobile εφαρμογών. Πολλά μαθήματα ασφαλούς κώδικα είναι απλά μαθήματα ethical hacking με μια ελαφριά πινελιά από συμβουλές κώδικα. Αυτό δεν βοηθά τους προγραμματιστές. Αντίθετα, τα προγράμματα εκπαίδευσης Ασφαλούς Ανάπτυξης μπορούν να χρησιμοποιούν το MASVS, με μεγάλη εστίαση στους προληπτικούς ελέγχους που τεκμηριώνονται στο MASVS, αντί π.χ. τα 10 κορυφαία ζητήματα ασφαλείας κώδικα. diff --git a/Document-gr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-gr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 63b5183e7..000000000 --- a/Document-gr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,38 +0,0 @@ -# V1: Απαιτήσεις Αρχιτεκτονικής, Σχεδίασης και Μοντέλου Απειλών - -## Στόχος Ελέγχου - -Σε ένα τέλειο κόσμο η ασφάλεια θα λαμβανόταν υπόψη σε όλες τις φάσεις ανάπτυξης του λογισμικού. Ωστόσο στη πραγματικότητα, συχνά η ασφάλεια λαμβάνεται υπόψη μόνο σε τελευταία στάδια του κύκλο ζωής του λογισμικού. Πέρα από τους τεχνικούς ελέγχους, το MASVS απαιτεί να υπάρχουν διαδικασίες οι οποίες εξασφαλίζουν ότι η ασφάλεια έχει συμπεριληφθεί κατά το σχεδιασμό της Αρχιτεκτονικής της mobile εφαρμογής, και ότι οι ρόλοι λειτουργίας και ασφάλειας όλων των υποσυστημάτων της εφαρμογής είναι γνωστοί. Δεδομένου ότι οι περισσότερες mobile εφαρμογές λειτουργούν ως clients σε απομακρυσμένες υπηρεσίες, πρέπει να εξασφαλισθεί ότι κατάλληλα πρότυπα ασφάλειας εφαρμόζονται σε αυτές τις υπηρεσίες - Το απομονωμένο testing της εφαρμογής δεν είναι επαρκές. - -Η κατηγορία “V1” παραθέτει απαιτήσεις σχετικά με την αρχιτεκτονική και το design της εφαρμογης. Συνεπώς είναι η μόνη κατηγορία η οποία δεν αντιστοιχίζεται με τεχνικά τεστ στο OWASP Mobile Testing Guide. Για να καλυφθούν έννοιες όπως το threat modeling, ο ασφαλής κύκλος ζωής του λογισμικού ή η διαχείριση κλειδιών, οι χρήστες του MASVS θα πρέπει να συμβουλευτούν τα σχετικά OWASP projects ή/και άλλα προτυπα, όπως αυτά που παραθέτονται στις αναφορές παρακάτω. - -## Απαιτήσεις Ασφάλειας - -Οι απαιτήσεις για το MASVS-L1 and MASVS-L2 παρουσιάζονται παρακάτω. - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Όλα τα υποσυστήματα/μέρη της εφαρμογής έχουν εντοπιστεί και είναι γνωστό ότι χρειάζονται για την εφαρμογή. | x | x | -| **1.2** | MSTG-ARCH-2 | Οι μηχανισμοί ασφάλειας δεν εφαρμόζονται ποτε στη μεριά του client, αλλά μόνο στα απομακρυσμένα endpoints. Security controls are never enforced only on the client side | x | x | -| **1.3** | MSTG-ARCH-3 | Μια υψηλού επίπεδου αρχιτεκτονική για τη mobile εφαρμογή και όλες τις συνδεδεμένες απομακρυσμένες υπηρεσίες έχει οριστεί, και η ασφάλεια έχει προσδιοριστεί σε αυτή την αρχιτεκτονική. | x | x | -| **1.4** | MSTG-ARCH-4 | Τα δεδομένα που θεωρούνται ευαίσθητα στο σκοπό της mobile εφαρμογής, έχουν εντοπιστεί με ακρίβεια. | x | x | -| **1.5** | MSTG-ARCH-5 | Όλα τα μέρη της εφαρμογής έχουν οριστεί ως προς τον επιχειρησιακό σκοπό που εξυπηρετούν ή/και ως προς τη λειτουργικότητα ασφάλειας που παρέχουν. | | x | -| **1.6** | MSTG-ARCH-6 | Ενα threat model για τη mobile εφαρμογή και τις συσχετιζόμενες απομακρυσμένες υπηρεσίες έχει παραχθεί, και εντοπίζει πιθανές απειλές καθώς και αντίμετρα ασφάλειας. | | x | -| **1.7** | MSTG-ARCH-7 | Όλοι οι μηχανισμοί ασφάλειας έχουν μια κεντρική υλοποίηση. | | x | -| **1.8** | MSTG-ARCH-8 | Υπάρχει μια αυστηρά καθορισμένη πολιτική σχετικά με το πως γίνεται η διαχείριση των κλειδιών κρυπτογράφησης (αν υπάρχουν), και πως ο κύκλος ζωής του κλειδιού επιβάλλεται στην εφαρμογή. Ιδανικά, μπορεί να ακολουθηθεί ένα πρότυπο διαχείρισης κλειδιών όπως το NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | Υπάρχει ένας μηχανισμός για επιβολή των ενημερώσεων (updates) της mobile εφαρμογής. | | x | -| **1.10** | MSTG-ARCH-10 | Η ασφάλεια καθορίζεται σε όλα τα στάδια του κύκλου ζωής του λογισμικού. | | x | -| **1.11** | MSTG-ARCH-11 | Μια πολιτική υπεύθυνης αποκάλυψης (responsible disclosure) υπάρχει και εφαρμόζεται αποτελεσματικά. | | x | -| **1.12** | MSTG-ARCH-12 | Η εφαρμογή πρέπει να συμορφώνεται με το νομικό πλαίσιο της ιδιωτικότητας (privacy). | x | x | - - -## Αναφορές - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-gr/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-gr/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 0eeee5e6c..000000000 --- a/Document-gr/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,66 +0,0 @@ -# V2: Απαιτήσεις Αποθήκευσης Δεδομένων και Ιδιωτικότητας - -## Στόχος Ελέγχου - -Η προστασία των ευαίσθητων δεδομένων όπως τα διαπιστευτήρια του χρήστη και η ιδιωτική πληροφορία, είναι σημαντικού σκοπού στην ασφάλεια mobile εφαρμογών. Αρχικά, ευαίσθητα δεδομένα μπορεί να εκτεθούν κατα λάθος σε άλλες εφαρμογές που τρέχουν στην ίδια συσκευή αν οι μηχανισμοί του λειτουργικού συστήματος (όπως το IPC) δεν χρησιμοποιούνται κατάλληλα. Δεδομένα μπορεί καταλάθος να διαρεύσουν στο cloud, μέσω μηχανισμών αποθήκευσης, backups ή από την cache του πληκτρολόγιου. Επιπροσθέτως, οι mobile συσκευές, μπορεί να χαθούν ή κλαπούν πιο εύκολα σε σύγκριση με άλλου τύπου συσκευές, με αποτέλεσμα το να αποκτήσει φυσική πρόσβαση ένας επιτιθέμενος να είναι ένα πιο πιθανό σενάριο. Σε αυτή τη περίπτωση, επιπλέον μορφές προστασίας μπορούν να υλοποιηθούν προκειμένου να κάνουν την ανάκτηση ευαίσθητων δεδομένων πιο δύσκολη. - -Να σημειωθεί ότι το MASVS είναι προσανατολισμένος γύρω από την εφαρμογή, και δε καλύπτει πολιτικές στο επίπεδο της συσκευής όπως εκείνες που εμπλέκονται με τα λύσεις Διαχείρισης Φορητής Συσκευής (MDM). Ενθαρρύνουμε τη χρήση τέτοιων πολιτικών σε ένα Enterprise περιβάλλον για την επιπλέον ενίσχυση της ασφάλειας των δεδομένων. - -### Ορισμός των ευαίσθητων δεδομένων - -Τα Ευαίσθητα δεδομένα στο σκοπό του MASVS περιλαμβάνουν και τα διαπιστευτήρια του χρήστη, και κάθε άλλα δεδομένα που θεωρούνται ευαίσθητα στο συγκεκριμένο πλαίσιο όπως: - -- Προσωπικά Ταυτοποιήσιμη Πληροφορία (ΡΙΙ) που θα μπορούν να χρησιμοποιηθεί κακόβουλα για κλοπή ταυτότητας. Αριθμοί κοινωνικής ασφάλισης, αριθμοί πιστωτικών καρτών, αριθμοί τραπεζικών λογαριασμών, πληροφορίες υγείας, -- Πολύ ευαίσθητα δεδομένα τα οποία θα οδηγούσαν σε απώλεια φήμης ή/και οικονομικά κόστη σε περίπτωση έκθεσης τους. Πληροφορίες συμβολαίων, πληροφορίες που δε καλύπτονται απο συμφωνο περι μη αποκάλυψης πληροφοριών (non disclosure agreement), πληροφορίες management. -- Οτιδήποτε δεδομένο υποχρεούται να προστατευθεί από το νόμο ή για λόγους συμμόρφωσης. - - -## Απαιτήσεις Ασφάλειας - -Η συντριπτική πλειοψηφία των προβλημάτων αποκάλυψης δεδομένων μπορεί να αποφευχθεί ακολουθώντας απλούς κανόνες. Οι περισσότεροι από τους μηχανισμούς που περιγράφονται σε αυτό το κεφάλαιο είναι υποχρεωτικοί για όλα τα επίπεδα επαλήθευσης. - -| # | MSTG-ID | Περιγραφή | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Πρέπει να χρησιμοποιούνται οι παρεχόμενες από το σύστημα δυνατότητας αποθήκευσης διαπιστευτηρίων για να αποθηκεύονται ευαίσθητα δεδομένα όπως PII, διαπιστευτήρια χρηστών ή κλειδιά κρυπτογράφησης. | x | x | -| **2.2** | MSTG-STORAGE-2 | Ευαίσθητα δεδομένα θα πρέπει να μην αποθηκεύονται εκτός του container της εφαρμογής ή των εγκαταστάσεων αποθήκευσης διαπιστευτηρίων του συστήματος. | x | x | -| **2.3** | MSTG-STORAGE-3 | Ευαίσθητα δεδομένα δε θα πρέπει να καταγράφονται σε logs της εφαρμογής. | x | x | -| **2.4** | MSTG-STORAGE-4 | Ευαίσθητα δεδομένα δε θα πρέπει να μοιράζονται με τρίτες οντότητες, εκτός αν είναι ένα απαραίτητο μέρος της Αρχιτεκτόνικης. | x | x | -| **2.5** | MSTG-STORAGE-5 | Η cache του πληκτρολογίου έχει απενεργοποιηθεί στο input του κειμένου που επεξεργάζεται ευαίσθητα δεδομένα. | x | x | -| **2.6** | MSTG-STORAGE-6 | Ευαίσθητα δεδομένα δε θα πρέπει να εκτίθενται μέσω μηχανισμών IPC. | x | x | -| **2.7** | MSTG-STORAGE-7 | Ευαίσθητα δεδομένα όπως κωδικοί ή PINs, δε θα πρέπει να εκτίθεται μέσω της διεπαφής με το χρήστη (user interface) | x | x | -| **2.8** | MSTG-STORAGE-8 | Ευαίσθητα δεδομένα δε θα πρέπει να περιλαμβάνονται σε backups που δημιουργούνται από το λειτουργικό σύστημα.| | x | -| **2.9** | MSTG-STORAGE-9 | Η εφαρμογή αφαιρεί ευαίσθητα δεδομένα απο τα views όταν η εφαρμογή μετακινείται στο background. | | x | -| **2.10** | MSTG-STORAGE-10 | Η εφαρμογή δεν κρατάει ευαίσθητα δεδομένα στη μνήμη περισσότερο από το απαραίτητο, και η μνήμη καθαρίζεται μετά τη χρήση αυτή. | | x | -| **2.11** | MSTG-STORAGE-11 | Η εφαρμογή επιβάλει μια πολιτική ασφάλειας της συσκευής, όπως για παράδειγμα το να απαιτείται από το χρήστη να ορίσει passcode συσκευής. | | x | -| **2.12** | MSTG-STORAGE-12 | Η εφαρμογή εκπαιδεύει το χρήστη σχετικά με τους τύπους PII που επεξεργάζεται η εφαρμογή, όπως επίσης και για βέλτιστες πρακτικές ασφάλειας που πρέπει να ακολουθεί ο χρήστης κατα τη χρήση της εφαρμογής. | x | x | -| **2.13** | MSTG-STORAGE-13 | Ευαίσθητα δεδομένα δε θα πρέπει να αποθηκεύονται τοπικά στη συσκευή. Αντιθέτως, τα δεδομένα θα πρέπει να ανακτόνται από μια απομακρυσμένη υπηρεσία όταν χρειάζεται, και να αποθηκεύονται μόνο στη μνήμη.| | x | -| **2.14** | MSTG-STORAGE-14 | Αν απαιτείται τα ευαίσθητα δεδομένα να αποθηκεύονται τοπικά, πρέπει να είναι κρυπτογραφημένα με ένα κλειδί που έχει προκύψει από το hardware-backed storage το οποίο απαιτεί αυθεντικοποίηση. | | x | -| **2.15** | MSTG-STORAGE-15 | Ο τοπικός αποθηκευτικός χώρος της εφαρμογής θα πρέπει να σβήνεται μετά από έναν υπερβολικό αριθμό από αποτυχημένες προσπάθειες αυθεντικοποίησης. | | x | - -## Αναφορές - -Το OWASP Mobile Security Testing Guide παρέχει αναλυτικές οδηγίες για την επαλήθευση οδηγιών των απαιτήσεων που παρουσιάζονται σε αυτό το κεφάλαιο. - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -For more information, see also: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-gr/0x08-V3-Cryptography_Verification_Requirements.md b/Document-gr/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 286aa851e..000000000 --- a/Document-gr/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Απαιτήσεις Κρυπτογραφίας - -## Στόχος ελέγχου - -Η κρυπτογραφία είναι ένα βασικό συστατικό όταν πρόκειται για την προστασία των δεδομένων που είναι αποθηκευμένα σε μια φορητή συσκευή. Είναι επίσης μια κατηγορία όπου τα πράγματα μπορεί να πάνε τρομερά στραβά, ειδικά όταν δεν τηρούνται οι τυπικές συμβάσεις. Ο σκοπός των ελέγχων σε αυτό το κεφάλαιο είναι να διασφαλίσουν ότι η επαληθευμένη εφαρμογή χρησιμοποιεί κρυπτογραφία σύμφωνα με τις βέλτιστες πρακτικές του κλάδου, συμπεριλαμβανομένων: - -- Χρήση αποδεδειγμένων βιβλιοθηκών κρυπτογράφησης. -- Σωστή επιλογή και διαμόρφωση κρυπτογραφικών παραμέτρων. -- Μια κατάλληλη γεννήτρια τυχαίων αριθμών όπου απαιτείται τυχαιότητα. - -## Απαιτήσεις Ασφάλειας - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | Η εφαρμογή δεν βασίζεται στη συμμετρική κρυπτογραφία με hardcoded κλειδιά ως μοναδική μέθοδο κρυπτογράφησης.| x | x | -| **3.2** | MSTG-CRYPTO-2 | Η εφαρμογή χρησιμοποιεί αποδεδειγμένες υλοποιήσεις κρυπτογραφικών δυνατοτήτων. | x | x | -| **3.3** | MSTG-CRYPTO-3 | Η εφαρμογή χρησιμοποιεί κρυπτογραφικές υλοποιήσεις που είναι κατάλληλες για τη συγκεκριμένη περίπτωση χρήσης, διαμορφωμένες με παραμέτρους που συμμορφώνονται με τις βέλτιστες πρακτικές του κλάδου. | x | x | -| **3.4** | MSTG-CRYPTO-4 | Η εφαρμογή δεν χρησιμοποιεί κρυπτογραφικά πρωτόκολλα ή αλγόριθμους που θεωρούνται ευρέως καταργημένοι για λόγους ασφαλείας. | x | x | -| **3.5** | MSTG-CRYPTO-5 | Η εφαρμογή δεν επαναχρησιμοποιεί το ίδιο κρυπτογραφικό κλειδί για πολλούς σκοπούς. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Όλες οι τυχαίες τιμές δημιουργούνται χρησιμοποιώντας μια επαρκώς ασφαλή γεννήτρια τυχαίων αριθμών. | x | x | - -## References - -Το OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται σε αυτήν την ενότητα. - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -Για περισσότερες πληροφορίες δείτε επίσης: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-gr/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-gr/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 28198b600..000000000 --- a/Document-gr/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Απαιτήσεις Αυθεντικοποίησης και Διαχείρισης Session - -## Στόχος Ελέγχου - -Στις περισσότερες περιπτώσεις, οι χρήστες που συνδέονται σε μια απομακρυσμένη υπηρεσία αποτελούν αναπόσπαστο μέρος της συνολικής αρχιτεκτονικής εφαρμογών για κινητά. Παρόλο που το μεγαλύτερο μέρος της λογικής συμβαίνει στο endpoint, το MASVS ορίζει ορισμένες βασικές απαιτήσεις σχετικά με τον τρόπο διαχείρισης των λογαριασμών χρηστών και των περιόδων σύνδεσης. - -## Απαιτήσεις Επαλήθευσης Ασφάλειας - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Εάν η εφαρμογή παρέχει στους χρήστες πρόσβαση σε μια απομακρυσμένη υπηρεσία, κάποια μορφή ελέγχου ταυτότητας, όπως ο έλεγχος ταυτότητας username/κωδικού πρόσβασης, εκτελείται στο απομακρυσμένο endpoint. | x | x | -| **4.2** | MSTG-AUTH-2 | Εάν χρησιμοποιείται stateful session management, το απομακρυσμένο endpoint χρησιμοποιεί session IDs που δημιουργούνται τυχαία για τον έλεγχο ταυτότητας των requests του client χωρίς αποστολή των διαπιστευτηρίων του χρήστη. | x | x | -| **4.3** | MSTG-AUTH-3 | Εάν χρησιμοποιείται stateless αυθεντικόποιηση με βάση κάποιον token, ο server παρέχει ένα token που έχει υπογραφεί χρησιμοποιώντας έναν ασφαλή αλγόριθμο. | x | x | -| **4.4** | MSTG-AUTH-4 | Το απομακρυσμένο endpoint τερματίζει την υπάρχουσα περίοδο λειτουργίας όταν ο χρήστης αποσυνδεθεί. | x | x | -| **4.5** | MSTG-AUTH-5 | Υπάρχει μια πολιτική κωδικού πρόσβασης και επιβάλλεται στο απομακρυσμένο endpoint. | x | x | -| **4.6** | MSTG-AUTH-6 | Το απομακρυσμένο endpoint εφαρμόζει έναν μηχανισμό για προστασία από την πολλάπλή υποβολή διαπιστευτηρίων. | x | x | -| **4.7** | MSTG-AUTH-7 | Οι περίοδοι λειτουργίας ακυρώνονται στο απομακρυσμένο endpoint μετά από μια προκαθορισμένη περίοδο αδράνειας και τα session tokens λήγουν. | x | x | -| **4.8** | MSTG-AUTH-8 | Ο βιομετρικός έλεγχος ταυτότητας (εάν υπάρχει), δεν δεσμεύεται από events (δηλαδή, χρησιμοποιώντας ένα API που απλώς επιστρέφει "true" ή "false"). Αντίθετα, βασίζεται στο ξεκλείδωμα του keychain/keystore. | | x | -| **4.9** | MSTG-AUTH-9 | Ένας δεύτερος παράγοντας ελέγχου ταυτότητας υπάρχει στο απομακρυσμένο endpoint και η απαίτηση 2FA επιβάλλεται με συνέπεια. | | x | -| **4.10** | MSTG-AUTH-10 | Οι ευαίσθητες συναλλαγές απαιτούν διπλό έλεγχο ταυτότητας (step-up authentication). | | x | -| **4.11** | MSTG-AUTH-11 | Η εφαρμογή ενημερώνει τον χρήστη για όλες τις ευαίσθητες δραστηριότητες με τον λογαριασμό του. Οι χρήστες μπορούν να προβάλουν μια λίστα συσκευών, να προβάλουν πληροφορίες με βάση στοιχεία (διεύθυνση IP, τοποθεσία κλπ.) και να αποκλείσουν συγκεκριμένες συσκευές. | | x | -| **4.12** | MSTG-AUTH-12 | Τα μοντέλα εξουσιοδότησης θα πρέπει να ορίζονται και να επιβάλλονται στο απομακρυσμένο endpoint. | x | x | - -## Αναφορές - -To OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται παραπάνω. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-gr/0x10-V5-Network_communication_requirements.md b/Document-gr/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 9eeae2525..000000000 --- a/Document-gr/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Απαιτήσεις Επικοινωνίας Δικτύου - -## Στόχος Ελέγχου - -Ο σκοπός των στοιχείων ελέγχου που παρατίθενται σε αυτήν την ενότητα είναι να διασφαλίσουν την εμπιστευτικότητα και την ακεραιότητα των πληροφοριών που ανταλλάσσονται μεταξύ της mobile εφαρμογής και των τελικών απομακρυσμένων endpoints. Τουλάχιστον, μια mobile εφαρμογή πρέπει να δημιουργήσει ένα ασφαλές, κρυπτογραφημένο κανάλι για επικοινωνία δικτύου χρησιμοποιώντας το πρωτόκολλο TLS με τις κατάλληλες ρυθμίσεις. Το επίπεδο 2 παραθέτει πρόσθετο μέτρο άμυνας σε βάθος, όπως το SSL pinning. - -## Απαιτήσεις Επαλήθευσης Ασφάλειας - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Τα δεδομένα κρυπτογραφούνται στο δίκτυο χρησιμοποιώντας TLS. Το ασφαλές κανάλι χρησιμοποιείται με συνέπεια σε όλη την εφαρμογή. | x | x | -| **5.2** | MSTG-NETWORK-2 | Οι ρυθμίσεις TLS είναι σύμφωνες με τις τρέχουσες βέλτιστες πρακτικές ή όσο το δυνατόν πλησιέστερα εάν το mobile λειτουργικό σύστημα δεν υποστηρίζει τα προτεινόμενα πρότυπα. | x | x | -| **5.3** | MSTG-NETWORK-3 | Η εφαρμογή επαληθεύει το πιστοποιητικό X.509 του απομακρυσμένου endpoint όταν δημιουργηθεί το ασφαλές κανάλι. Γίνονται αποδεκτά μόνο πιστοποιητικά υπογεγραμμένα από αξιόπιστη Aρχή έκδοσης πιστοποιητικών (CA). | x | x | -| **5.4** | MSTG-NETWORK-4 | Η εφαρμογή είτε χρησιμοποιεί το δικό της χώρο αποθήκευσης πιστοποιητικών, είτε κάνει pin το πιστοποιητικό του endpoint ή το δημόσιο κλειδί και στη συνέχεια, δεν δημιουργεί συνδέσεις με endpoints που προσφέρουν διαφορετικό πιστοποιητικό ή κλειδί, ακόμη και αν είναι υπογεγραμμένα από αξιόπιστη αρχή έκδοσης πιστοποιητικών. | | x | -| **5.5** | MSTG-NETWORK-5 | Η εφαρμογή δεν βασίζεται σε ένα ανασφαλές κανάλι επικοινωνίας (email ή SMS) για κρίσιμες λειτουργίες, όπως εγγραφές και ανάκτηση λογαριασμού. | | x | -| **5.6** | MSTG-NETWORK-6 | Η εφαρμογή εξαρτάται μόνο από ενημερωμένες βιβλιοθήκες συνδεσιμότητας και ασφάλειας. | | x | - -## Αναφορές - -Tο OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται σε αυτήν την ενότητα. - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-gr/0x11-V6-Interaction_with_the_environment.md b/Document-gr/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 42677e311..000000000 --- a/Document-gr/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Απαιτήσεις Αλληλεπίδρασης με τη Πλατφόρμα - -## Στόχος Ελέγχου - -Τα στοιχεία ελέγχου αυτής της ομάδας διασφαλίζουν ότι η εφαρμογή χρησιμοποιεί τα APIs της πλατφόρμας και standard μέρη της με ασφαλή τρόπο. Επιπλέον, τα στοιχεία ελέγχου καλύπτουν την επικοινωνία μεταξύ εφαρμογών (IPC). - -## Απαιτήσεις Επαλήθευσης Ασφάλειας - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | Η εφαρμογή ζητά μόνο το ελάχιστο σύνολο απαραίτητων αδειών. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Όλες τα inputs από εξωτερικές πηγές καθώς και ο χρήστης επικυρώνονται, και εάν χρειάζεται, γίνονται sanitize. Αυτό περιλαμβάνει δεδομένα που λαμβάνονται μέσω της διεπαφής χρήστη (UI), μηχανισμούς IPC, όπως intents, προσαρμοσμένα URLs και πηγές δικτύου. | x | x | -| **6.3** | MSTG-PLATFORM-3 | Η εφαρμογή δεν εξάγει ευαίσθητες λειτουργίες μέσω προσαρμοσμένων URL schemes, εκτός εάν αυτοί οι μηχανισμοί προστατεύονται σωστά. | x | x | -| **6.4** | MSTG-PLATFORM-4 | Η εφαρμογή δεν εξάγει ευαίσθητη λειτουργικότητα μέσω IPC δυνατοτήτων, εκτός εάν αυτοί οι μηχανισμοί προστατεύονται κατάλληλα. | x | x | -| **6.5** | MSTG-PLATFORM-5 | Η JavaScript είναι απενεργοποιημένη στα WebViews, εκτός εάν απαιτείται ρητά. | x | x | -| **6.6** | MSTG-PLATFORM-6 | Τα WebViews έχουν ρυθμιστεί ώστε να επιτρέπουν μόνο το ελάχιστο σύνολο απαιτούμενων protocol handlers (ιδανικά, υποστηρίζεται μόνο το https). Οι δυνητικά επικίνδυνοι handlers, όπως το file, το tel και το app-id, είναι απενεργοποιημένα.| x | x | -| **6.7** | MSTG-PLATFORM-7 | Εάν οι native μέθοδοι της εφαρμογής εκτίθενται σε ένα WebView, βεβαιωθείτε ότι το WebView αποδίδει μόνο JavaScript που περιέχεται στο package της εφαρμογής. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Το object deserialization (εάν υπάρχει), υλοποιείται με χρήση ασφαλών serialization APIs. | x | x | -| **6.9** | MSTG-PLATFORM-9 | Η εφαρμογή προστατεύεται από επιθέσεις επικάλυψης οθόνης (screen overlay attacks, μόνο για Android) | | x | -| **6.10** | MSTG-PLATFORM-10 | Η cache, το storage και οι φορτωμένοι πόροι (JavaScript, κ.λπ.) ενός WebView θα πρέπει να διαγραφούν πριν καταστραφεί το WebView. | | x | -| **6.11** | MSTG-PLATFORM-11 | Επαληθεύστε ότι η εφαρμογή αποτρέπει τη χρήση τρίτων (custom) πληκτρολογίων, όποτε εισάγονται ευαίσθητα δεδομένα (μόνο για iOS).| | x | - -## Αναφορές - -Tο OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται σε αυτήν την ενότητα. - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-gr/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-gr/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 4183ea271..000000000 --- a/Document-gr/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Απαιτήσεις Ποιότητας Κώδικα και Ρύθμισης Build - -## Στόχος Ελέγχου - -Ο στόχος αυτού του ελέγχου είναι να διασφαλίσει ότι ακολουθούνται βασικές πρακτικές ασφαλούς κώδικα κατά την ανάπτυξη της εφαρμογής, και ότι ενεργοποιούνται οι "δωρεάν" δυνατότητες ασφαλείας που προσφέρονται από τον μεταγλωττιστή. - -## Απαιτήσεις Επαλήθευσης Ασφάλειας - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | Η εφαρμογή είναι υπογεγραμμένη και εφοδιασμένη με έγκυρο πιστοποιητικό, του οποίου το ιδιωτικό κλειδί προστατεύεται κατάλληλα. | x | x | -| **7.2** | MSTG-CODE-2 | Η εφαρμογή έχει δημιουργηθεί σε λειτουργία έκδοσης (release mode), με ρυθμίσεις κατάλληλες για ένα release build (π.χ. χωρίς τη δυνατότητα debugging). | x | x | -| **7.3** | MSTG-CODE-3 | Tα debugging symbols έχουν αφαιρεθεί από τα native binaries | x | x | -| **7.4** | MSTG-CODE-4 | Κώδικας Debugging and κώδικας που χρησιμοποιείται για βοήθεια του developer (πχ test code, backdoors, κρυφές ρυθμίσεις) έχουν αφαιρεθεί. Η εφαρμογή δε καταγράφει αναλυτικά (verbose) error ή debugging μηνύματα. | x | x | -| **7.5** | MSTG-CODE-5 | Όλα τα τρίτα στοιχεία/υποσυστήματα που χρησιμοποιούνται από την mobile εφαρμογή, όπως βιβλιοθήκες και frameworks, εντοπίζονται και ελέγχονται για γνωστές ευπάθειες. | x | x | -| **7.6** | MSTG-CODE-6 | Η εφαρμογή εντοπίζει και χειρίζεται πιθανά exceptions. | x | x | -| **7.7** | MSTG-CODE-7 | H λογική διαχείρισης σφαλμάτων (error handling logic) στoυς μηχανισμούς ασφαλείας δεν επιτρέπει τη by default πρόσβαση. | x | x | -| **7.8** | MSTG-CODE-8 | Στον unmanaged κώδικα η μνήμη γίνεται allocate, freed και χρησιμοποιείται με ασφάλεια | x | x | -| **7.9** | MSTG-CODE-9 | Ενεργοποιούνται δωρεάν λειτουργίες ασφαλείας που προσφέρει το toolchain, όπως byte-code minimization , stack protection, PIE support, και reference counting. | x | x | - -## Αναφορές - -Tο OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται σε αυτήν την ενότητα. - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-gr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-gr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 30e7a232e..000000000 --- a/Document-gr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,71 +0,0 @@ -# V8: Απαιτήσεις Ανθεκτικότητας - -## Στόχος Ελέγχου - -Αυτή η ενότητα καλύπτει μέτρα άμυνας σε βάθος (defense-in-depth) που προτείνονται για εφαρμογές που επεξεργάζονται ή παρέχουν πρόσβαση σε ευαίσθητα δεδομένα ή λειτουργίες. Η έλλειψη κάποιου από αυτά τα στοιχεία ελέγχου δεν προκαλεί ευπάθεια. Αντίθετα, προορίζονται να αυξήσουν την ανθεκτικότητα της εφαρμογής έναντι τoυ reverse engineering και συγκεκριμένων επιθέσεων από την πλευρά του client. - -Οι έλεγχοι σε αυτήν την ενότητα θα πρέπει να εφαρμοστούν όπως πρέπει, η αξιολόγηση των κινδύνων που προκαλείται από μη εξουσιοδοτημένη παραβίαση της εφαρμογής ή/και του reverse engineering του κώδικα. Προτείνουμε να συμβουλευτείτε το έγγραφο του OWASP "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" (βλ. παραπομπές παρακάτω) για μια λίστα κινδύνων και σχετικών τεχνικών απειλών. - -Για να είναι αποτελεσματικό οποιοδήποτε από τα στοιχεία ελέγχου της παρακάτω λίστας, η εφαρμογή πρέπει να πληροί τουλάχιστον όλα τα MASVS-L1 (δηλαδή, πρέπει να υπάρχουν σταθερά στοιχεία ελέγχου ασφαλείας), καθώς και όλες τις απαιτήσεις με χαμηλότερο αριθμό στο V8. Για παράδειγμα, τα obfuscation controls που παρατίθενται στην ενότητα "Παρεμπόδιση Κατανόησης (Impede Comprehension)" πρέπει να συνδυάζονται με την "Παρεμπόδιση δυναμικής ανάλυσης και παραβίασης (Ιmpede Dynamic Analysis and Tampering)" και "Δέσμευση με τη συσκευή (Device Binding)". - -**Λάβετε υπόψη ότι οι προστασίες λογισμικού δεν πρέπει ποτέ να χρησιμοποιούνται ως αντικατάσταση των στοιχείων ελέγχου ασφαλείας. Τα στοιχεία ελέγχου που αναφέρονται στο MASVR-R προορίζονται να προσθέσουν ειδικά για την απειλή, πρόσθετα προστατευτικά στοιχεία ελέγχου σε εφαρμογές που πληρούν επίσης τις απαιτήσεις ασφαλείας MASVS.** - -Ισχύουν οι ακόλουθες εκτιμήσεις: - -1. Πρέπει να οριστεί ένα μοντέλο απειλών που να περιγράφει με σαφήνεια τις απειλές από την πλευρά του client που πρόκειται να προστατευθούν. Επιπλέον, πρέπει να προσδιορίζεται ο βαθμός προστασίας που προορίζεται να παρέχει το σύστημα. Για παράδειγμα, ένας δηλωμένος στόχος θα μπορούσε να είναι να αναγκαστούν οι δημιουργοί στοχευμένου malware που επιδιώκουν να βλάψουν την εφαρμογή να επενδύσουν σημαντική προσπάθεια manual reverse engineering. - -2. Το μοντέλο απειλής πρέπει να είναι αξιόπιστο και σχετικό. Για παράδειγμα, η απόκρυψη ενός κρυπτογραφικού κλειδιού σε μια ανοιχτού κώδικα (white box) υλοποίησης μπορεί να αποδειχθεί περιττή, εάν ένας επιτιθέμενος μπορεί απλώς να υποκλέψει απευθείας το κώδικα. - -3. Η αποτελεσματικότητα της προστασίας θα πρέπει πάντα να επαληθεύεται από έναν άνθρωπο, ειδικό με πείρα στη δοκιμή των συγκεκριμένων τύπων anti-tampering και obfuscation που χρησιμοποιούνται (βλ. επίσης τα κεφάλαια "reverse engineering" και "assessing software protections" στο OWASP Mobile Security Testing Guide) - - - -### Παρεμπόδιση δυναμικής ανάλυσης και παραβίασης (Impede Dynamic Analysis and Tampering) - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | Η εφαρμογή εντοπίζει και ανταποκρίνεται στη παρουσία μιας rooted/jailbroken συσκευής είτε προειδοποιώντας το χρήστη είτε τερματίζοντας την εφαρμογή. | x | -| **8.2** | MSTG-RESILIENCE-2 | Η εφαρμογή εντοπίζει και ανταποκρίνεται σε ένα debugger που είναι σε χρήση. Όλα τα διαθέσιμα πρωτόκολλα debugging πρέπει να καλύπτονται. | x | -| **8.3** | MSTG-RESILIENCE-3 | Η εφαρμογή εντοπίζει και ανταποκρίνεται στη παραβίαση και τροποποίηση εκτελέσιμων αρχείων ή σημαντικών δεδομένων μέσα στο sandbox της. | x | -| **8.4** | MSTG-RESILIENCE-4 | Η εφαρμογή εντοπίζει και ανταποκρίνεται στη παρουσία ευρέως χρησιμοποιούμενων εργαλείων και frameworks στη συσκευή. | x | -| **8.5** | MSTG-RESILIENCE-5 | Η εφαρμογή εντοπίζει και ανταποκρίνεται στη λειτουργία μέσα σε emulator. | x | -| **8.6** | MSTG-RESILIENCE-6 | Η εφαρμογή εντοπίζει και ανταποκρίνεται στη παραβίαση και τροποποίηση του κώδικα και των δεδομένων μέσα στο memory space της. | x | -| **8.7** | MSTG-RESILIENCE-7 | Η εφαρμογή εφαρμόζει πολλαπλούς μηχανισμούς σε κάθε κατηγορία άμυνας (8.1 έως 8.6). Σημειώστε ότι η ανθεκτικότητα κλιμακώνεται με την ποσότητα και την ποικιλομορφία της πρωτοτυπίας των μηχανισμών που χρησιμοποιούνται. | x | -| **8.8** | MSTG-RESILIENCE-8 | Οι μηχανισμοί ανίχνευσης ενεργοποιούν αποκρίσεις διαφορετικών τύπων, συμπεριλαμβανομένων καθυστερημένων και κρυφών αποκρίσεων. | x | -| **8.9** | MSTG-RESILIENCE-9 | Το obfuscation εφαρμόζεται σε προγραμματικές άμυνες, οι οποίες με τη σειρά τους εμποδίζουν τo deobfuscation μέσω δυναμικής ανάλυσης. | x | - - -### Δέσμευση με τη συσκευή (Device Binding) - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | Η εφαρμογή υλοποιεί μια λειτουργία «σύνδεσης συσκευής» (device binding) χρησιμοποιώντας ένα δακτυλικό αποτύπωμα συσκευής που προέρχεται από πολλαπλές ιδιότητες μοναδικές για τη συσκευή. | x | - -### Παρεμπόδιση Κατανόησης (Impede Comprehension) - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Όλα τα εκτελέσιμα αρχεία και οι βιβλιοθήκες που ανήκουν στην εφαρμογή είτε είναι κρυπτογραφημένα σε επίπεδο αρχείου ή/και σημαντικά τμήματα κώδικα και δεδομένων μέσα στα εκτελέσιμα είναι κρυπτογραφημένα ή packed. Μια βασική στατική ανάλυση δεν αποκαλύπτει σημαντικό κώδικα ή δεδομένα.| x | -| **8.12** | MSTG-RESILIENCE-12 | Εάν ο στόχος του obfuscation είναι η προστασία ευαίσθητων υπολογισμών, χρησιμοποιείται ένα obfuscation scheme που είναι κατάλληλο για τη συγκεκριμένη εργασία και ανθεκτικό έναντι των χειροκίνητων (manual) και αυτοματοποιημένων μεθόδων deobfuscation, λαμβάνοντας υπόψη την τρέχουσα δημοσιευμένη έρευνα. Η αποτελεσματικότητα του συστήματος deobfuscation πρέπει να επαληθευτεί μέσω manual tests. Σημειώστε ότι οι λειτουργίες απομόνωσης που βασίζονται στο hardware προτιμώνται έναντι του obfuscation όποτε είναι δυνατόν. | x | - -### Παρεμπόδιση Καταγραφής (Impede Eavesdropping) - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Ως άμυνα σε βάθος (defense-in-depth), εκτός από τo σταθερό hardening των μερών/υποσυστημάτων που επικοινωνούν, μπορεί να εφαρμοστεί κρυπτογράφηση payload σε επίπεδο εφαρμογής για να εμποδίσει περαιτέρω την υποκλοπή. | x | - - - -## Αναφορές - -Tο OWASP Mobile Security Testing Guide παρέχει λεπτομερείς οδηγίες για την επαλήθευση των απαιτήσεων που αναφέρονται σε αυτήν την ενότητα. - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -Για περισσότερες πληροφορίες, δείτε επίσης: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-gr/0x90-Appendix-A_Glossary.md b/Document-gr/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 5e8c17888..000000000 --- a/Document-gr/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Παράρτημα Α: Γλωσσάρι - -- **Address Space Layout Randomization (ASLR)** – Μια τεχνική για να κάνει πιο δύσκολη την εκμετάλλευση σφαλμάτων τύπου memory corruption. -- **Application Security** – Η ασφάλεια σε επίπεδο εφαρμογής εστιάζει στην ανάλυση στοιχείων που αποτελούν το επίπεδο εφαρμογής του Μοντέλου Αναφοράς Διασύνδεσης Ανοικτών Συστημάτων (OSI Model), αντί να εστιάζει, για παράδειγμα, στο υποκείμενο λειτουργικό σύστημα ή στα συνδεδεμένα δίκτυα. -- **Application Security Verification** – Η τεχνική αξιολόγηση μιας εφαρμογής έναντι του OWASP MASVS. -- **Application Security Verification Report** – Μια αναφορά που τεκμηριώνει τα συνολικά αποτελέσματα και την υποστηρικτική ανάλυση που παράγεται από τον ελεγκτή για μια συγκεκριμένη εφαρμογή. -- **Authentication** – Η επαλήθευση της διεκδικούμενης ταυτότητας ενός χρήστη εφαρμογής. -- **Automated Verification** – Η χρήση αυτοματοποιημένων εργαλείων (είτε εργαλεία δυναμικής ανάλυσης, εργαλεία στατικής ανάλυσης ή και τα δύο) που χρησιμοποιούν υπογραφές ευπαθειών για την εύρεση προβλημάτων. -- **Black Box Testing** – Είναι μια μέθοδος δοκιμής λογισμικού που εξετάζει τη λειτουργικότητα μιας εφαρμογής χωρίς να εξετάζει τις εσωτερικές δομές ή τις λειτουργίες της. -- **Component** – Μια αυτόνομη μονάδα κώδικα, με συσχετισμένες διεπαφές δίσκου και δικτύου που επικοινωνεί με άλλα στοιχεία. -- **Cross-Site Scripting (XSS)** – Μια ευπάθεια ασφαλείας που συνήθως εντοπίζεται σε εφαρμογές web που επιτρέπει την εισαγωγή σεναρίων από την πλευρά του πελάτη στο περιεχόμενο. -- **Cryptographic Module** – Υλικό, λογισμικό ή/και υλικολογισμικό που εφαρμόζει κρυπτογραφικούς αλγόριθμους ή/και δημιουργεί κρυπτογραφικά κλειδιά. -- **CWE** – Το CWE είναι μια λίστα κοινών αδυναμιών ασφάλειας λογισμικού που έχει αναπτυχθεί από την κοινότητα. Χρησιμεύει ως μια κοινή γλώσσα, ένα μέσο μέτρησης για εργαλεία ασφάλειας λογισμικού και ως βάση για τον εντοπισμό αδυναμιών, τον μετριασμό και τις προσπάθειες πρόληψης. -- **Dynamic Application Security Testing (DAST)** – Οι τεχνολογίες DAST έχουν σχεδιαστεί για να ανιχνεύουν συνθήκες που υποδεικνύουν μια ευπάθεια ασφαλείας σε μια εφαρμογή σε κατάσταση λειτουργίας. -- **Design Verification** – Η τεχνική αξιολόγηση της αρχιτεκτονικής ασφαλείας μιας εφαρμογής. -- **Dynamic Verification** – Η χρήση αυτοματοποιημένων εργαλείων που χρησιμοποιούν υπογραφές ευπαθειών για την εύρεση προβλημάτων κατά την εκτέλεση μιας εφαρμογής. -- **Globally Unique Identifier (GUID)** – Ένας μοναδικός αριθμός αναφοράς που χρησιμοποιείται ως αναγνωριστικό στο λογισμικό. -- **Hyper Text Transfer Protocol (HTTP)** – Ένα πρωτόκολλο εφαρμογής για κατανεμημένα, συνεργατικά, πληροφοριακά συστήματα υπερμέσων. Είναι το θεμέλιο της επικοινωνίας δεδομένων για τον Παγκόσμιο Ιστό. -- **Hardcoded Keys** – Κρυπτογραφικά κλειδιά που είναι αποθηκευμένα στην ίδια τη συσκευή. -- **IPC** – Inter Process Communications, Στο IPC, οι διεργασίες επικοινωνούν μεταξύ τους και με τον πυρήνα για να συντονίσουν τις δραστηριότητές τους. -- **Input Validation** – Η κανονικοποίηση και η επικύρωση των μη αξιόπιστων εισροών χρήστη. -- **Java Bytecode** – Το bytecode Java είναι το σύνολο εντολών της εικονικής μηχανής Java (JVM). Κάθε bytecode αποτελείται από ένα, ή σε ορισμένες περιπτώσεις δύο byte που αντιπροσωπεύουν την εντολή (opcode), μαζί με μηδέν ή περισσότερα byte για τη μετάδοση παραμέτρων. -- **Malicious Code** – Ο κώδικας που εισήχθη σε μια εφαρμογή κατά την ανάπτυξή της εν αγνοία του κατόχου της εφαρμογής, ο οποίος παρακάμπτει την επιδιωκόμενη πολιτική ασφαλείας της εφαρμογής. Δεν είναι το ίδιο με κακόβουλο λογισμικό, όπως ιός ή ιός τύπου worm! -- **Malware** – Εκτελέσιμος κώδικας που εισάγεται σε μια εφαρμογή κατά τη διάρκεια του χρόνου εκτέλεσης χωρίς τη γνώση του χρήστη ή του διαχειριστή της εφαρμογής. -- **Open Web Application Security Project (OWASP)** – Το Open Web Application Security Project (OWASP) είναι μια παγκόσμια δωρεάν και ανοιχτή κοινότητα που επικεντρώνεται στη βελτίωση της ασφάλειας του λογισμικού εφαρμογών. Η αποστολή μας είναι να κάνουμε την ασφάλεια των εφαρμογών «ορατή», έτσι ώστε άτομα και οργανισμοί να μπορούν να λαμβάνουν τεκμηριωμένες αποφάσεις σχετικά με τους κινδύνους ασφάλειας εφαρμογών. βλ: -- **Personally Identifiable Information (PII)** – PII είναι πληροφορίες που μπορούν να χρησιμοποιηθούν από μόνες τους ή με άλλες πληροφορίες για την αναγνώριση, επαφή ή εντοπισμό ενός μεμονωμένου ατόμου ή για την αναγνώριση ενός ατόμου στο πλαίσιο. -- **Position-Independent Executable (PIE)** – Ένα PIE είναι ένα μερός κώδικα μηχανής που, τοποθετημένο κάπου στην κύρια μνήμη, εκτελείται σωστά ανεξάρτητα από την απόλυτη διεύθυνσή (absolute address) του. -- **Public Key Infrastructure (PKI)** – Το PKI είναι μια διάταξη που δεσμεύει δημόσια κλειδιά με αντίστοιχες ταυτότητες οντοτήτων. Η δέσμευση καθορίζεται μέσω μιας διαδικασίας εγγραφής και έκδοσης πιστοποιητικών σε και από μια αρχή έκδοσης πιστοποιητικών (CA). -- **Static Application Security Testing (SAST)** – Το SAST είναι ένα σύνολο τεχνολογιών που έχουν σχεδιαστεί για να αναλύουν τον πηγαίο κώδικα εφαρμογής, τον κώδικα byte και τα binary αρχεία για την κωδικοποίηση και τις συνθήκες σχεδιασμού που είναι ενδεικτικές ευπάθειας ασφαλείας. Οι λύσεις SAST αναλύουν μια εφαρμογή από "μέσα προς τα έξω" σε κατάσταση που δεν εκτελείται. -- **SDLC** – Κύκλος ζωής ανάπτυξης λογισμικού. -- **Security Architecture** – Μια περίληψη του σχεδιασμού μιας εφαρμογής που προσδιορίζει και περιγράφει πού και πώς χρησιμοποιούνται οι μηχανισμοί ελέγχου ασφαλείας, καθώς επίσης και προσδιορίζει και περιγράφει τη θέση και την ευαισθησία τόσο των δεδομένων χρήστη όσο και της εφαρμογής. -- **Security Configuration** – Η διαμόρφωση κατά το χρόνο εκτέλεσης (runtime configuration) μιας εφαρμογής που επηρεάζει τον τρόπο χρήσης των μηχανισμών ασφαλείας. -- **Security Control** – Μια συνάρτηση ή στοιχείο που εκτελεί έλεγχο ασφαλείας (π.χ. μηχανισμός ελέγχου πρόσβασης) ή όταν καλείται έχει ως αποτέλεσμα μια ενέργεια ασφαλείας (π.χ. δημιουργία αρχείου ελέγχου). -- **SQL Injection (SQLi)** – Μια τεχνική έγχυσης κώδικα (code injection) που χρησιμοποιείται για την επίθεση σε εφαρμογές που βασίζονται σε δεδομένα, στην οποία εισάγονται κακόβουλες δηλώσεις SQL σε ένα σημείο εισόδου. -- **SSO Authentication** – To Single Sign On (SSO) συμβαίνει όταν ένας χρήστης συνδέεται σε έναν client και στη συνέχεια συνδέεται αυτόματα σε άλλους clients, ανεξάρτητα από την πλατφόρμα, την τεχνολογία ή τον τομέα που χρησιμοποιεί ο χρήστης. Για παράδειγμα, όταν συνδέεστε στο google, συνδέεστε αυτόματα στην υπηρεσία youtube, έγγραφα και αλληλογραφία. -- **Threat Modeling** – Μια τεχνική που αποτελείται από την ανάπτυξη ολοένα και πιο εκλεπτυσμένων αρχιτεκτονικών ασφαλείας για τον εντοπισμό παραγόντων απειλής, ζώνες ασφαλείας, ελέγχους ασφαλείας και σημαντικά τεχνικά και επιχειρηματικά περιουσιακά στοιχεία. -- **Transport Layer Security** – Κρυπτογραφικά πρωτόκολλα που παρέχουν ασφάλεια επικοινωνίας μέσω Διαδικτύου -- **URI and URL** – Ένα Uniform Resource Identifier (URI) είναι μια συμβολοσειρά χαρακτήρων που χρησιμοποιούνται για την αναγνώριση ενός ονόματος ή ενός πόρου Ιστού. Ένας Uniform Resource Locator (URL) χρησιμοποιείται συχνά ως αναφορά σε έναν πόρο. -- **User Acceptance Testing (UAT)** – Παραδοσιακά ένα περιβάλλον δοκιμής που συμπεριφέρεται όπως το περιβάλλον παραγωγής όπου όλες οι δοκιμές λογισμικού εκτελούνται πριν από τη μετάδοση. -- **Verifier** – Το άτομο ή η ομάδα που εξετάζει μια εφαρμογή σε σχέση με τις απαιτήσεις του OWASP MASVS. -- **Whitelist** – Μια λίστα με επιτρεπόμενα δεδομένα ή λειτουργίες, για παράδειγμα μια λίστα χαρακτήρων που επιτρέπεται να εκτελούν επικύρωση εισόδου. -- **X.509 Certificate** – Ένα πιστοποιητικό X.509 είναι ένα ψηφιακό πιστοποιητικό που χρησιμοποιεί το ευρέως αποδεκτό διεθνές πρότυπο υποδομής δημόσιου κλειδιού X.509 (PKI) για να επαληθεύσει ότι ένα δημόσιο κλειδί ανήκει στον χρήστη, τον υπολογιστή ή την ταυτότητα υπηρεσίας που περιέχεται στο πιστοποιητικό. diff --git a/Document-gr/0x91-Appendix-B_References.md b/Document-gr/0x91-Appendix-B_References.md deleted file mode 100644 index 7db8dec5e..000000000 --- a/Document-gr/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Παράρτημα Β: Αναφορές - -Τα ακόλουθα έργα του OWASP είναι πολύ πιθανό να είναι χρήσιμα στους χρήστες αυτού του προτύπου: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Security Testing Guide - [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -Ομοίως, οι ακόλουθοι ιστότοποι είναι πολύ πιθανό να είναι χρήσιμοι στους χρήστες αυτού του προτύπου: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-gr/CHANGELOG.md b/Document-gr/CHANGELOG.md deleted file mode 100644 index d1a92d2a7..000000000 --- a/Document-gr/CHANGELOG.md +++ /dev/null @@ -1,99 +0,0 @@ -# Αρχείο καταγραφής αλλαγών (Changelog) - -## V1.3.1 και νεότερη έκδοση - -Όλα τα Changelog μας είναι διαθέσιμα στο διαδίκτυο στο Github repo OWASP MASVS, ανατρέξτε στo [Releases page](https://github.com/OWASP/owasp-masvs/releases). - -## V1.3 - 13 Μαΐου 2021 - -Είμαστε περήφανοι που ανακοινώνουμε την εισαγωγή ενός document build pipeline, ο οποίος αποτελεί σημαντικό ορόσημο για το έργο μας. Το build pipeline βασίζεται στο [Pandocker](https://github.com/dalibo/pandocker) και στο [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows ). -Αυτό μειώνει σημαντικά τον χρόνο που δαπανάται για τη δημιουργία νέων εκδόσεων και θα αποτελέσει επίσης τη βάση για το OWASP MSTG και θα διατεθεί για το έργο OWASP ASVS. - -### Αλλαγές - -- Υπάρχουν διαθέσιμες 4 ακόμη μεταφράσεις, οι οποίες είναι Hindi, Farsi, Πορτογαλικά και Πορτογαλικά Βραζιλίας -- Προστέθηκε η απαίτηση MSTG-PLATFORM-11 - -### Ιδιαίτερες ευχαριστίες - -- Το Jeroen Willemsen για την έναρξη αυτής της πρωτοβουλίας πέρυσι! -- Το Damien Clochard και το Dalibo για την υποστήριξη και την επαγγελματοποίηση του build pipeline. -- Όλοι οι Hindi, Farsi, Πορτογάλοι και Βραζιλιάνοι συνεργάτες μας για την εξαιρετική μεταφραστική δουλειά. - -## V1.2 - 7 Μαρτίου 2020 - Διεθνής κυκλοφορία - -Οι ακόλουθες αλλαγές αποτελούν μέρος της έκδοσης 1.2: - -- Διατίθεται μετάφραση του MASVS στα απλοποιημένα κινέζικα. -- Αλλαγή τίτλου στο εξώφυλλο του βιβλίου MASVS. -- Αφαιρέθηκε το Mobile Top 10 και το CWE από το MSTG και συγχωνεύτηκαν σε υπάρχουσες αναφορές στο MASVS. - -## V1.2-RC - 5 Οκτωβρίου 2019 - Προέκδοση (μόνο στα Αγγλικά) - -Οι ακόλουθες αλλαγές αποτελούν μέρος της προέκδοσης 1.2: - -- Προαγωγή σε flagship status. -- Η απαίτηση άλλαξε: MSTG-STORAGE-1 "πρέπει να χρησιμοποιηθεί". -- Προστίθενται οι απαιτήσεις MSTG-STORAGE-13, MSTG-STORAGE-14 και MSTG-STORAGE-15 με έμφαση στην προστασία δεδομένων. -- Η απαίτηση MSTG-AUTH-11 ενημερώθηκε για τη διατήρηση των συναφών πληροφοριών. -- Η απαίτηση MSTG-CODE-4 ενημερώθηκε για να καλύπτει περισσότερα από απλώς το debugging. -- Η απαίτηση MSTG-PLATFORM-10 προστέθηκε για την περαιτέρω ασφαλή χρήση των WebViews. -- Η απαίτηση MSTG-AUTH-12 προστέθηκε για να υπενθυμίζει στους προγραμματιστές την εφαρμογή εξουσιοδοτήσεων, ειδικά στην περίπτωση εφαρμογών πολλών χρηστών. -- Προστέθηκε λίγη περισσότερη περιγραφή για το πώς θα πρέπει να χρησιμοποιείται το MASVS με βάση την αξιολόγηση κινδύνου. -- Προστέθηκε λίγη περισσότερη περιγραφή για το περιεχόμενο επί πληρωμή. -- Η απαίτηση MSTG-ARCH-11 προστέθηκε για να συμπεριλάβει μια πολιτική Υπεύθυνης Αποκάλυψης (ΝDA) για εφαρμογές L2. -- Η απαίτηση MSTG-ARCH-12 προστέθηκε για να δείξει στους προγραμματιστές εφαρμογών ότι πρέπει να τηρούνται οι σχετικοί διεθνείς νόμοι περί απορρήτου και ιδιωτικότητας. -- Δημιούργησε ένα συνεπές στυλ για όλες τις αναφορές στην αγγλική έκδοση. -- Η απαίτηση MSTG-PLATFORM-11 προστέθηκε για την καταπολέμηση της κατασκοπείας μέσω πληκτρολογίων τρίτων. -- Η απαίτηση MSTG-MSTG-RESILIENCE-13 προστέθηκε για να εμποδίσει την υποκλοπή σε μια εφαρμογή. - -## V1.1.4 - 4 Ιουλίου 2019 - Έκδοση summit - -Οι ακόλουθες αλλαγές αποτελούν μέρος της έκδοσης 1.1.4: - -- Διορθώθηκαν όλα τα ζητήματα σήμανσης. -- Ενημερώσεις στη γαλλική και ισπανική μετάφραση. -- Μεταφράστηκε το αρχείο καταγραφής αλλαγών (changelog) στα Κινέζικα (ZHTW) και στα Ιαπωνικά. -- Αυτοματοποιημένη επαλήθευση της σύνταξης σήμανσης και της προσβασιμότητας των διευθύνσεων URL. -- Προστέθηκαν κωδικοί αναγνώρισης στις απαιτήσεις, οι οποίοι θα συμπεριληφθούν στη μελλοντική έκδοση του MSTG για να βρίσκετε εύκολα τις συστάσεις και τις δοκιμαστικές περιπτώσεις. -- Μειώθηκε το μέγεθος του repo και προστέθηκε το Generated στο .gitignore. -- Προστέθηκε ένας Κώδικας Δεοντολογίας & Οδηγίες Συνεισφοράς. -- Προστέθηκε ένα πρότυπο Pull-Request. -- Ενημερώθηκε ο συγχρονισμός με το repo που χρησιμοποιείται για τη φιλοξενία του ιστότοπου Gitbook. -- Ενημερώθηκαν τα σενάρια για τη δημιουργία XML/JSON/CSV για όλες τις μεταφράσεις. -- Μεταφράστηκε ο Πρόλογος στα Κινέζικα (ZHTW). - -## V1.1.3 - 9 Ιανουαρίου 2019 - Μικρές διορθώσεις - -- Διορθώστε το ζήτημα μετάφρασης της απαίτησης 7.1 στην ισπανική έκδοση -- Νέα ρύθμιση μεταφραστών σε ευχαριστίες - -## V1.1.2 - 3 Ιανουαρίου 2019 - Χορηγία και διεθνοποίηση - -Οι ακόλουθες αλλαγές αποτελούν μέρος της έκδοσης 1.1.2: - -- Προστέθηκε ευχαριστήριο σημείωμα για τους αγοραστές του ηλεκτρονικού βιβλίου. -- Προστέθηκε σύνδεσμος ελέγχου ταυτότητας που λείπει και ενημερώθηκε ο κατεστραμμένος σύνδεσμος ελέγχου ταυτότητας στο V4. -- Διορθώθηκε το swap μεταξύ 4.7 και 4.8 στα Αγγλικά. -- Πρώτη διεθνής κυκλοφορία! - - Διορθώσεις σε ισπανική μετάφραση. Η μετάφραση είναι πλέον σε συγχρονισμό με τα Αγγλικά (1.1.2). - - Διορθώσεις σε ρωσική μετάφραση. Η μετάφραση είναι πλέον σε συγχρονισμό με τα Αγγλικά (1.1.2). - - Προστέθηκε η πρώτη κυκλοφορία των Κινεζικών (ZHTW) Γαλλικών, Γερμανικών και Ιαπωνικών! -- Απλοποιημένο έγγραφο για ευκολία στη μετάφραση. -- Προστέθηκαν οδηγίες για αυτοματοποιημένες εκδόσεις. - -## V1.1.0 - 14 Ιουλίου 2018 - -Οι ακόλουθες αλλαγές αποτελούν μέρος της έκδοσης 1.1: - -- Αφαιρέθηκε η Απαίτηση 2.6 "Το πρόχειρο είναι απενεργοποιημένο σε πεδία κειμένου που ενδέχεται να περιέχουν ευαίσθητα δεδομένα.". -- Προστέθηκε η Απαίτηση 2.2 "Δεν πρέπει να αποθηκεύονται ευαίσθητα δεδομένα εκτός του κοντέινερ της εφαρμογής ή των εγκαταστάσεων αποθήκευσης διαπιστευτηρίων συστήματος." -- Η απαίτηση 2.1 αναδιατυπώθηκε σε "Οι εγκαταστάσεις αποθήκευσης διαπιστευτηρίων συστήματος χρησιμοποιούνται κατάλληλα για την αποθήκευση ευαίσθητων δεδομένων, όπως PII, διαπιστευτήρια χρήστη ή κρυπτογραφικά κλειδιά.". - -## V1.0 12 - Ιανουάριος 2018 - -Οι ακόλουθες αλλαγές αποτελούν μέρος της έκδοσης 1.0: - -- Διεγράφη το 8.9 ως ταυτόσημο του 8.12 -- Το 4.6 έγινε πιο γενικό -- Μικρές διορθώσεις (τυπογραφικά λάθη κλπ.) diff --git a/Document-gr/GLOSSARY.md b/Document-gr/GLOSSARY.md deleted file mode 100644 index afc286da0..000000000 --- a/Document-gr/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Παράρτημα Α: Γλωσσάρι - -## Address Space Layout Randomization (ASLR) - -Μια τεχνική για να κάνει πιο δύσκολη την εκμετάλλευση σφαλμάτων τύπου memory corruption. - -## Application Security - -Η ασφάλεια σε επίπεδο εφαρμογής εστιάζει στην ανάλυση στοιχείων που αποτελούν το επίπεδο εφαρμογής του Μοντέλου Αναφοράς Διασύνδεσης Ανοικτών Συστημάτων (OSI Model), αντί να εστιάζει, για παράδειγμα, στο υποκείμενο λειτουργικό σύστημα ή στα συνδεδεμένα δίκτυα. - -## Application Security Verification - -Η τεχνική αξιολόγηση μιας εφαρμογής έναντι του OWASP MASVS. - -## Application Security Verification Report - -Μια αναφορά που τεκμηριώνει τα συνολικά αποτελέσματα και την υποστηρικτική ανάλυση που παράγεται από τον ελεγκτή για μια συγκεκριμένη εφαρμογή. - -## Authentication - -Η επαλήθευση της διεκδικούμενης ταυτότητας ενός χρήστη εφαρμογής. - -## Automated Verification - -Η χρήση αυτοματοποιημένων εργαλείων (είτε εργαλεία δυναμικής ανάλυσης, εργαλεία στατικής ανάλυσης ή και τα δύο) που χρησιμοποιούν υπογραφές ευπαθειών για την εύρεση προβλημάτων. - -## Black box testing - -Είναι μια μέθοδος δοκιμής λογισμικού που εξετάζει τη λειτουργικότητα μιας εφαρμογής χωρίς να εξετάζει τις εσωτερικές δομές ή τις λειτουργίες της. - -## Component - -Μια αυτόνομη μονάδα κώδικα, με συσχετισμένες διεπαφές δίσκου και δικτύου που επικοινωνεί με άλλα στοιχεία. - -## Cross-Site Scripting (XSS) - -Μια ευπάθεια ασφαλείας που συνήθως εντοπίζεται σε εφαρμογές web που επιτρέπει την εισαγωγή σεναρίων από την πλευρά του πελάτη στο περιεχόμενο. - -## Cryptographic module - -Υλικό, λογισμικό ή/και υλικολογισμικό που εφαρμόζει κρυπτογραφικούς αλγόριθμους ή/και δημιουργεί κρυπτογραφικά κλειδιά. - -## CWE - -Το CWE είναι μια λίστα κοινών αδυναμιών ασφάλειας λογισμικού που έχει αναπτυχθεί από την κοινότητα. Χρησιμεύει ως μια κοινή γλώσσα, ένα μέσο μέτρησης για εργαλεία ασφάλειας λογισμικού και ως βάση για τον εντοπισμό αδυναμιών, τον μετριασμό και τις προσπάθειες πρόληψης. - -## DAST - -Οι τεχνολογίες DAST έχουν σχεδιαστεί για να ανιχνεύουν συνθήκες που υποδεικνύουν μια ευπάθεια ασφαλείας σε μια εφαρμογή σε κατάσταση λειτουργίας. - -## Design Verification - -Η τεχνική αξιολόγηση της αρχιτεκτονικής ασφαλείας μιας εφαρμογής. - -## Dynamic Verification - -Η χρήση αυτοματοποιημένων εργαλείων που χρησιμοποιούν υπογραφές ευπαθειών για την εύρεση προβλημάτων κατά την εκτέλεση μιας εφαρμογής. - -## Globally Unique Identifier(GUID) - -Ένας μοναδικός αριθμός αναφοράς που χρησιμοποιείται ως αναγνωριστικό στο λογισμικό. - -## Hyper Text Transfer Protocol(HTTP) - -Ένα πρωτόκολλο εφαρμογής για κατανεμημένα, συνεργατικά, πληροφοριακά συστήματα υπερμέσων. Είναι το θεμέλιο της επικοινωνίας δεδομένων για τον Παγκόσμιο Ιστό. - -## Hardcoded keys - -Κρυπτογραφικά κλειδιά που είναι αποθηκευμένα στην ίδια τη συσκευή. - -## IPC - -Inter Process Communications, Στο IPC, οι διεργασίες επικοινωνούν μεταξύ τους και με τον πυρήνα για να συντονίσουν τις δραστηριότητές τους. - -## Input Validation - -Η κανονικοποίηση και η επικύρωση των μη αξιόπιστων εισροών χρήστη. - -## JAVA Bytecode - -Το bytecode Java είναι το σύνολο εντολών της εικονικής μηχανής Java (JVM). Κάθε bytecode αποτελείται από ένα, ή σε ορισμένες περιπτώσεις δύο byte που αντιπροσωπεύουν την εντολή (opcode), μαζί με μηδέν ή περισσότερα byte για τη μετάδοση παραμέτρων. - -## Malicious Code - -Ο κώδικας που εισήχθη σε μια εφαρμογή κατά την ανάπτυξή της εν αγνοία του κατόχου της εφαρμογής, ο οποίος παρακάμπτει την επιδιωκόμενη πολιτική ασφαλείας της εφαρμογής. Δεν είναι το ίδιο με κακόβουλο λογισμικό, όπως ιός ή ιός τύπου worm! - -## Malware - -Εκτελέσιμος κώδικας που εισάγεται σε μια εφαρμογή κατά τη διάρκεια του χρόνου εκτέλεσης χωρίς τη γνώση του χρήστη ή του διαχειριστή της εφαρμογής. - -## Open Web Application Security Project (OWASP) - -Το Open Web Application Security Project (OWASP) είναι μια παγκόσμια δωρεάν και ανοιχτή κοινότητα που επικεντρώνεται στη βελτίωση της ασφάλειας του λογισμικού εφαρμογών. Η αποστολή μας είναι να κάνουμε την ασφάλεια των εφαρμογών «ορατή», έτσι ώστε άτομα και οργανισμοί να μπορούν να λαμβάνουν τεκμηριωμένες αποφάσεις σχετικά με τους κινδύνους ασφάλειας εφαρμογών. βλ: - -## Personally Identifiable Information (PII) - -PII είναι πληροφορίες που μπορούν να χρησιμοποιηθούν από μόνες τους ή με άλλες πληροφορίες για την αναγνώριση, επαφή ή εντοπισμό ενός μεμονωμένου ατόμου ή για την αναγνώριση ενός ατόμου στο πλαίσιο. - -## PIE - -Ένα PIE είναι ένα μερός κώδικα μηχανής που, τοποθετημένο κάπου στην κύρια μνήμη, εκτελείται σωστά ανεξάρτητα από την απόλυτη διεύθυνσή (absolute address) του. - -## PKI - -Το PKI είναι μια διάταξη που δεσμεύει δημόσια κλειδιά με αντίστοιχες ταυτότητες οντοτήτων. Η δέσμευση καθορίζεται μέσω μιας διαδικασίας εγγραφής και έκδοσης πιστοποιητικών σε και από μια αρχή έκδοσης πιστοποιητικών (CA). - -## SAST - -Το SAST είναι ένα σύνολο τεχνολογιών που έχουν σχεδιαστεί για να αναλύουν τον πηγαίο κώδικα εφαρμογής, τον κώδικα byte και τα binary αρχεία για την κωδικοποίηση και τις συνθήκες σχεδιασμού που είναι ενδεικτικές ευπάθειας ασφαλείας. Οι λύσεις SAST αναλύουν μια εφαρμογή από "μέσα προς τα έξω" σε κατάσταση που δεν εκτελείται. - -## SDLC - -Κύκλος ζωής ανάπτυξης λογισμικού. - -## Security Architecture - -Μια περίληψη του σχεδιασμού μιας εφαρμογής που προσδιορίζει και περιγράφει πού και πώς χρησιμοποιούνται οι μηχανισμοί ελέγχου ασφαλείας, καθώς επίσης και προσδιορίζει και περιγράφει τη θέση και την ευαισθησία τόσο των δεδομένων χρήστη όσο και της εφαρμογής. - -## Security Configuration - -Η διαμόρφωση κατά το χρόνο εκτέλεσης (runtime configuration) μιας εφαρμογής που επηρεάζει τον τρόπο χρήσης των μηχανισμών ασφαλείας. - -## Security Control - -Μια συνάρτηση ή στοιχείο που εκτελεί έλεγχο ασφαλείας (π.χ. μηχανισμός ελέγχου πρόσβασης) ή όταν καλείται έχει ως αποτέλεσμα μια ενέργεια ασφαλείας (π.χ. δημιουργία αρχείου ελέγχου). - -## SQL Injection (SQLi) - -Μια τεχνική έγχυσης κώδικα (code injection) που χρησιμοποιείται για την επίθεση σε εφαρμογές που βασίζονται σε δεδομένα, στην οποία εισάγονται κακόβουλες δηλώσεις SQL σε ένα σημείο εισόδου. - -## SSO Authentication - -To Single Sign On (SSO) συμβαίνει όταν ένας χρήστης συνδέεται σε έναν client και στη συνέχεια συνδέεται αυτόματα σε άλλους clients, ανεξάρτητα από την πλατφόρμα, την τεχνολογία ή τον τομέα που χρησιμοποιεί ο χρήστης. Για παράδειγμα, όταν συνδέεστε στο google, συνδέεστε αυτόματα στην υπηρεσία youtube, έγγραφα και αλληλογραφία. - -## Threat Modeling - -Μια τεχνική που αποτελείται από την ανάπτυξη ολοένα και πιο εκλεπτυσμένων αρχιτεκτονικών ασφαλείας για τον εντοπισμό παραγόντων απειλής, ζώνες ασφαλείας, ελέγχους ασφαλείας και σημαντικά τεχνικά και επιχειρηματικά περιουσιακά στοιχεία. - -## Transport Layer Security - -Κρυπτογραφικά πρωτόκολλα που παρέχουν ασφάλεια επικοινωνίας μέσω Διαδικτύου - -## URI and URL - -Ένα Uniform Resource Identifier (URI) είναι μια συμβολοσειρά χαρακτήρων που χρησιμοποιούνται για την αναγνώριση ενός ονόματος ή ενός πόρου Ιστού. Ένας Uniform Resource Locator (URL) χρησιμοποιείται συχνά ως αναφορά σε έναν πόρο. - -## User acceptance testing (UAT) - -Παραδοσιακά ένα περιβάλλον δοκιμής που συμπεριφέρεται όπως το περιβάλλον παραγωγής όπου όλες οι δοκιμές λογισμικού εκτελούνται πριν από τη μετάδοση. - -## Verifier - -Το άτομο ή η ομάδα που εξετάζει μια εφαρμογή σε σχέση με τις απαιτήσεις του OWASP MASVS. - -## Whitelist - -Μια λίστα με επιτρεπόμενα δεδομένα ή λειτουργίες, για παράδειγμα μια λίστα χαρακτήρων που επιτρέπεται να εκτελούν επικύρωση εισόδου. - -## X.509 Certificate - -Ένα πιστοποιητικό X.509 είναι ένα ψηφιακό πιστοποιητικό που χρησιμοποιεί το ευρέως αποδεκτό διεθνές πρότυπο υποδομής δημόσιου κλειδιού X.509 (PKI) για να επαληθεύσει ότι ένα δημόσιο κλειδί ανήκει στον χρήστη, τον υπολογιστή ή την ταυτότητα υπηρεσίας που περιέχεται στο πιστοποιητικό. diff --git a/Document-gr/SUMMARY.md b/Document-gr/SUMMARY.md deleted file mode 100644 index 38e1ed8ed..000000000 --- a/Document-gr/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Πίνακας Περιεχομένων - -- [Ημερολόγιο Αλλαγών](CHANGELOG.md) -- [Πρόλογος](0x01-Foreword.md) -- [Εξώφυλλο](0x02-Frontispiece.md) -- [Χρησιμοποιώντας το MASVS](0x03-Using_the_MASVS.md) -- [Αποτίμηση και Πιστοποίηση](0x04-Assessment_and_Certification.md) - -## Απαιτήσεις Ασφάλειας - -- [V1: Απαιτήσεις Αρχιτεκτονικής, Σχεδιασμού και Μοντέλου Απειλών](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Απαιτήσεις Αποθήκευσης Δεδομένων και Ιδιωτικότητας](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Απαιτήσεις Κρυπτογραφίας](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Απαιτήσεις Αυθεντικοποίησης και Διαχείρισης Session](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Απαιτήσεις Δικτυακής Επικοινωνίας](0x10-V5-Network_communication_requirements.md) -- [V6: Απαιτήσεις για Αλληλεπίδραση με τη Πλατφόρμα](0x11-V6-Interaction_with_the_environment.md) -- [V7: Απαιτήσεις Ποιότητας Κώδικα και Ρυθμίσεων Build](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Απαιτήσεις Ανθεκτικότητας](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Παράρτημα - -- [Παράρτημα A - Γλωσσάρι](GLOSSARY.md) -- [Παράρτημα B - Αναφορές](0x91-Appendix-B_References.md) diff --git a/Document-gr/book.json b/Document-gr/book.json deleted file mode 100644 index a5c5d593d..000000000 --- a/Document-gr/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "gr" -} diff --git a/Document-gr/images/CC-license.png b/Document-gr/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-gr/images/CC-license.png and /dev/null differ diff --git a/Document-gr/images/Donators/donators.png b/Document-gr/images/Donators/donators.png deleted file mode 100644 index 2e25ebd72..000000000 Binary files a/Document-gr/images/Donators/donators.png and /dev/null differ diff --git a/Document-gr/images/GitHub_logo.png b/Document-gr/images/GitHub_logo.png deleted file mode 100644 index ea6ff545a..000000000 Binary files a/Document-gr/images/GitHub_logo.png and /dev/null differ diff --git a/Document-gr/images/MASVS-levels.png b/Document-gr/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-gr/images/MASVS-levels.png and /dev/null differ diff --git a/Document-gr/images/OWASP_logo.png b/Document-gr/images/OWASP_logo.png deleted file mode 100644 index 9baaef889..000000000 Binary files a/Document-gr/images/OWASP_logo.png and /dev/null differ diff --git a/Document-gr/images/license.png b/Document-gr/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-gr/images/license.png and /dev/null differ diff --git a/Document-gr/images/masvs-levels-new.jpg b/Document-gr/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-gr/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-gr/images/masvs-mini-cover.png b/Document-gr/images/masvs-mini-cover.png deleted file mode 100644 index c7985e14c..000000000 Binary files a/Document-gr/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-gr/images/masvs-progress.png b/Document-gr/images/masvs-progress.png deleted file mode 100644 index aa01d9f7d..000000000 Binary files a/Document-gr/images/masvs-progress.png and /dev/null differ diff --git a/Document-gr/images/slack_logo.png b/Document-gr/images/slack_logo.png deleted file mode 100644 index 6967050a0..000000000 Binary files a/Document-gr/images/slack_logo.png and /dev/null differ diff --git a/Document-gr/images/twitter_logo.png b/Document-gr/images/twitter_logo.png deleted file mode 100644 index b52f15964..000000000 Binary files a/Document-gr/images/twitter_logo.png and /dev/null differ diff --git a/Document-gr/metadata.md b/Document-gr/metadata.md deleted file mode 100644 index f3b2bfcfa..000000000 --- a/Document-gr/metadata.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -# This is the main metadata file. -# Variables below can be overwritten by the local metadata -# file (e.g. Document-fr/metadata.md) - -# Custom Template variables (cover, first page, etc.) -version: 'SNAPSHOT' # this will overridden at build time -languagetext: '' - -mainfont: 'DejaVu Sans' -sansfont: 'DejaVu Sans' -monofont: 'DejaVu Sans Mono' - -# General variables -toc: true -toc-depth: 2 -# numbersections: true -# secnumdepth: 2 -linkcolor: blue - -# Language variables -lang: 'gr' - -# Latex variables - -# Eisvogel Latex variables -# https://github.com/Wandmalfarbe/pandoc-latex-template#custom-template-variables -code-block-font-size: '\tiny' - -table-use-row-colors: true -geometry: "top=1cm,left=1cm,right=2cm,bottom=4cm" ---- - diff --git a/Document-gr/metadata.yml b/Document-gr/metadata.yml deleted file mode 100644 index c7700ff67..000000000 --- a/Document-gr/metadata.yml +++ /dev/null @@ -1,3 +0,0 @@ -language: 'en' -languagetext: '' -toc_title: 'Table of Contents' diff --git a/Document-hi/0x01-Foreword.md b/Document-hi/0x01-Foreword.md deleted file mode 100644 index 3f9543c2f..000000000 --- a/Document-hi/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# प्रस्तावना - -तकनीकी क्रांतियां बहुत जल्दी हो जाती हैं। एक दशक पहले तक भारी और छोटे की-बोर्ड वाले मोबाइल तकनीकी प्रेमियों के लिए महंगी वस्तुएँ हुआ करती थी। आज स्मार्टफोन्स हमारे जीवन का एक अहम् हिस्सा हैं। हम सूचना, नेविगेशन और संचार के लिए उन पर भरोसा करने लगे हैं, और वे हमारे व्यापारिक तथा सामाजिक जीवन में सर्वव्यापी हैं। - -हर नई तकनीक अपने साथ एक नया सिक्योरिटी रिस्क लेकर आती है और उसी परिवर्तन के साथ काम करना सिक्योरिटी इंडस्ट्री के व्यापार के लिए चुनौतीपूर्ण होता है। रक्षात्मक पक्ष हमेशा कुछ कदम पीछे होता है। उदाहरण के लिए, कई लोगों के लिए डिफ़ॉल्ट रिफ्लेक्स चीजों को करने के पुराने तरीकों को लागू करना था: स्मार्टफोन छोटे कंप्यूटरों की तरह हैं, और मोबाइल एप्लिकेशन क्लासिक सॉफ्टवेयर की तरह हैं, इसलिए निश्चित रूप से सुरक्षा आवश्यकताएं समान हैं? लेकिन यह उस तरह काम नहीं करता है। स्मार्टफ़ोन ऑपरेटिंग सिस्टम डेस्कटॉप ऑपरेटिंग सिस्टम से अलग होते हैं, और मोबाइल ऐप वेब ऐप से अलग होते हैं। उदाहरण के लिए, हस्ताक्षर-आधारित वायरस स्कैनिंग की पुरानी विधि आधुनिक मोबाइल OS वातावरण में कोई मतलब नहीं रखती है: न केवल यह मोबाइल ऐप वितरण मॉडल के साथ असंगत है, यह सैंडबॉक्सिंग प्रतिबंधों के कारण तकनीकी रूप से भी असंभव है। इसके अलावा, कुछ भेद्यता कक्षाएं, जैसे बफर ओवरफ्लो और XSS मुद्दे,साधारण मोबाइल ऐप के संदर्भ में कम प्रासंगिक हैं, जैसे, डेस्कटॉप ऐप और वेब एप्लिकेशन (अपवाद लागू होते हैं)। - -समय के साथ, हमारे उद्योग ने मोबाइल खतरे के परिदृश्य पर बेहतर पकड़ बना ली है। जैसा कि यह पता चला है, मोबाइल सिक्योरिटी डेटा सिक्योरिटी के बारे में ही है: ऐप्स हमारी व्यक्तिगत जानकारी, फोटो, रिकॉर्डिंग, नोट्स, खाता डेटा, व्यावसायिक जानकारी, स्थान और बहुत कुछ संग्रहित करते हैं। वे ग्राहकों के रूप में कार्य करते हैं जो हमें दैनिक आधार पर उपयोग की जाने वाली सेवाओं से जोड़ते हैं, और एक संचार हब के रूप में भी जो प्रत्येक संदेश को समझ कर आगे भेजते हैं जिन्हे हम दूसरों के साथ आदान-प्रदान करते हैं। अगर आप किसी का स्मार्टफोन हैक करें तो आपको उस व्यक्ति के जीवन के बारे में सब जानकारी प्राप्त करने की पहुँच मिल जाती है। जब हम मानते हैं कि मोबाइल डिवाइस अधिक आसानी से खो जाते हैं या चोरी हो जाते हैं और मोबाइल मैलवेयर बढ़ रहा है, तो डेटा सिक्योरिटी की आवश्यकता और भी स्पष्ट हो जाती है। - -इसलिए मोबाइल ऐप्स के लिए एक सिक्योरिटी स्टैण्डर्ड/मानक इस बात पर केंद्रित होना चाहिए कि मोबाइल एप्लिकेशन संवेदनशील जानकारी को कैसे संभालें संग्रहित करें तथा उनकी सुरक्षा करें। यदि iOS और एंड्रॉइड जैसे आधुनिक मोबाइल ऑपरेटिंग सिस्टम सुरक्षित डेटा भंडारण और संचार के लिए अच्छे APIs देते हैं, तब भी उन्हें प्रभावी होने के लिए सही तरीके से कार्यान्वित और उपयोग किया जाना चाहिए। डेटा भंडारण, इंटर-ऐप संचार, क्रिप्टोग्राफ़िक APIs का उचित उपयोग और सुरक्षित नेटवर्क संचार केवल कुछ ऐसे पहलू हैं जिनके लिए सावधानीपूर्वक विचार की आवश्यकता होती है। - -उद्योग की सर्वसम्मति की आवश्यकता में एक महत्वपूर्ण सवाल यह है कि डेटा की गोपनीयता और अखंडता की रक्षा में किस हद तक कार्य करना चाहिए। उदाहरण के लिए, हम में से अधिकांश इस बात से सहमत होंगे कि एक मोबाइल ऐप को TLS एक्सचेंज में सर्वर प्रमाणपत्र को सत्यापित करना चाहिए। लेकिन एसएसएल प्रमाणपत्र पिनिंग के बारे में क्या? क्या इसका परिणाम भेद्यता/वल्नेरेबिलिटी नहीं होगा? अगर कोई ऐप संवेदनशील डेटा को हैंडल करता है, तो क्या यह एक आवश्यकता होनी चाहिए, या क्या यह काउंटर-प्रोडक्टिव भी है? क्या हमें OS सैंडबॉक्स एप्लिकेशन के बावजूद भी SQLite डेटाबेस में संग्रहीत डेटा को एन्क्रिप्ट करने की आवश्यकता है? जो एक ऐप के लिए उपयुक्त है वह दूसरे के लिए अवास्तविक हो सकता है। MASVS सत्यापन आवश्यकताओं का उपयोग करके इन आवश्यकताओं को स्टैण्डर्डअइस/मानकीकृत करने का एक प्रयास है जो विभिन्न खतरे परिदृश्यों में सटीक बैठता है। - -इसके अलावा, रूट मालवेयर और रिमोट एडमिनिस्ट्रेशन टूल्स/उपकरणों की उपस्थिति ने इस तथ्य के बारे में जागरूकता पैदा की है कि मोबाइल ऑपरेटिंग सिस्टम में स्वयं में शोषणीय खामियां हैं, इसलिए कंटेनरीकरण रणनीतियों का उपयोग संवेदनशील डेटा को अतिरिक्त सुरक्षा प्रदान करने और क्लाइंट-साइड छेड़छाड़ को रोकने के लिए ज़्यादा किया जा रहा है। और यहीं पर चीजें जटिल हो जाती हैं। हार्डवेयर समर्थित सुरक्षा सुविधाएँ और OS- स्तर के कन्टेनराइज़ेशन समाधान, जैसे कि Android for Work और Samsung Knox मौजूद हैं, लेकिन वे विभिन्न उपकरणों पर लगातार उपलब्ध नहीं हैं। एक बैंड-ऐड सहायता के रूप में, सॉफ़्टवेयर-आधारित सुरक्षा उपायों को लागू करना संभव है - लेकिन दुर्भाग्य से, इस प्रकार की सुरक्षा को सत्यापित करने के लिए कोई स्टैण्डर्ड/मानक या परीक्षण प्रक्रिया नहीं हैं। - -फलस्वरूप, मोबाइल ऐप सुरक्षा परीक्षण रिपोर्ट रिपोर्ट सभी जगह हैं: उदाहरण के लिए, कुछ परीक्षक एंड्रॉइड ऐप में "सिक्योरिटी/सुरक्षा दोष" के रूप में अस्पष्टता या रुट डिटेक्शन की कमी की रिपोर्ट करते हैं। दूसरी ओर, स्ट्रिंग एनक्रिप्शन, डीबगर डिटेक्शन या कंट्रोल फ्लो अस्पष्टता जैसे उपायों को अनिवार्य नहीं माना जाता है। हालाँकि, चीजों को देखने का यह दोहरा तरीका समझ में नहीं आता है क्योंकि लचीलापन एक दोहरा प्रस्ताव नहीं है: यह विशेष क्लाइंट-साइड खतरों पर निर्भर करता है जिसका उद्देश्य बचाव करना है। सॉफ़्टवेयर सिक्योरिटी बेकार नहीं हैं, लेकिन वे अंततः बायपास हो सकते हैं, इसलिए उन्हें सुरक्षा नियंत्रण के लिए विकल्प के रूप में कभी भी उपयोग नहीं किया जाना चाहिए। - -MASVS का संपूर्ण लक्ष्य मोबाइल एप्लिकेशन सुरक्षा (MASVS- L1) के लिए आधार रेखा की पेशकश करना है, जबकि रक्षा-में-गहराई उपायों (MASVS-L2) को शामिल करने और क्लाइंट-साइड स्थितियों (MASVS-R) के खिलाफ सुरक्षा के लिए भी अनुमति देता है। MASVS का प्रयोग निम्नलिखित के लिए किया जाता है: - -- सुरक्षित मोबाइल एप्लिकेशन विकसित करने के इच्छुक सॉफ्टवेयर आर्किटेक्ट और डेवलपर्स के लिए आवश्यकताएं प्रदान करने के लिए; -- एक इंडस्ट्री स्टैण्डर्ड/मानक पेश करने के लिए जिसका मोबाइल ऐप सुरक्षा समीक्षाओं के लिए परीक्षण किया जा सकता है; -- मोबाइल सुरक्षा में सॉफ्टवेयर सुरक्षा तंत्र की भूमिका को स्पष्ट करना और उनकी प्रभावशीलता को सत्यापित करने के लिए आवश्यकताएं प्रदान करना; -- विभिन्न उपयोग के मामलों के लिए सुरक्षा के स्तर का सुझाव किस स्तर तक किया जा सकता है, इसके लिए विशिष्ट सुझाव प्रदान करना। - -हम जानते हैं कि 100% उद्योग की सहमति प्राप्त करना असंभव है। फिर भी, हम आशा करते हैं कि MASVS मोबाइल एप्लिकेशन विकास और परीक्षण के सभी चरणों में मार्गदर्शन प्रदान करने में उपयोगी है। एक खुले स्रोत स्टैण्डर्ड/मानक के रूप में, MASVS समय के साथ विकसित होगा, तथा इसके लिए हम किसी भी योगदान और सुझावों का स्वागत करते हैं। - -बर्नहार्ड म्यूलर द्वारा diff --git a/Document-hi/0x02-Frontispiece.md b/Document-hi/0x02-Frontispiece.md deleted file mode 100644 index 936824b34..000000000 --- a/Document-hi/0x02-Frontispiece.md +++ /dev/null @@ -1,55 +0,0 @@ -# मानक के बारे में - -![OWASP Logo](images/OWASP_logo.png) - -मोबाइल एप्लिकेशन सुरक्षा सत्यापन मानक (MASVS) 1.1 में आपका स्वागत है। MASVS आईओएस (iOS) और एंड्रॉइड पर सुरक्षित मोबाइल एप्लिकेशन को डिजाइन, विकसित और परीक्षण करने के लिए आवश्यक सुरक्षा आवश्यकताओं के ढांचे को स्थापित करने का एक सामुदायिक प्रयास है। - -MASVS सामुदायिक प्रयास और उद्योग की प्रतिक्रिया के चरम बिंदु है। हम उम्मीद करते हैं कि यह मानक समय के साथ विकसित होगा और समुदाय से प्रतिक्रिया का स्वागत करेगा। - -हमारे साथ संपर्क करने का सबसे अच्छा तरीका OWASP मोबाइल प्रोजेक्ट स्लैक चैनल है: . - -निम्नलिखित URL पर खाते बनाए जा सकते हैं: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## कॉपीराइट और लाइसेंस - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -कॉपीराइट © 2021 OWASP Foundation.यह काम एक [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/) के तहत लाइसेंस प्राप्त है। किसी भी तरह के पुन: उपयोग या वितरण के लिए, आपको इस कार्य के लाइसेंस की शर्तों को दूसरों को स्पष्ट करना चाहिए। - -
-
- -## आभार - -| प्रोजेक्ट लीड | लीड लेखक | योगदानकर्ता और समीक्षक | -| --------- | --------- | ------------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | -
- -| भाषा | अनुवादक और समीक्षक | -| --- | ------------------ | -| ब्राजिलियन पुर्तगाली | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| चीनी (पारंपरिक)| पीटर ची, और लेक्स चिएन, हेनरी हू, लियो वांग| -| चीनी (सरलीकृत)| बॉब पेंग, हेरोल्ड ज़ैंग, जैक एस| -| फ्रेंच | रोमुआल्ड स्ज़ुडलारेक, एबदर्रहमान आफ़ताही, क्रिश्चियन डोंग (समीक्षा)| -| जर्मन | रोक्को ग्रिट्ज़, स्वेन शेलियर (समीक्षा)| -| जापानी | कोकी तकेयमा, रियोतरो ऑकदा (समीक्षा)| -| कोरिअन| यौन्ग्जये जेओं, जेओंग्वों चो, जियौ हान, जियेऑन सुन्ग| -| रूसी | गल्ल मक्सिम, एउगेन मर्त्य्नोव, चलनोकोव व्लादिस्लाव, ओप्री ईगोर, टेरेशिन दिमित्री | -|स्पेनिश | मार्टिन मार्सिकनो, कार्लोस होलगुएरा| -| पुर्तगाली | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| फ़ारसी | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -|हिंदी | मुकेश शर्मा, कुंवर अतुल सिंह, रितेश कुमार, विक्रांत शाह, देवेंद्र कुमार सिन्हा, पराग दवे| -| तुर्की | Anıl Baş, Haktan Emik | -| यूनानी | Panagiotis Yialouris | - -
-यह दस्तावेज़ जिम मैनिको द्वारा लिखित OWASP एप्लीकेशन सिक्योरिटी वेरिफिकेशन स्टैंडर्ड के एक विशाख के रूप में शुरू हुआ। - -## प्रायोजक - -हालांकि MASVS और MASTG दोनों को स्वैच्छिक आधार पर समुदाय द्वारा बनाया और बनाए रखा जाता है, कभी-कभी थोड़ी बहुत बाहरी मदद की आवश्यकता होती है। इसलिए हम तकनीकी प्रायोजकों को नियुक्त करने में सक्षम होने के लिए धन प्रदान करने के लिए अपने प्रायोजकों को धन्यवाद देते हैं। ध्यान दें कि उनके प्रायोजन किसी भी तरह से MASVS या MASTG की सामग्री को प्रभावित नहीं करते हैं। प्रायोजन पैकेज पर वर्णित हैं [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP मोबाइल सुरक्षा परीक्षण गाइड प्रायोजन पैकेज")। - - - -हम हर उस शख्स का शुक्रिया अदा करना चाहेंगे जिसने लीनपब ([Leanpub](https://leanpub.com/mobile-security-testing-guide)) से किताब खरीदी और हमें उस तरह से प्रायोजित किया। diff --git a/Document-hi/0x03-Using_the_MASVS.md b/Document-hi/0x03-Using_the_MASVS.md deleted file mode 100644 index 810ade9b4..000000000 --- a/Document-hi/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,88 +0,0 @@ -# मोबाइल एप्लिकेशन सुरक्षा सत्यापन मापदंड - -MASVS का उपयोग मोबाइल एप्लिकेशन की सुरक्षा में विश्वास का स्तर स्थापित करने के लिए किया जा सकता है|और उसकी आवश्यकताओं को निम्नलिखित उद्देश्यों को ध्यान में रखते हुए विकसित किया गया है: - -- एक मापदंड के रूप में, जो मौजूदा मोबाइल एप्लिकेशन की तुलना डेवलपर्स और एप्लिकेशन मालिकों से कर सके; -- मार्गदर्शन के रूप में उपयोग करें - मोबाइल एप्लिकेशन बनाने और परीक्षण के सभी चरणों के दौरान मार्गदर्शन प्रदान करने के लिए; -- खरीदी के दौरान उपयोग करें - मोबाइल एप्लिकेशन सुरक्षा की जांच पड़ताल की आधार रेखा प्रदान करने के लिए। - -## मोबाइल एप्लिकेशन की सुरक्षा का मॉडल - -MASVS दो सुरक्षा सत्यापन स्तरों को (MASVS-L1 और MASVS-L2) परिभाषित करता है, साथ ही साथ रिवर्स इंजीनियरिंग की लचीलाता की आवश्यकताओं (MASVS-R) का एक सेट भी है। MASVS-L1 में सामान्य सुरक्षा आवश्यकताएं हैं जो सभी मोबाइल एप्लिकेशन के लिए एक अच्छा सुझाव हैं|जबकि MASVS-L2 को अत्यधिक संवेदनशील डेटा को संभालने वाले एप्लिकेशन पर लागू किया जाना चाहिए, MASVS-R में अतिरिक्त सुरक्षात्मक नियंत्रण शामिल हैं जो ग्राहक की ओर के ख़तरों को रोकना हमारा लक्ष्य होने पर लागू किए जा सकते हैं। - -MASVS-L1 की सभी आवश्यकताओं की पूर्ति करने से एक सुरक्षित एप्लिकेशन बना सकते है, जो सुरक्षा के उत्तम अभ्यास का पालन करता है और सामान्य कमजोरियों से ग्रस्त नहीं होता है| MASVS-L2 और भी गहन सुरक्षा के नियंत्रण जैसे कि SSL Pinning,अधिक जटिल हमलों के खिलाफ टिकने की क्षमता एप्लिकेशन को देता है - यह मानते हुए कि मोबाइल ऑपरेटिंग सिस्टम के सुरक्षा नियंत्रण बरकरार हैं और अंतिम उपयोगकर्ता को संभावित विरोधी के रूप में नहीं देखा जाता है| MASVS-R में सॉफ़्टवेयर सुरक्षा की सभी आवश्यकताओं विशिष्ट क्लाइंट-साइड खतरों को रोकने में मदद करता है, जहां अंतिम उपयोगकर्ता दुर्भावनापूर्ण और / या मोबाइल ऑपरेटिंग सिस्टम से समझौता किया जाता है। - -> १: यद्यपि हम हर एप्लिकेशन में MASVS-L1 नियंत्रणों को लागू करने की सलाह देते हैं, नियंत्रण लागू करना या नहीं अंततः एक जोखिम-आधारित निर्णय होना चाहिए, जो व्यवसाय के मालिकों के साथ लिया / संप्रेषित किया जाता है - -२: ध्यान दें कि सॉफ्टवेयर सुरक्षा नियंत्रण MASVS-R में सूचीबद्ध और OWASP मोबाइल सिक्योरिटी टेस्टिंग गाइड में वर्णित जिसे अंततः बाइपास किया जा सकता है इसे कभी भी सुरक्षा नियंत्रणों के प्रतिस्थापन के रूप में उपयोग नहीं किया जाना चाहिए। इसके बजाय, वे उन एप्लिकेशनों में अतिरिक्त खतरे तथा सुरक्षात्मक नियंत्रण जोड़ने का इरादा रखते हैं जो MASVS आवश्यकताओं को MASVS-L1 या MASVS-L2 में पूरा करते हैं। - -![Verification Levels](images/masvs-levels-new.jpg) - -### दस्तावेज़ संरचना - -MASVS के पहले भाग में सुरक्षा मॉडल पुष्टीकरण के उपलब्ध सत्यापन स्तरों का वर्णन है, इसके बाद अभ्यास में आदर्श तरीकों का उपयोग करने के बारे में सिफ़ारिशें दी गई हैं। सत्यापन स्तरों तक मैपिंग के साथ-साथ विस्तृत सुरक्षा आवश्यकताओं को दूसरे भाग में सूचीबद्ध किया गया है| आवश्यकताओं को तकनीकी उद्देश्य / दायरे के आधार पर आठ श्रेणियों (V1 से V8) में बाँटा गया है| निम्नलिखित तालिका का उपयोग MASVS और MASTG में किया जाता है: - -- *आवश्यकता श्रेणी:* MASVS-Vx, e.g. MASVS-V2: डेटा संग्रह और गोपनीयता -- *आवश्यकता :* MASVS-Vx.y, e.g. MASVS-V2.2: "एप्लिकेशन लॉग के लिए कोई संवेदनशील डेटा नहीं लिखा गया है।" - -### जाँच पड़ताल का स्तर विस्तार से - -#### MASVS-L1: आदर्श सुरक्षा - -एक मोबाइल एप्लिकेशन जो MASVS-L1 को हासिल करना है, व मोबाइल एप्लिकेशन सुरक्षा के सर्वोत्तम प्रथाओं का पालन करता है। यह कोड की गुणवत्ता, संवेदनशील डेटा को संभालने और मोबाइल वातावरण के साथ बातचीत के मामले में बुनियादी आवश्यकताओं को पूरा करता है। सुरक्षा नियंत्रणों को जाँचने के लिए एक परीक्षण प्रक्रिया होनी चाहिए। यह स्तर सभी मोबाइल एप्लिकेशन के लिए उचित है। - -#### MASVS-L2: गहन सुरक्षा - -MASVS-L2 में ऐसी उन्नत सुरक्षा नियंत्रणों का परिचय दिया गया है जो आदर्श आवश्यकताओं से कई आगे है| MASVS-L2 को पूरा करने के लिए, एक थ्रेट मॉडल मौजूद होना चाहिए, और सुरक्षा को एप्लिकेशन के आर्किटेक्चर और डिज़ाइन का एक अभिन्न अंग होना चाहिए। थ्रेट मॉडल के आधार पर, सही MASVS-L2 नियंत्रण का चयन किया जाना चाहिए और सफलतापूर्वक लागू किया जाना चाहिए। यह स्तर उन एप्लिकेशन के लिए उपयुक्त है जो अत्यधिक संवेदनशील डेटा को संभालते हैं, जैसे कि मोबाइल बैंकिंग एप्लिकेशन । - -#### MASVS-R: रिवर्स इंजीनियरिंग और छेड़छाड़ (Tampering) के खिलाफ सुलह - -एप्लिकेशन में अत्याधुनिक सुरक्षा है, तथा विशिष्ट रूप से क्लाइंट-साइड हमलों जैसे छेड़छाड़ करने(Tampering), रूपांतरित करना, या रिवर्स इंजीनियरिंग के खिलाफ भी सफल है। ऐसा एप्लिकेशन या तो हार्ड-वेयर सुरक्षा सुविधाओं का लाभ उठाता है और पर्याप्त रूप से मजबूत सॉफ्टवेयर सुरक्षा तकनीक साबित हो सकती है। MASVS-R उन एप्लिकेशन पर लागू होता है जो अत्यधिक संवेदनशील डेटा को संभालते हैं तथा बौद्धिक सम्पदा और छेड़छाड़ करने(Tampering) से बचाते है | - -### अनुशंसित उपयोग - -एप्लिकेशन को MASVS L1 or L2 के विरूद्ध पूर्व जोखिम मूल्यांकन तथा सुरक्षा के समग्र स्तर की आवश्यकता के आधार पर जांचा जा सकता है | L1 सभी मोबाइल एप्लिकेशन पर लागू होता है, जबकि L2 को आमतौर पर उन एप्लिकेशन के लिए सुझावित किया जाता है जो अधिक संवेदनशील डेटा और/या कार्यक्षमता को संभालते हैं। MASVS-R (या इसके कुछ हिस्सों) को विशिष्ट ख़तरों का सामना करने के लिए लागू किया जा सकता है, जैसे कि संवेदनशील डेटा का रीपैकेजिंग या निष्कर्षण से लेकर उचित सुरक्षा की जांच पड़ताल तक। - -सारांश में, निम्नलिखित जांच पड़ताल के प्रकार उपलब्ध हैं: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -अलग-अलग संयोजन सुरक्षा और कठिनाई का सामना करने की विभिन्न श्रेणी को दर्शाता हैं| हमारा लक्ष्य स्थिति के अनुसार आसानी से बदलाव है: उदाहरण के लिए एक मोबाइल गेम को MASVS-L2 सुरक्षा नियंत्रण जैसे की 2-कारक प्रमाणीकरण -( 2-Factor Authentication) की कोई खास जरुरत नही है किंतु हेर-फेर को रोकने के लिए मजबूत व्यावसायिक आवश्यकता है। - -#### किस प्रकार की जाँच पड़ताल को चुनना है - -MASVS L2 की आवश्यकताओं को लागू करने से सुरक्षा में तो वृद्धि होती है,लेकिन विकास का समय तथा अंतिम उपयोगकर्ता का अनुभव बिगड़ता है| सामान्य तौर पर, L2 का उपयोग जोखिम बनाम लागत के दृष्टिकोण से समझ में आए उस एप्लिकेशन में होना चाहिए | (यानी, जहां गोपनीयता या अखंडता के एक समझौते के कारण होने वाला संभावित नुकसान अतिरिक्त सुरक्षा नियंत्रणों द्वारा की गई लागत से अधिक है) MASVS को लागू करने से पहले जोखिम मूल्यांकन पहला कदम होना चाहिए। - -##### उदाहरण - -###### MASVS-L1 - -सभी मोबाइल एप्लिकेशन। MASVS-L1 सुरक्षा सर्वोत्तम प्रथाओं को सूचीबद्ध करता है जिनकी विकास लागत और उपयोगकर्ता के अनुभव पर उचित प्रभाव के साथ किया जा सकता है। किसी भी एप्लिकेशन के लिए MASVS-L1 में आवश्यकताओं को लागू करें जो उच्च स्तरों में से एक के लिए योग्य नहीं हैं। - - - -###### MASVS-L2 - -- स्वास्थ्य सेवा उद्योग: मोबाइल एप्लिकेशन जो व्यक्तिगत रूप से निजी जानकारी को संग्रहीत करते हैं, जिनका उपयोग निजी जानकारी की चोरी,धोखाधड़ी भुगतान या धोखाधड़ी योजनाओं की एक किस्म के लिए किया जा सकता है। यूएस(US) स्वास्थ्य सेवा क्षेत्र के लिए, अनु-पालन विचारों में स्वास्थ्य बीमा पोर्टेबिलिटी और जवाबदेही अधिनियम (HIPAA) गोपनीयता, सुरक्षा, उल्लंघन अधिसूचना नियम (Breach Notification Rules) और रोगी की सुरक्षा नियम शामिल हैं। - --वित्तीय उद्योग: ऐसे एप्लिकेशन जो क्रेडिट कार्ड नंबर, व्यक्तिगत जानकारी या उपयोगकर्ता को धन स्थानांतरित करने की अनुमति देने जैसी अत्यधिक संवेदनशील जानकारी तक पहुँच प्रदान करते हैं। ये ऐप धोखाधड़ी को रोकने के लिए अतिरिक्त सुरक्षा नियंत्रण प्रदान करते हैं। वित्तीय एप्लिकेशन को भुगतान कार्ड उद्योग डेटा सुरक्षा आदर्श (PCI DSS), ग्राम लीची ब्लाइली अधिनियम (Gramm Leech Bliley Act) और Sarbanes-Oxley Act (SOX) का अनु-पालन सुनिश्चित करने की आवश्यकता है। - -###### MASVS L1+R - -- मोबाइल ऐप जहां बौद्धिक संपदा (IP) संरक्षण एक व्यावसायिक लक्ष्य है। मूल स्रोत कोड को प्राप्त करने के लिए आवश्यक प्रयास को बढ़ाने के लिए और गैर कानूनी छेड़छाड़/ दरार को बाधित करने के लिए MASVS-R में सूचीबद्ध रिज़ॉल्यूशन नियंत्रण का उपयोग किया जा सकता है। - -- खेल उद्योग: प्रतिस्पर्धी ऑनलाइन गेम्स जैसे रूपांतरित करना और धोखे को रोकने की आवश्यकता वाले खेल। ऑनलाइन गेम में धोखा एक महत्वपूर्ण मुद्दा है, चूंकि बड़ी मात्रा में धोखेबाज़ होने से बाकि खिलाड़ी असंतुष्ट रहते है और अंततः ये गेम को विफल कर सकते हैं।। MASVS-R धोखेबाज़ों के लिए प्रयास बढ़ाने में मदद करने के लिए बुनियादी गैर कानूनी क्षति नियंत्रण प्रदान करता है। - -###### MASVS L2+R - -- वित्तीय उद्योग: ऑनलाइन बैंकिंग एप्लिकेशन जो उपयोगकर्ता को धन स्थानांतरित करने की अनुमति देते हैं,जहां समझौता किए गए उपकरणों पर कोड इंजेक्शन और इंस्ट्रूमेंटेशन जैसी तकनीकें जोखिम पैदा करती हैं। इस मामले में, MASVS-R से नियंत्रण का उपयोग गैर कानूनी क्षति को रोकने के लिए किया जा सकता है,मैलवेयर(malware) लेखकों के लिए प्रतिबंध बढ़ा सकता है। - --सभी मोबाइल एप्लिकेशन,जिन्हें डिज़ाइन करके,मोबाइल डिवाइस पर संवेदनशील डेटा संग्रहीत करने की आवश्यकता होती है,और उसके साथ ही डिवाइस और ऑपरेटिंग सिस्टम संस्करणों(versions) की एक विस्तृत श्रृंखला का समर्थन भी करना चाहिए तो इस मामले में,संवेदनशील नियंत्रणों को संवेदनशील डेटा को निकालने के लिए हमलावरों के लिए प्रयास को बढ़ाने के लिए बचाव-नियंत्रण में गहराई से उपाय के रूप में इस्तेमाल किया जा सकता है। - --इन-ऐप खरीदारी वाले एप्लिकेशन को भुगतान की गई सामग्री की सुरक्षा के लिए सर्वर-साइड और MASVS-L2 नियंत्रण का उपयोग करना चाहिए। हालांकि, ऐसे मामले हो सकते हैं जहां सर्वर-साइड सुरक्षा का उपयोग करने की कोई संभावना नहीं है। उन मामलों में, रिवर्सिंग और/या गैर कानूनी क्षति - -के प्रयास को बढ़ाने के लिए MASVS-R नियंत्रण को अतिरिक्त रूप से लागू किया जाना चाहिए। diff --git a/Document-hi/0x04-Assessment_and_Certification.md b/Document-hi/0x04-Assessment_and_Certification.md deleted file mode 100644 index ed4652173..000000000 --- a/Document-hi/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,50 +0,0 @@ -# मूल्यांकन और प्रमाणन - -## MASVS प्रमाणन और विश्वास अंक पर OWASP का रुख - -OWASP, निष्पक्ष-अलाभकारी संगठन के रूप में, किसी भी विक्रेता, सत्यापनकर्ता या सॉफ़्टवेयर को प्रमाणित नहीं करता है. - -ऐसे सभी आश्वासन दावे, विश्वास चिह्न, या प्रमाणपत्र आधिकारिक रूप से OWASP द्वारा प्रमाणित, पंजीकृत या प्रमाणित नहीं हैं, इसलिए इस तरह के दृष्टिकोण पर भरोसा करने वाले एक संगठन को किसी तीसरे पक्ष या ट्रस्ट मार्किंग ट्रस्ट (M) ASVS प्रमाणपत्र में रखे गए विश्वास से सावधान रहने की आवश्यकता है. - -यह संगठनों को ऐसी आश्वासन सेवाओं की पेशकश करने से रोकना नहीं चाहिए, जब तक कि वे आधिकारिक OWASP प्रमाणपत्र का दावा नहीं करते. - -## मोबाइल एप्लिकेशन को प्रमाणित करने के लिए मार्गदर्शन - -MASVS के साथ एक मोबाइल एप्लिकेशन के अनुपालन की पुष्टि करने का अनुशंसित तरीका "खुली किताब" समीक्षा करके है, -जिसका अर्थ है कि परीक्षकों को प्रमुख संसाधनों जैसे कि ऐप के आर्किटेक्ट्स और ऐप के डेवलपर्स जैसे प्रोजेक्ट, प्रोजेक्ट डॉक्यूमेंटेशन, सोर्स कोड और एंडपॉइंट्स के लिए ऑथेंटिकेटेड एक्सेस के लिए हर रोल के लिए कम से कम एक यूजर अकाउंट का एक्सेस दिया जाता है। - -यह ध्यान रखना महत्वपूर्ण है कि MASVS केवल (क्लाइंट-साइड) मोबाइल ऐप और इसके दूरस्थ समापन बिंदु (ओं) के बीच नेटवर्क संचार को कवर करता है, साथ ही उपयोगकर्ता प्रमाणीकरण और सत्र से संबंधित कुछ बुनियादी और सामान्य आवश्यकताओं को भी कवर करता है। इसमें ऐप से जुड़ी दूरस्थ सेवाओं (जैसे वेब सेवाओं) के लिए विशिष्ट आवश्यकताएं नहीं हैं, प्रमाणीकरण और सत्र प्रबंधन से संबंधित सामान्य आवश्यकताओं के सीमित सेट के लिए बचत करें। हालांकि, MASVS V1 निर्दिष्ट करता है कि दूरस्थ सेवाओं को समग्र थ्रेट मॉडल द्वारा कवर किया जाना चाहिए, और OWASP ASVS जैसे उपयुक्त मानकों के खिलाफ सत्यापित किया जाना चाहिए। - -एक प्रमाणित संगठन को किसी भी रिपोर्ट में सत्यापन के दायरे को शामिल करना चाहिए (विशेष रूप से यदि एक महत्वपूर्ण घटक गुंजाइश से बाहर है), सत्यापन निष्कर्षों का एक सारांश, जिसमें उत्तीर्ण और असफल परीक्षण शामिल हैं, असफल परीक्षणों को हल करने के स्पष्ट संकेत के साथ। विस्तृत कार्य पत्र, स्क्रीनशॉट या फिल्में, स्क्रिप्ट्स को मज़बूती से और बार-बार किसी मुद्दे का फायदा उठाने के लिए, और परीक्षण के इलेक्ट्रॉनिक रिकॉर्ड जैसे कि प्रॉक्सी लॉग्स और संबंधित नोट्स जैसे कि सफाई सूची, को मानक उद्योग अभ्यास माना जाता है। यह केवल एक उपकरण चलाने और विफलताओं पर रिपोर्ट करने के लिए पर्याप्त नहीं है; यह पर्याप्त प्रमाण नहीं देता है कि प्रमाणित स्तर पर सभी मुद्दों को अच्छी तरह से जांचा और परखा गया है। विवाद के मामले में, यह प्रदर्शित करने के लिए पर्याप्त सहायक सबूत होना चाहिए कि हर सत्यापित आवश्यकता का वास्तव में परीक्षण किया गया है। - - - -### OWASP मोबाइल सुरक्षा परीक्षण गाइड (MASTG) का उपयोग करना - -OWASP MASTG मोबाइल एप्लिकेशन की सुरक्षा के परीक्षण के लिए एक गाइड है। यह MASVS में सूचीबद्ध आवश्यकताओं की पुष्टि के लिए तकनीकी प्रक्रियाओं का वर्णन करता है। MASTG में परीक्षण मामलों की एक सूची शामिल होती है, जिनमें से प्रत्येक में MASVS की आवश्यकता होती है। जबकि MASVS आवश्यकताएं उच्च-स्तरीय और सामान्य हैं, MASTG प्रति मोबाइल-OS आधार पर गहराई से सिफारिशें और परीक्षण प्रक्रियाएं प्रदान करता है। - -### स्वचालित सुरक्षा परीक्षण उपकरण की भूमिका - -जब भी संभव हो, दक्षता बढ़ाने के लिए स्रोत कोड स्कैनर और ब्लैक-बॉक्स परीक्षण उपकरणों के उपयोग को प्रोत्साहित किया जाता है। हालांकि केवल स्वचालित उपकरणों का उपयोग करके MASVS सत्यापन को पूरा करना संभव नहीं है: हर मोबाइल ऐप अलग है, और समग्र वास्तुकला (Overall Architecture), व्यावसायिक तर्क, और उपयोग की जा रही विशिष्ट प्रौद्योगिकियों और रूपरेखाओं के तकनीकी नुकसान को समझना, सुरक्षा को सत्यापित करने के लिए एप्लिकेशन में एक अनिवार्य आवश्यकता है। - -## अन्य उपयोग - -### विस्तृत सुरक्षा वास्तुकला मार्गदर्शन के रूप में - -मोबाइल एप्लिकेशन सुरक्षा सत्यापन मानक के लिए अधिक सामान्य उपयोगों में से एक सुरक्षा आर्किटेक्ट के लिए एक संसाधन के रूप में है। दो प्रमुख सुरक्षा वास्तुकला ढांचे, SABSA या TOGAF, मोबाइल एप्लिकेशन आर्किटेक्चर की समीक्षा को पूरा करने के लिए आवश्यक जानकारी का एक बहुत कुछ हिस्सा अनुपस्थित हैं। MASVS का उपयोग उन गैप्स को भरने के लिए किया जा सकता है, जो सुरक्षा वास्तुकारों को मोबाइल ऐप्स के मुद्दों के लिए बेहतर नियंत्रण चुनने की अनुमति देते हैं। - -### ऑफ-द-शेल्फ सुरक्षित कोडिंग चेकलिस्ट के प्रतिस्थापन के रूप में - -कई संगठन MASVS को अपनाने से लाभान्वित हो सकते हैं, दो स्तरों में से एक को चुनकर, या MASVS को जोड़ (Fork) करके और डोमेन-विशिष्ट तरीके से प्रत्येक एप्लिकेशन के जोखिम स्तर के लिए जो आवश्यक है उसे बदल सकते हैं। जब तक ट्रैसेबिलिटी बनी रहती है, तब तक हम इस प्रकार के जोड़ को प्रोत्साहित करते हैं, इसलिए कि यदि किसी ऐप ने 4.1 की आवश्यकता को पार कर लिया है, तो इसका मतलब मानक विकसित होने वाली फोर्क्ड प्रतियों के लिए समान है - -### सुरक्षा परीक्षण के तरीकों के लिए एक आधार के रूप में - -एक अच्छा मोबाइल ऐप सुरक्षा परीक्षण पद्धति को MASVS में सूचीबद्ध सभी आवश्यकताओं को कवर करना चाहिए। OWASP मोबाइल सुरक्षा परीक्षण गाइड (MASTG) प्रत्येक सत्यापन आवश्यकता के लिए ब्लैक-बॉक्स और व्हाइट-बॉक्स परीक्षण मामलों का वर्णन करता है। - -### स्वचालित इकाई और एकीकरण टेस्ट के लिए एक मार्गदर्शक के रूप में - -MASVS को वास्तुशिल्प आवश्यकताओं के एकमात्र अपवाद के साथ, अत्यधिक परीक्षण योग्य बनाया गया है। MASVS आवश्यकताओं के आधार पर स्वचालित इकाई, एकीकरण और स्वीकृति परीक्षण निरंतर विकास जीवनचक्र में एकीकृत किया जा सकता है। यह न केवल डेवलपर सुरक्षा जागरूकता बढ़ाता है, बल्कि परिणामी ऐप्स की समग्र गुणवत्ता में सुधार करता है, और पूर्व-रिलीज़ चरण में सुरक्षा परीक्षण के दौरान निष्कर्षों की मात्रा को कम करता है। - -### सुरक्षित विकास प्रशिक्षण के लिए - -MASVS का उपयोग सुरक्षित मोबाइल एप्लिकेशन की विशेषताओं को परिभाषित करने के लिए भी किया जा सकता है। कई "सुरक्षित कोडिंग" पाठ्यक्रम केवल कोडिंग युक्तियों के हल्के धब्बा के साथ नैतिक हैकिंग पाठ्यक्रम हैं। यह डेवलपर्स की मदद नहीं करता है। इसके बजाय, सुरक्षित विकास पाठ्यक्रम MASVS का उपयोग कर सकते हैं, जैसे कि MASVS में प्रलेखित सक्रिय नियंत्रणों पर एक मजबूत फोकस के साथ, उदाहरण के लिए - शीर्ष 10 कोड सुरक्षा मुद्दे। diff --git a/Document-hi/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-hi/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index a1acafd42..000000000 --- a/Document-hi/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,36 +0,0 @@ -# V1: आर्किटेक्चर, डिजाइन और थ्रेट मॉडलिंग आवश्यकताएं - -## उद्देश्य नियंत्रण - - एक संपूर्ण दुनिया में, विकास के सभी चरणों में सुरक्षा पर विचार किया जाएगा। हालांकि वास्तविकता में, सुरक्षा अक्सर एसडीएलसी (SDLC) में एक देर के चरण में एक विचार है। तकनीकी नियंत्रणों के अलावा, MASVS को ऐसी प्रक्रियाओं की आवश्यकता होती है जो यह सुनिश्चित करती हैं कि मोबाइल ऐप की वास्तुकला (architecture) की योजना बनाते समय सुरक्षा स्पष्ट रूप से संबोधित की गई है, और यह कि सभी घटकों (components) की कार्यात्मक और सुरक्षा भूमिकाएं ज्ञात हैं। चूंकि अधिकांश मोबाइल एप्लिकेशन दूरस्थ सेवाओं के लिए ग्राहकों के रूप में कार्य करते हैं, इसलिए यह सुनिश्चित किया जाना चाहिए कि उन सेवाओं के लिए उपयुक्त सुरक्षा मानक भी लागू हों - अलग से मोबाइल ऐप का परीक्षण करना पर्याप्त नहीं है। - -"V1" श्रेणी, आर्किटेक्चर और ऐप के डिजाइन से संबंधित आवश्यकताओं को सूचीबद्ध करती है। इस प्रकार, यह एकमात्र श्रेणी है जो ओडब्ल्यूएएसपी(OWASP) मोबाइल टेस्टिंग गाइड में तकनीकी परीक्षण मामलों के लिए मैप नहीं करता है। थ्रेट मॉडलिंग, सुरक्षित एसडीएलसी( Secure SDLC) या मुख्य प्रबंधन (Key Management) जैसे विषयों को कवर करने के लिए, MASVS के उपयोगकर्ताओं को संबंधित OWASP योजना और / या अन्य मानकों से परामर्श करना चाहिए जैसे नीचे दिए गए लिंक। - -## सुरक्षा सत्यापन आवश्यकताएँ - -MASVS-L1 और MASVS-L2 की आवश्यकताएं नीचे सूचीबद्ध हैं। - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | सभी एप्लिकेशन घटकों की पहचान की जाती है और आवश्यक होने के लिये जाना जाता है। | x | x | -| **1.2** | MSTG-ARCH-2 | सुरक्षा नियंत्रण केवल ग्राहक पक्ष पर ही नहीं बल्कि संबंधित दूरस्थ समापन बिंदुओं पर भी लागू किए जाते हैं। | x | x | -| **1.3** | MSTG-ARCH-3 | मोबाइल एप्लिकेशन और सभी कनेक्टेड दूरस्थ सेवाओं के लिए एक उच्च-स्तरीय वास्तुकला (architecture) को परिभाषित किया गया है और उस वास्तुकला में सुरक्षा को संबोधित किया गया है। | x | x | -| **1.4** | MSTG-ARCH-4 | मोबाइल ऐप के संदर्भ में संवेदनशील माना जाने वाला डेटा स्पष्ट रूप से पहचाना जाता है। | x | x | -| **1.5** | MSTG-ARCH-5 | सभी ऐप घटकों (components) को उनके द्वारा प्रदान किये जाने वाले व्यावसायिक कार्यों और / या सुरक्षा कार्यों के संदर्भ में परिभाषित किया गया है। | | x | -| **1.6** | MSTG-ARCH-6 | मोबाइल ऐप और संबंधित दूरस्थ सेवाओं के लिए एक थ्रेट मॉडल को प्रस्तुत किया गया है, जो संभावित खतरों और प्रतिकारों (countermeasure) की पहचान करता है। | | x | -| **1.7** | MSTG-ARCH-7 | सभी सुरक्षा नियंत्रणों का केंद्रीयकृत कार्यान्वयन है।| | x | -| **1.8** | MSTG-ARCH-8 | क्रिप्टोग्राफ़िक कुंजियाँ (यदि कोई हो) प्रबंधित की जाती हैं, और क्रिप्टोग्राफ़िक कुंजियों का जीवनचक्र कैसे लागू किया जाता है, इसके लिए एक स्पष्ट नीति है। आदर्श रूप से, NIST SP 800-57 जैसे प्रमुख प्रबंधन मानक का पालन करें। | | x | -| **1.9** | MSTG-ARCH-9 | मोबाइल ऐप के अपडेट को लागू करने के लिए एक तंत्र मौजूद है। | | x | -| **1.10** | MSTG-ARCH-10 | सॉफ्टवेयर विकास जीवनचक्र के सभी भागों के भीतर सुरक्षा को संबोधित किया जाता है। | | x | -| **1.11** | MSTG-ARCH-11 | एक जिम्मेदार प्रकटीकरण नीति लागू होती है और प्रभावी रूप से लागू होती है। | | x | -| **1.12** | MSTG-ARCH-12 | एप्लिकेशन को गोपनीयता कानूनों और नियमों का पालन करना चाहिए। | x | x | - -## संदर्भ - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP मोबाइल टॉप 10: M10 (एक्सट्रोनस फंक्शनलिटी) - -- OWASP थ्रेट मॉडलिंग - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-hi/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-hi/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 8afff905d..000000000 --- a/Document-hi/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: डेटा संग्रहण और गोपनीयता आवश्यकताएँ - -## नियंत्रण का उद्देश्य - -संवेदनशील डेटा की सुरक्षा, जैसे कि उपयोगकर्ता के क्रिडेंशियल्स और निजी जानकारी, मोबाइल सुरक्षा में एक महत्वपूर्ण फोकस है। सबसे पहले, संवेदनशील डेटा अनजाने में एक ही डिवाइस पर चल रहे अन्य ऐप के संपर्क में आ सकते हैं यदि IPC जैसे ऑपरेटिंग सिस्टम तंत्र का अनुचित उपयोग किया जाता है। डेटा भी अनजाने में क्लाउड स्टोरेज, बैकअप या कीबोर्ड कैशे में लीक हो सकता है। इसके अतिरिक्त, मोबाइल उपकरणों को अन्य प्रकार के उपकरणों की तुलना में अधिक आसानी से खोया या चुराया जा सकता है, इसलिए भौतिक पहुंच प्राप्त करने वाले एक विरोधी/अनचाहे हैकर की अधिक संभावना होती है। उस स्थिति में अतिरिक्त सुरक्षा को लागू किया जा सकता है ताकि संवेदनशील डेटा तक पहुंच और अधिक कठिन बन जाए। - -ध्यान दें, जैसे कि MASVS ऐप-केंद्रित है, इसके अंतर्गत MDM समाधानों द्वारा लागू की गई डिवाइस-स्तरीय नीतियों नहीं आती हैं। हम डेटा सुरक्षा को और बढ़ाने के लिए एंटरप्राइज़ संदर्भ में ऐसी नीतियों के उपयोग को प्रोत्साहित करते हैं। - -### संवेदनशील डेटा की परिभाषा - -MASVS के संदर्भ में संवेदनशील डेटा दोनों उपयोगकर्ता क्रिडेंशियल्स और किसी भी अन्य डेटा को विशेष संदर्भ में संवेदनशील माना जाता है, जैसे: - -- व्यक्तिगत रूप से पहचान योग्य जानकारी (पीआईआई) जिसका दुरुपयोग पहचान की चोरी (आइडेंटिटी थेफ़्ट) के लिए किया जा सकता है जैसे कि; सामाजिक सुरक्षा नंबर, क्रेडिट कार्ड नंबर, बैंक खाता संख्या, स्वास्थ्य जानकारी आदि। -- अत्यधिक संवेदनशील डेटा जिसको यदि हैक कर लिया जाये तो, व्यक्ति विशेष की प्रतिष्ठा को या वित्त को नुक्सान हो सकता है जैसे कि; संविदात्मक जानकारी, गैर-प्रकटीकरण समझौतों द्वारा कवर की गई जानकारी, प्रबंधन जानकारी आदि। -- कोई भी डेटा जिसे कानून द्वारा या अनुपालन कारणों से संरक्षित किया जाना चाहिए। - -## सुरक्षा सत्यापन आवश्यकताएँ - -डेटा प्रकटीकरण के मुद्दों के विशाल बहुमत को सरल नियमों का पालन करके रोका जा सकता है। इस अध्याय में सूचीबद्ध अधिकांश नियंत्रण सभी सत्यापन स्तरों के लिए अनिवार्य हैं। - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | सिस्टम क्रिडेंशियल्स स्टोरेज सुविधाओं का उपयोग संवेदनशील डेटा, जैसे PII, उपयोगकर्ता क्रिडेंशियल्स या क्रिप्टोग्राफ़िक कुंजियों को संग्रहीत करने के लिए किया जाना चाहिए। | x | x | -| **2.2** | MSTG-STORAGE-2 | कोई संवेदनशील डेटा ऐप कंटेनर या सिस्टम क्रिडेंशियल्स स्टोरेज सुविधाओं के सिवाय कहीं और संग्रहित नहीं किया जाना चाहिए। | x | x | -| **2.3** | MSTG-STORAGE-3 | एप्लिकेशन लॉग के लिए कोई संवेदनशील डेटा नहीं लिखा गया है। | x | x | -| **2.4** | MSTG-STORAGE-4 | किसी भी संवेदनशील डेटा को तीसरे पक्ष के साथ साझा नहीं किया जाना चाहिए जब तक कि वह आर्किटेक्चर का एक आवश्यक हिस्सा ना हो। | x | x | -| **2.5** | MSTG-STORAGE-5 | कीबोर्ड कैशे संवेदनशील डेटा को प्रोसेस करने वाले टेक्स्ट इनपुट पर अक्षम होता है। | x | x | -| **2.6** | MSTG-STORAGE-6 | IPC तंत्र के माध्यम से कोई संवेदनशील डेटा सामने नहीं आया है। | x | x | -| **2.7** | MSTG-STORAGE-7 | पासवर्ड या पिन जैसे कोई संवेदनशील डेटा उपयोगकर्ता इंटरफ़ेस के माध्यम से उजागर नहीं होता है। | x | x | -| **2.8** | MSTG-STORAGE-8 | मोबाइल ऑपरेटिंग सिस्टम द्वारा उत्पन्न बैकअप में कोई संवेदनशील डेटा शामिल नहीं है। | | x | -| **2.9** | MSTG-STORAGE-9 | ऐप पृष्ठभूमि पर चले जाने पर संवेदनशील डेटा को व्यू (View) से हटा देता है। | | x | -| **2.10** | MSTG-STORAGE-10 | ऐप एप्लिकेशन मेमोरी में संवेदनशील डेटा को आवश्यकता से अधिक समय तक नहीं रखता है, और उपयोग के बाद मेमोरी को स्पष्ट रूप से साफ़ किया जाता है। | | x | -| **2.11** | MSTG-STORAGE-11 | ऐप एक न्यूनतम डिवाइस-एक्सेस-सुरक्षा नीति लागू करता है, जैसे कि उपयोगकर्ता को डिवाइस पासकोड सेट करने की आवश्यकता होती है। | | x | -| **2.12** | MSTG-STORAGE-12 | एप्लिकेशन उपयोगकर्ता को व्यक्तिगत रूप से पहचाने जाने योग्य जानकारी के प्रकारों के बारे में शिक्षित करता है, साथ ही सुरक्षा सर्वोत्तम प्रथाओं को उपयोगकर्ता को ऐप का उपयोग करना चाहिए। | x | x | -| **2.13** | MSTG-STORAGE-13 | मोबाइल डिवाइस पर कोई संवेदनशील डेटा स्थानीय रूप से संग्रहीत नहीं किया जाना चाहिए। इसके बजाय, डेटा को जरूरत पड़ने पर एक दूरस्थ समापन बिंदु से पुनर्प्राप्त किया जाना चाहिए और केवल स्मृति में रखा जाना चाहिए। | | x | -| **2.14** | MSTG-STORAGE-14 | यदि संवेदनशील डेटा को अभी भी स्थानीय रूप से संग्रहित करने की आवश्यकता है, तो इसे हार्डवेयर समर्थित भंडारण से प्राप्त एक की (Key) का उपयोग करके एन्क्रिप्ट किया जाना चाहिए जिसे प्रमाणीकरण की आवश्यकता होती है। | | x | -| **2.15** | MSTG-STORAGE-15 | अत्यधिक प्रमाणीकरण विफल प्रयासों के बाद ऐप के स्थानीय भंडारण को मिटा दिया जाना चाहिए। | | x | - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड इस खंड में सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करती है। - -- Android: परीक्षण डेटा संग्रहण - -- iOS: परीक्षण डेटा संग्रहण - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP Mobile Top 10: M1 (अनुचित प्लेटफ़ॉर्म उपयोग) - -- OWASP Mobile Top 10: M2 (असुरक्षित डेटा संग्रहण) - -- CWE 117 (लॉग्स के लिए अनुचित आउटपुट तटस्थता) - -- CWE 200 (सूचना एक्सपोजर) - -- CWE 276 (गलत डिफ़ॉल्ट अनुमतियाँ) - -- CWE 311 (संवेदनशील डेटा की अनुपलब्ध एन्क्रिप्शन) - -- CWE 312 (संवेदनशील सूचना का क्लियरटेक्स्ट स्टोरेज) - -- CWE 316 (मेमोरी में सेंसिटिव इंफॉर्मेशन का क्लियरटेक्स्ट स्टोरेज) - -- CWE 359 (निजी जानकारी का एक्सपोजर ('गोपनीयता उल्लंघन')) - -- CWE 522 (अपर्याप्त रूप से संरक्षित क्रिडेंशियल्स) - -- CWE 524 (कैशिंग के माध्यम से सूचना एक्सपोजर) - -- CWE 530 (अनधिकृत नियंत्रण क्षेत्र के लिए बैकअप फ़ाइल का एक्सपोजर) - -- CWE 532 (लॉग फ़ाइलों के माध्यम से सूचना एक्सपोजर) - -- CWE 534 (डीबग लॉग फ़ाइलों के माध्यम से सूचना एक्सपोजर) - -- CWE 634 (कमजोरियाँ जो सिस्टम प्रक्रियाओं को प्रभावित करती हैं) - -- CWE 798 (हार्ड-कोडेड क्रिडेंशियल्स का उपयोग) - -- CWE 921 (एक्सेस कंट्रोल के बिना एक तंत्र में संवेदनशील डेटा का भंडारण) - -- CWE 922 (संवेदनशील जानकारी का असुरक्षित भंडारण) - diff --git a/Document-hi/0x08-V3-Cryptography_Verification_Requirements.md b/Document-hi/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 6751f9621..000000000 --- a/Document-hi/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,40 +0,0 @@ -# V3: क्रिप्टोग्राफी आवश्यकताएँ - -## नियंत्रण उद्देश्य - -क्रिप्टोग्राफी एक आवश्यक घटक है जब यह मोबाइल डिवाइस पर संग्रहीत डेटा की सुरक्षा के लिए आता है। यह एक ऐसी श्रेणी भी है जहां चीजें बुरी तरह से गलत हो सकती हैं, खासकर जब मानक सम्मेलनों का पालन नहीं किया जाता है। इस अध्याय में नियंत्रण का उद्देश्य यह सुनिश्चित करना है कि सत्यापित आवेदन उद्योग की सर्वोत्तम प्रथाओं के अनुसार क्रिप्टोग्राफी का उपयोग करता है, जिसमें शामिल हैं: - -- सिद्ध क्रिप्टोग्राफिक लाइब्रिरीज़ (libraries) का उपयोग; -- क्रिप्टोग्राफिक प्राइमेटिक्स की उचित पसंद और विन्यास; -- एक उपयुक्त रेन्डम संख्या जनरेटर जहाँ भी रेन्डम्नस की आवश्यकता है। - -## सुरक्षा सत्यापन आवश्यकताएँ - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | एप्लिकेशन एन्क्रिप्शन हार्ड कोडेड कीज़ (keys) के साथ सममित क्रिप्टोग्राफी (symmetric cryptography) की एकमात्र विधि के रूप में निर्भर नहीं करता है।| x | x | -| **3.2** | MSTG-CRYPTO-2 | एप्लिकेशन क्रिप्टोग्राफिक प्राइमेटिव के सिद्ध कार्यान्वयन का उपयोग करता है। | x | x | -| **3.3** | MSTG-CRYPTO-3 | एप्लिकेशन क्रिप्टोग्राफ़िक प्राइमेटिव का उपयोग करता है जो विशेष उपयोग के मामले के लिए उपयुक्त हैं, उन मापदंडों के साथ कॉन्फ़िगर किया गया है जो उद्योग की सर्वोत्तम प्रथाओं का पालन करते हैं। | x | x | -| **3.4** | MSTG-CRYPTO-4 | ऐप क्रिप्टोग्राफ़िक प्रोटोकॉल या एल्गोरिदम का उपयोग नहीं करता है जो सुरक्षा उद्देश्यों का विरोध करते है। - | x | x | -| **3.5** | MSTG-CRYPTO-5 | एप्लिकेशन कई उद्देश्यों के लिए एक ही क्रिप्टोग्राफिक कुंजी का फिर से उपयोग नहीं करता है। | x | x | -| **3.6** | MSTG-CRYPTO-6 | सभी रेन्डम वेल्यू एक पर्याप्त रूप से सुरक्षित रेन्डम संख्या जनरेटर का उपयोग करके उत्पन्न होते हैं। | x | x | - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड इस खंड में सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है। - -- Android: परीक्षण क्रिप्टोग्राफ़ी - -- iOS: परीक्षण क्रिप्टोग्राफी - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP मोबाइल टॉप 10: M5 (अपर्याप्त क्रिप्टोग्राफी) - -- CWE 310 (क्रिप्टोग्राफिक इश्यू) - -- CWE 321 (हार्ड-कोडेड क्रिप्टोग्राफ़िक कुंजी का उपयोग) - -- CWE 326 (अपर्याप्त एन्क्रिप्शन स्ट्रेंथ) - -- CWE 327 (ब्रॉकन् या रिस्की भरा क्रिप्टोग्राफिक एल्गोरिदम का उपयोग) - -- CWE 329 (CBC मोड के साथ रैंडम IV का उपयोग नहीं) - -- CWE 330 (अपर्याप्त रैंडम वैल्यू का उपयोग) - -- CWE 337 (PRNG में अनुमानित सीड) - -- CWE 338 (क्रिप्टोग्राफिकली कमजोर सूडो रेन्डम संख्या जनरेटर (PRNG) का उपयोग) - diff --git a/Document-hi/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-hi/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index e025ab7ac..000000000 --- a/Document-hi/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: प्रमाणीकरण और सत्र प्रबंधन आवश्यकताएँ - -## उद्देश्य नियंत्रण - -ज्यादातर मामलों में, दूरस्थ सेवा में प्रवेश करने वाले उपयोगकर्ता समग्र मोबाइल एप्लिकेशन आर्किटेक्चर का एक अभिन्न अंग हैं। हालांकि अधिकांश तर्क समापन बिंदु पर होते हैं,MASVS उपयोगकर्ता खातों और सत्रों को प्रबंधित करने के तरीके के बारे में कुछ बुनियादी आवश्यकताओं को परिभाषित करता है। - -## सुरक्षा सत्यापन आवश्यकताएँ - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | यदि एप्लिकेशन उपयोगकर्ताओं को दूरस्थ सेवा तक पहुँच प्रदान करता है, तो प्रमाणीकरण का कुछ रूप, जैसे कि उपयोगकर्ता नाम / पासवर्ड प्रमाणीकरण, दूरस्थ समापन बिंदु पर किया जाता है। | x | x | -| **4.2** | MSTG-AUTH-2 | यदि स्टेटफुल सत्र प्रबंधन का उपयोग किया जाता है, तो दूरस्थ समापन बिंदु उपयोगकर्ता के क्रेडेंशियल्स को भेजे बिना क्लाइंट अनुरोधों को प्रमाणिक करने के लिए बेतरतीब ढंग से उत्पन्न सत्र पहचानकर्ताओं का उपयोग करता है।| x | x | -| **4.3** | MSTG-AUTH-3 | यदि स्टेटलेस टोकन-आधारित प्रमाणीकरण का उपयोग किया जाता है, तो सर्वर एक टोकन प्रदान करता है जिसे एक सुरक्षित एल्गोरिथ्म का उपयोग करके हस्ताक्षरित किया गया है। | x | x | -| **4.4** | MSTG-AUTH-4 | जब उपयोगकर्ता लॉग आउट करता है, तो दूरस्थ समापन बिंदु मौजूदा सत्र को समाप्त कर देता है। | x | x | -| **4.5** | MSTG-AUTH-5 | एक पासवर्ड नीति मौजूद है और इसे दूरस्थ समापन बिंदु पर लागू किया गया है। | x | x | -| **4.6** | MSTG-AUTH-6 | रिमोट एंडपॉइंट कई बार अत्यधिक संख्या में क्रेडेंशियल्स जमा करने से बचाने के लिए एक तंत्र को लागू करता है। | x | x | -| **4.7** | MSTG-AUTH-7 | निष्क्रियता और पहुंच टोकन की समय सीमा समाप्त होने के बाद सत्र दूरस्थ समापन बिंदु पर अमान्य हैं। | x | x | -| **4.8** | MSTG-AUTH-8 | बायोमेट्रिक प्रमाणीकरण, यदि कोई हो, तो ईवेंट-बाउंड नहीं है (यानी एक API का उपयोग करके जो "सही" या "गलत" लौटाना है)। इसके बजाय, यह किचेन / की-स्टोर को अनलॉक करने पर आधारित है। | | x | -| **4.9** | MSTG-AUTH-9 | प्रमाणीकरण का दूसरा कारक दूरस्थ समापन बिंदु पर मौजूद है और 2FA आवश्यकता लगातार लागू होती है। | | x | -| **4.10** | MSTG-AUTH-10 | संवेदनशील लेनदेन के लिए स्टेप-अप प्रमाणीकरण की आवश्यकता होती है। | | x | -| **4.11** | MSTG-AUTH-11 | ऐप अपने खाते के साथ सभी संवेदनशील गतिविधियों के उपयोगकर्ता को सूचित करता है। उपयोगकर्ता उपकरणों की एक सूची देखने में सक्षम हैं, प्रासंगिक जानकारी (IP पते, स्थान आदि) को देखने के लिए, और विशिष्ट उपकरणों को अवरुद्ध करने में सक्षम हैं। | | x | -| **4.12** | MSTG-AUTH-12 | प्राधिकरण मॉडल को दूरस्थ समापन बिंदु पर परिभाषित और लागू किया जाना चाहिए। | x | x | - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड ऊपर सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है। - -- सामान्य: प्रमाणीकरण और सत्र प्रबंधन - -- Android: स्थानीय प्रमाणीकरण का परीक्षण - -- iOS: स्थानीय प्रमाणीकरण का परीक्षण - - -For more information, see also: - -- OWASP मोबाइल टॉप 10: M4 (असुरक्षित प्रमाणीकरण) - -- OWASP मोबाइल टॉप 10: M6 (असुरक्षित प्राधिकरण) - -- CWE 287 (अनुचित प्रमाणीकरण) - -- CWE 307 (अत्यधिक प्रमाणीकरण प्रयासों का अनुचित प्रतिबंध) - -- CWE 308 (एकल-कारक प्रमाणीकरण का उपयोग) - -- CWE 521 (एकल-कारक प्रमाणीकरण का उपयोग) - -- CWE 604 (क्लाइंट-साइड प्रमाणीकरण का उपयोग) - -- CWE 613 (अपर्याप्त सत्र समाप्ति) - diff --git a/Document-hi/0x10-V5-Network_communication_requirements.md b/Document-hi/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index db96f7b4a..000000000 --- a/Document-hi/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: नेटवर्क संचार आवश्यकताएँ - -## नियंत्रण उद्देश्य - -इस खंड में सूचीबद्ध नियंत्रण का उद्देश्य मोबाइल ऐप और दूरस्थ सेवा के समापन बिंदुओं के बीच सूचना की गोपनीयता और अखंडता को सुनिश्चित करना है। बहुत कम से कम, एक मोबाइल ऐप को उचित सेटिंग्स के साथ टीएलएस (TLS) प्रोटोकॉल का उपयोग करके नेटवर्क संचार के लिए एक सुरक्षित, एन्क्रिप्टेड (Encrypted) चैनल स्थापित करना होगा। लेवल 2 अतिरिक्त रक्षा-में-गहराई माप (defense-in-depth) को सूचीबद्ध करता है जैसे एसएसएल (SSL) पिनिंग। - -## सुरक्षा सत्यापन आवश्यकताएँ - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-नेटवर्क -1 | टीएलएस का उपयोग कर नेटवर्क पर डेटा एन्क्रिप्ट किया गया है। सुरक्षित चैनल का उपयोग पूरे ऐप में लगातार किया जाता है। | x | x | -| **5.2** | MSTG-नेटवर्क -2 | टीएलएस सेटिंग्स वर्तमान सर्वोत्तम प्रथाओं के अनुरूप हैं, या यदि संभव हो तो मोबाइल ऑपरेटिंग सिस्टम अनुशंसित मानकों का समर्थन नहीं करता है। | x | x | -| **5.3** | MSTG-नेटवर्क -3 | सुरक्षित चैनल स्थापित होने पर ऐप दूरस्थ समापन बिंदु के X.509 प्रमाणपत्र की पुष्टि करता है। केवल विश्वसनीय CA (Certificate Authority) द्वारा हस्ताक्षरित प्रमाणपत्र ही स्वीकार किए जाते हैं। | x | x | -| **5.4** | MSTG-नेटवर्क -4 | ऐप या तो अपने सर्टिफिकेट स्टोर का उपयोग करता है, या अंतिम बिंदु प्रमाण पत्र या सार्वजनिक कुंजी को पिन करता है, और बाद में उन समापन बिंदुओं के साथ कनेक्शन स्थापित नहीं करता है जो एक विश्वसनीय CA(Certificate Authority) द्वारा हस्ताक्षरित होने पर भी एक अलग प्रमाण पत्र या कुंजी प्रदान करते हैं। | | x | -| **5.5** | MSTG-नेटवर्क -5 | एप्लिकेशन महत्वपूर्ण परिचालन जैसे कि नामांकन और खाता पुनर्प्राप्ति के लिए एक असुरक्षित संचार चैनल (ईमेल या एसएमएस) पर भरोसा नहीं करता है। | | x | -| **5.6** | MSTG-नेटवर्क -6 | एप्लिकेशन केवल अप-टू-डेट कनेक्टिविटी और सुरक्षा लाइब्रेरी पर निर्भर करता है। | | x | - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड इस खंड में सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है। - -- जनरल: परीक्षण नेटवर्क संचार - -- एंड्रॉयड: परीक्षण नेटवर्क संचार - -- आईओएस: परीक्षण नेटवर्क संचार - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP मोबाइल शीर्ष 10: M3 (असुरक्षित संचार) - -- CWE 295 (अनुचित प्रमाणपत्र सत्यापन) - -- CWE 296 (ट्रस्ट के प्रमाण पत्र के बाद का पालन) - -- CWE 297 (होस्ट मिसमैच के साथ प्रमाण पत्र का अनुचित सत्यापन) - -- CWE 298 (प्रमाणपत्र समाप्ति की अनुचित मान्यता) - -- CWE 308 (सिंगल-कारक प्रमाणीकरण का प्रयोग करें) - -- CWE 319 (संवेदनशील सूचना का स्पष्ट प्रसारण) - -- CWE 326 (अपर्याप्त एन्क्रिप्शन शक्ति) - -- CWE 327 (एक टूटे या जोखिम भरे क्रिप्टोग्राफ़िक एल्गोरिथम का उपयोग) - -- CWE 780 (OAEP के बिना RSA एल्गोरिथम का उपयोग) - -- CWE 940 (एक संचार चैनल के स्रोत का अनुचित सत्यापन) - -- CWE 941 (एक संचार चैनल में गलत तरीके से निर्दिष्ट गंतव्य) - diff --git a/Document-hi/0x11-V6-Interaction_with_the_environment.md b/Document-hi/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 8fde8bc7d..000000000 --- a/Document-hi/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# प्लेटफ़ॉर्म इंटरएक्शन आवश्यकताएँ - -## उद्देश्य नियंत्रण - -इस समूह में नियंत्रण सुरक्षित करता है तथा ऐप सुरक्षित तरीके से प्लेटफार्म एपीआई और स्टैंडर्ड कॅम्पोनॅन्ट का उपयोग करता है। इसके अतिरिक्त नियंत्रण ऍप्लिकेशन्स (आईपीसी) के बीच कम्युनिकेशन को कवर करता है। - -## सुरक्षा सत्यापन की आवश्यकता। - -| # | MSTG-ID | विवरण | एल 1| एल 2 | -| -- | ---------- | ---------------------- | - | - | -| *6.1* | MSTG-PLATFORM-1 | यह ऐप केवल आवश्यक अनुमतियों के न्यूनतम सेट का अनुरोध करता है. | x | x | -| *6.2* | MSTG-PLATFORM-2 | एक्सटर्नल सोर्स और यूज़र के सभी इनपुट मान्य किए गए हैं और आवश्यकता अनुसार सेन्सिटाइज़ भी । इसमें यूआई, आईपीसी जैसे कि इन्टेन्ट डेटा, कस्टम यूआरएल और नेटवर्क सोर्स के माध्यम से प्राप्त डाटा शामिल है. | x | x | -| *6.3* | MSTG-PLATFORM-3 | यह ऐप कस्टम यूआरएल स्कीम्स के माध्यम से सेन्सिटिव फंगक्शनैलिटी को इक्स्पोर्ट नहीं करता है जब तक कि यह मेकनिज़म्ज़ ठीक से सुरक्षित ना हो. | x | x | -| *6.4* | MSTG-PLATFORM-4 | यह ऐप आईपीसी स्कीम्स के माध्यम से सेन्सिटिव फंगक्शनैलिटी को इक्स्पोर्ट नहीं करता है। जब तक कि इन मेकनिज़म्ज़ को ठीक से सुरक्षित नहीं किया जाता है. | x | x | -| *6.5* | MSTG-PLATFORM-5 | जावा स्क्रिप्ट वेब व्यू मे डिसेबल होती है , जब तक की वह स्पष्ट रूप से आवश्यक नहीं हो. | x | x | -| *6.6* | MSTG-PLATFORM-6 | वेब व्यू को केवल प्रोटकॉल हैन्डलर के कम से कम सेट की अनुमति देने के लिए कन्फिग्यर किया जाता है ( केवल एचटीटीपीएस सपॉर्टड ). पटेन्शली, डैन्जरस हैन्डलरस , जैसे फाइल, टेल और ऐप आईडी डिसैबल्ड होते हैं. | x | x | -| *6.7* | MSTG-PLATFORM-7 | यदि ऐप के नेटिव मेथड के किसी वेब व्यू के संपर्क में है, तो वेरफाइड करे कि वेब व्यू केवल ऐप पैकिज के अंदर मौजूद जावा स्क्रिप्ट को रेन्डर करता है. | x | x | -| *6.8* | MSTG-PLATFORM-8 | अब्जेक्ट डीसीरिएलाइजेशन, यदि कोई हो, सुरक्षित सीरिएलाइजेशन एपीआईस का उपयोग करके कार्यन्वित किया जाता है. | x | x | -| *6.9* | MSTG-PLATFORM-9 | यह ऐप खुद को स्क्रीन ओवर्ले अटैक से बचाता है (सिर्फ ऐन्ड्रॉइड के लिए). | | x | -| *6.10* | MSTG-PLATFORM-10 | वेब व्यू के क्लीर होने से पहले एक वेब व्यू का कैशै, स्टोरेज और लोडिड रीसॉर्सिज़ (जावा स्क्रिप्ट) को क्लीर होना चाहिए. | | x | -| *6.11* | MSTG-PLATFORM-11 | जब भी सेसेन्सिटिव डेटा इंटर किया जाता है तो वेरीफाई करें कि ऐप कस्टम थर्ड पार्टी कीबोर्ड के उपयोग को रोकती है (सिर्फ आईओएस के लिए). | | x | - -## सदंर्भ निर्देश - -OWASP मोबाइल सुरक्षा परीक्षण गाइड इस खंड में सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है।. - -- Android: परीक्षण प्लेटफ़ॉर्म इंटरैक्शन - -- iOS: परीक्षण प्लेटफ़ॉर्म इंटरैक्शन - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP मोबाइल टॉप 10: M1 (अनुचित प्लेटफ़ॉर्म उपयोग) - -- OWASP मोबाइल टॉप 10: M7 ( पुअर कोड की गुणवत्ता) - -- CWE 20 (अनुचित इनपुट सत्यापन) - -- CWE 79 (वेब पेज जनरेशन के दौरान इनपुट के अनुचित न्यूट्रलाइज़ेशन) - -- CWE 200 (सूचना लीक / प्रकटीकरण) - -- CWE 250 (अनावश्यक विशेषाधिकार के साथ निष्पादन) - -- CWE 672 (समाप्ति या रिलीज़ के बाद किसी संसाधन पर कार्रवाई) - -- CWE 749 (खतरनाक विधि या कार्य का उजागर ) - -- CWE 772 (प्रभावी जीवनकाल के बाद संसाधन की अनुपलब्धता) - -- CWE 920 (बिजली की खपत में अनुचित प्रतिबंध) - -- CWE 925 (प्रसारण प्राप्तकर्ता द्वारा इरादे का अनुचित सत्यापन) - -- CWE 926 (एंड्रॉयड अनुप्रयोग घटकों का अनुचित निर्यात) - -- CWE 927 (सेंसिटिव कम्युनिकेशन के लिए इंप्लिकेंट इंटेंट का इस्तेमाल) - -- CWE 939 (कस्टम URL योजना के लिए हैंडलर में अनुचित प्राधिकरण) - diff --git a/Document-hi/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-hi/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 5b36ec415..000000000 --- a/Document-hi/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: कोड गुणवत्ता और बिल्ड सेटिंग आवश्यकताएँ - -## नियंत्रण उद्देश्य - -इस नियंत्रण का लक्ष्य यह सुनिश्चित करना है कि ऐप को विकसित करने में बुनियादी सुरक्षा कोडिंग प्रथाओं का पालन किया जाता है, और यह कि संकलक द्वारा प्रदान की जाने वाली "मुफ्त" सुरक्षा विशेषताएं सक्रिय हैं। - -## सुरक्षा सत्यापन आवश्यकताएँ - -| # | MSTG-ID | विवरण | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | ऐप को एक वैध प्रमाण पत्र के साथ हस्ताक्षरित और प्रावधानित किया गया है, जिनमें से निजी कुंजी(Private Key) ठीक से संरक्षित है। | x | x | -| **7.2** | MSTG-CODE-2 | एप्लिकेशन को रिलीज़ मोड में बनाया गया है, जिसमें रिलीज़ बिल्ड (जैसे गैर-डीबग करने योग्य) के लिए उपयुक्त सेटिंग्स हैं। | x | x | -| **7.3** | MSTG-CODE-3 | नेटिव् बाइनरी से डिबगिंग प्रतीकों को हटा दिया गया है। | x | x | -| **7.4** | MSTG-CODE-4 | डिबगिंग कोड और डेवलपर सहायता कोड (जैसे परीक्षण कोड, बैकडोर, छिपी सेटिंग्स) को हटा दिया गया है। एप्लिकेशन क्रिया त्रुटियों या डिबगिंग संदेशों को लॉग नहीं करता है। | x | x | -| **7.5** | MSTG-CODE-5 | मोबाइल एप्लिकेशन द्वारा उपयोग किए जाने वाले सभी तृतीय पक्ष घटक(Third party components), जैसे लाइब्रेरी और फ्रेमवर्क की पहचान की जाती है, और ज्ञात कमजोरियों(Vulnerabilities) के लिए जाँच की जाती है। | x | x | -| **7.6** | MSTG-CODE-6 | एप्लिकेशन पकड़ता है और संभावित अपवादों को संभालता है।| x | x | -| **7.7** | MSTG-CODE-7 | सुरक्षा नियंत्रण में एरर से निपटने में एरर डिफ़ॉल्ट रूप से पहुंच से इनकार करती है। | x | x | -| **7.8** | MSTG-CODE-8 | अप्रबंधित कोड(unmanaged code) में, मेमोरी को आवंटित(allocated), मुक्त(freed) और सुरक्षित रूप से उपयोग किया जाता है। | x | x | -| **7.9** | MSTG-CODE-9 | टूलचैन द्वारा दी जाने वाली मुफ्त सुरक्षा सुविधाएँ, जैसे कि बाइट-कोड मिनिफिकेशन, स्टैक प्रोटेक्शन, पीआईई सपोर्ट और ऑटोमैटिक रेफरेंस काउंटिंग सक्रिय हैं। | x | x | - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड ऊपर सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है। - -- एंड्रॉइड: टेस्टिंग कोड क्वालिटी और बिल्ड सेटिंग्स - -- iOS: टेस्टिंग कोड क्वालिटी और बिल्ड सेटिंग्स - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP मोबाइल टॉप 10: M7 (खराब कोड क्वालिटी) - -- CWE 20 (अनुचित इनपुट सत्यापन) - -- CWE 89 (SQL कमांड में उपयोग किए गए विशेष तत्वों का अनुचित उपयोग) - -- CWE 95 (डायनामिक रूप से मूल्यांकन किए गए कोड में निर्देशों का अनुचित सुधार) ('एवल इंजेक्शन') - -- CWE 119 (मेमोरी बफ़र की सीमा के भीतर संचालन में सुधार) - -- CWE 215 (डिबग सूचना के माध्यम से सूचना एक्सपोजर) - -- CWE 388 (7PK - एरर) - -- CWE 489 (लेफ्टओवर डिबग कोड) - -- CWE 502 (अविश्वसनीय डेटा का वर्णन) - -- CWE 511 (तर्क / समय बम) - -- CWE 656 (अंधकार(Obscurity) के माध्यम से सुरक्षा पर रिलायंस) - -- CWE 676 (संभावित रूप से खतरनाक कार्य का उपयोग) - -- CWE 937 (OWASP शीर्ष दस 2013 श्रेणी ए 9 - ज्ञात कमजोरियों(Known Vulnerabilities) के साथ घटकों का उपयोग करना) - diff --git a/Document-hi/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-hi/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 74e1f5be6..000000000 --- a/Document-hi/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,70 +0,0 @@ -# V8: लचीलापन आवश्यकताएँ - -## नियंत्रण उद्देश्य - -यह अनुभाग उन ऐप्स के लिए रक्षा के विस्तृत उपायों को शामिल करता है, जो संवेदनशील डेटा अथवा कार्यक्षमता तक पहुँच प्रदान करने या उसे प्रोसेस करने के लिए सुझाये जाते हैं। इनमें से किसी भी नियंत्रण की कमी से भेद्यता पैदा नहीं होती है - इसके बजाय, वे रिवर्स इंजीनियरिंग और विशिष्ट क्लाइंट-साइड हमलों के खिलाफ ऐप का लचीलापन बढ़ाने के लिए हैं। - -इस अनुभाग में नियंत्रण को आवश्यकतानुसार लागू किया जाना चाहिए, जो एप्लिकेशन के साथ अनधिकृत छेड़छाड़ और/या कोड के रिवर्स इंजीनियरिंग के कारण होने वाले जोखिमों के आकलन के आधार पर किया जाना चाहिए। हम OWASP दस्तावेज़ "रिवर्स इंजीनियरिंग और अनधिकृत कोड संशोधन रिवर्स इंजीनियरिंग और कोड संशोधन रोकथाम के तकनीकी जोखिम" (नीचे संदर्भ देखें) के साथ-साथ व्यावसायिक जोखिमों की सूची के साथ-साथ संबंधित तकनीकी खतरों के लिए परामर्श करने का सुझाव देते हैं। - -**ध्यान दें कि सॉफ़्टवेयर सुरक्षा का उपयोग सुरक्षा नियंत्रणों के प्रतिस्थापन के रूप में कभी नहीं किया जाना चाहिए। MASVR-R में सूचीबद्ध नियंत्रणों का उद्देश्य उन एप्लिकेशनों के लिए विशिष्ट,अतिरिक्त सुरक्षात्मक नियंत्रणों को जोड़ना है, जो MASSSR आवश्यकताओं को पूरा करते हैं।**. - -निम्नलिखित विचार लागू होते हैं: - -1. एक थ्रेट मॉडल को इस तरह से परिभाषित किया जाना चाहिए कि वो स्पष्ट रूप से उन क्लाइंट-साइड खतरों को अत सके जिनकी रक्षा तथा बचाव किया जाना है। इसके अतिरिक्त, वह योजना जो सुरक्षा के ग्रेड को प्रदान करने के लिए है उसे भी निर्दिष्ट किया जाना चाहिए। उदाहरण के लिए, एक उल्लिखित लक्ष्य महत्वपूर्ण मैनुअल रिवर्स इंजीनियरिंग प्रयास को निवेश करने के लिए ऐप को लक्षित करने के लिए लक्षित मैलवेयर के लेखकों को मजबूर करने के लिए हो सकता है। - -2. थ्रेट मॉडल विश्वसनीय और प्रासंगिक होना चाहिए। उदाहरण के लिए, यदि एक हैकर पूरी तरह से व्हाइट-बॉक्स को कोड-लिफ्ट कर सके तो एक व्हाइट-बॉक्स कार्यान्वयन में एक क्रिप्टोग्राफ़िक कुंजी को छुपाना शायद निरर्थक साबित हो सकता है। - -3. संरक्षण की प्रभावशीलता का सत्यापन सदैव एक ऐसे मानव विशेषज्ञ द्वारा किया जाना चाहिए जिसे विशेष प्रकार के एंटी-टैम्परिंग और औबफ़स्केशन का परीक्षण करने का अनुभव होता है (मोबाइल इंजीनियरिंग परीक्षण गाइड में "रिवर्स इंजीनियरिंग" और "सॉफ़्टवेयर सुरक्षा का आकलन" अध्याय)। - - - -### इम्पेड डायनामिक एनालिसिस एंड टैम्परिंग - -| # | MSTG-ID | विवरण | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | ऐप, उपयोगकर्ता को सचेत करके या ऐप को समाप्त करके एक निहित या जेलब्रोकेन डिवाइस की उपस्थिति को बताने या उसको प्रतिक्रिया देने का कार्य करता है। | x | -| **8.2** | MSTG-RESILIENCE-2 | ऐप, डिबगिंग और / या पता लगाता है, और एक डीबगर संलग्न होने की प्रतिक्रिया देता है। सभी उपलब्ध डिबगिंग प्रोटोकॉल को कवर किया जाना चाहिए। | x | -| **8.3** | MSTG-RESILIENCE-3 | ऐप, अपने स्वयं के सैंडबॉक्स के भीतर निष्पादन योग्य फ़ाइलों और महत्वपूर्ण डेटा के साथ छेड़छाड़ करने के लिए प्रतिक्रिया करता है तथा उनका पता लगाने का कार्य करता है। | x | -| **8.4** | MSTG-RESILIENCE-4 | ऐप, डिवाइस पर व्यापक रूप से उपयोग किए जाने वाले रिवर्स इंजीनियरिंग टूल और फ्रेमवर्क की उपस्थिति को बताने या उसको प्रतिक्रिया देने का कार्य करता है। | x | -| **8.5** | MSTG-RESILIENCE-5 | ऐप, एक एमुलेटर में चलाया जाता है, और उसको प्रतिक्रिया देने का कार्य करता है। | x | -| **8.6** | MSTG-RESILIENCE-6 | ऐप, स्वयं की मेमोरी स्पेस में कोड और डेटा से छेड़छाड़ करने का पता लगता है, और उसके लिए प्रतिक्रिया देने का कार्य करता है। | x | -| **8.7** | MSTG-RESILIENCE-7 | ऐप प्रत्येक रक्षा श्रेणी में कई तंत्र लागू करता है (8.1 to 8.6). ध्यान दें कि लचीलाता,तंत्र की मौलिकता की विविधता मात्रा से मापी जाती है। | x | -| **8.8** | MSTG-RESILIENCE-8 | डिटेक्शन मैकेनिज्म विभिन्न प्रकार की प्रतिक्रियाओं को ट्रिगर करता है, जिसमें देरी और चोरी की प्रतिक्रियाएं भी शामिल हैं। | x | -| **8.9** | MSTG-RESILIENCE-9 | औबफ़स्केशन प्रोग्रामेटिक डिफेंस पर लागू होता है, जो गतिशील विश्लेषण के माध्यम से डी-औबफ़स्केशन को बाधित करता है। | x | - -### डिवाइस बाइंडिंग - -| # | MSTG-ID | विवरण | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | डिवाइस के लिए अनोखे कई गुणों से प्राप्त डिवाइस फिंगरप्रिंट का उपयोग करके ऐप एक 'डिवाइस बाइंडिंग' कार्यक्षमता को लागू करता है। | x | - - - -### इम्पेड कॉम्प्रिहेंशन - -| # | MSTG-ID | विवरण | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | एप्लिकेशन से संबंधित सभी निष्पादन योग्य फाइलें और लाइब्रेरी या तो फ़ाइल स्तर पर एन्क्रिप्टेड हैं और / या निष्पादन योग्य के अंदर महत्वपूर्ण कोड और डेटा सेगमेंट एन्क्रिप्टेड या पैक किए गए हैं। तुच्छ स्थिर विश्लेषण महत्वपूर्ण कोड या डेटा को प्रकट नहीं करता है। | x | -| **8.12** | MSTG-RESILIENCE-12 | यदि औबफ़स्केशन का लक्ष्य संवेदनशील संगणनाओं की रक्षा करना है, तो एक औबफ़स्केशन स्कीम का उपयोग किया जाता है, जो विशेष रूप से कार्य के लिए उपयुक्त है और वर्तमान में प्रकाशित शोध को देखते हुए, मैनुअल और स्वचालित डी-औबफ़स्केशन विधियों के खिलाफ मजबूत है। औबफ़स्केशन स्कीम की प्रभावशीलता को मैन्युअल परीक्षण के माध्यम से सत्यापित किया जाना चाहिए। ध्यान दें कि जब भी संभव हो हार्डवेयर आधारित आइसोलेशन फीचर्स को औबफ़स्केशन पर पसंद किया जाता है। | x | - -### इम्पेड ईव्ज़्ड्रॉपिंग - -| # | MSTG-ID | विवरण | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | व्यापक सुरक्षा के लिए, संचार पक्षों के ठोस सख्त होने के बाद,एप्लिकेशन लेवल पेलोड एनक्रिप्शन को आगे जासूसी रोकने के लिए लागू किया जा सकता है। | x | - - - -## संदर्भ - -OWASP मोबाइल सुरक्षा परीक्षण गाइड इस खंड में सूचीबद्ध आवश्यकताओं की पुष्टि करने के लिए विस्तृत निर्देश प्रदान करता है। - -- Android: रिवर्स इंजीनियरिंग के खिलाफ लचीलापन परीक्षण - -- iOS: रिवर्स इंजीनियरिंग के खिलाफ लचीलापन परीक्षण - - -अधिक जानकारी के लिए, यह भी देखें: - -- OWASP Mobile Top 10: M8 (कोड टेम्परिंग) - -- OWASP Mobile Top 10: M9 (रिवर्स इंजीनियरिंग) - -- OWASP रिवर्स इंजीनियरिंग थ्रेट - -- OWASP रिवर्स इंजीनियरिंग और कोड संशोधन की रोकथाम - diff --git a/Document-hi/0x90-Appendix-A_Glossary.md b/Document-hi/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 9b5a52058..000000000 --- a/Document-hi/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# परिशिष्ट A: शब्दावली - -- **एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR)** – मेमोरी करप्शन बग्स के शोषण को और अधिक कठिन बनाने की तकनीक। -- **एप्लीकेशन सिक्योरिटी** – एप्लीकेशन-लेवल सिक्योरिटी उन घटकों के विश्लेषण पर केंद्रित होती है, जिसमें ओपन ऑपरेटिंग सिस्टम इंटरकनेक्शन रेफरेंस मॉडल (OSI मॉडल) की एप्लिकेशन परत शामिल होती है, बजाय इसके कि अंतर्निहित ऑपरेटिंग सिस्टम या कनेक्टेड नेटवर्क के लिए ध्यान केंद्रित किया जाए। -- **एप्लीकेशन सिक्योरिटी वेरिफिकेशन** – OWASP MASVS के खिलाफ एक आवेदन का तकनीकी मूल्यांकन। -- **एप्लीकेशन सिक्योरिटी वेरिफिकेशन रिपोर्ट** – एक रिपोर्ट जो किसी विशेष एप्लिकेशन के लिए सत्यापनकर्ता द्वारा उत्पादित समग्र परिणामों और सहायक विश्लेषण का दस्तावेजीकरण करती है। -- **ऑथिन्टकेशन** – किसी एप्लिकेशन उपयोगकर्ता के दावे की गई पहचान का सत्यापन। -- **ऑटमेटिड वेरिफिकेशन** – स्वचालित उपकरण (या तो गतिशील विश्लेषण उपकरण, स्थिर विश्लेषण उपकरण, या दोनों) का उपयोग जो समस्याओं को खोजने के लिए वल्नरेबिलिटी हस्ताक्षर का उपयोग करते हैं। -- **ब्लैक बॉक्स परीक्षण** - यह सॉफ्टवेयर परीक्षण का एक तरीका है जो किसी एप्लिकेशन की कार्यक्षमता को उसकी आंतरिक संरचनाओं या कामकाज में शामिल किए बिना जांचता है। -- **कम्पोनन्ट** – कोड की एक स्व-निहित इकाई, संबंधित डिस्क और नेटवर्क इंटरफेस के साथ जो अन्य घटकों के साथ संचार करती है। -- **क्रॉस-साइट स्क्रिप्टिंग (XSS)** - एक सुरक्षा भेद्यता आम तौर पर वेब एप्लिकेशन में पाई जाती है जो क्लाइंट-साइड स्क्रिप्ट के कंटेंट को इंजेक्शन की अनुमति देती है। -- **क्रिप्टोग्राफिक मॉड्यूल** - हार्डवेयर, सॉफ्टवेयर, और / या फर्मवेयर जो क्रिप्टोग्राफिक एल्गोरिदम को लागू करता है और / या क्रिप्टोग्राफिक कीज़ उत्पन्न करता है। -- **सीडब्ल्यूई(CWE)** - सीडब्ल्यूई(CWE) आम सॉफ्टवेयर सुरक्षा कमजोरियों की एक समुदाय-विकसित सूची है। यह एक सामान्य भाषा के रूप में, सॉफ्टवेयर सुरक्षा उपकरणों के लिए एक छड़ी और कमजोरी पहचान, शमन और रोकथाम के प्रयासों के लिए किसी आधार रेखा के रूप में कार्य करती है। -- **डायनेमिक एप्लिकेशन सिक्योरिटी टेस्टिंग (DAST)** - डीएसटी (DAST) तकनीकें, रनिंग एप्लीकेशन की सुरक्षा भेद्यता का पता लगाने के लिए डिज़ाइन की गई हैं। -- **डिजाइन वेरिफिकेशन** - किसी एप्लिकेशन की आर्किटेक्चर सुरक्षा का तकनीकी मूल्यांकन। -- **डायनेमिक वेरिफिकेशन** - स्वचालित टूल का उपयोग जो किसी एप्लिकेशन के निष्पादन के दौरान समस्याओं को खोजने के लिए वल्नरेबिलिटी हस्ताक्षरों का उपयोग करते हैं। -- **ग्लोबली यूनिक आइडेंटिफायर (GUID)** – एक विशिष्ट संदर्भ संख्या जो सॉफ्टवेयर में पहचानकर्ता के रूप में उपयोग की जाती है। -- **हाइपर टेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP)** - वितरित, सहयोगी, हाइपरमीडिया सूचना प्रणाली के लिए एक अनुप्रयोग प्रोटोकॉल। यह वर्ल्ड वाइड वेब के लिए डेटा संचार की नींव है। -- **हार्ड कोडित कीज़** - क्रिप्टोग्राफ़िक कीज़ जो डिवाइस में ही संग्रहीत होती हैं। -- **IPC** - अंतर प्रक्रिया संचार, IPC प्रक्रियाओं में एक दूसरे के साथ और अपनी गतिविधियों को समन्वित करने के लिए कर्नेल के साथ संवाद करते हैं। -- **इनपुट वेलडेशन** - अविश्वसनीय उपयोगकर्ता इनपुट का कैनोनेज़लाइजेशन और वेलिडेशन। -- **जावा बाइटकोड(Java Bytecode)** - जावा बाइटकोड जावा वर्चुअल मशीन (जेवीएम) का निर्देश सेट है। प्रत्येक बाइटकोड एक से बना होता है, या कुछ मामलों में दो बाइट्स जो निर्देश (ओपोड) का प्रतिनिधित्व करते हैं, साथ ही साथ मापदंडों को पारित करने के लिए शून्य या अधिक बाइट्स के साथ। -- **मालिसियस कोड** - कोड को इसके विकास के दौरान एक एप्लिकेशन में पेश किया जाता है जो एप्लिकेशन के मालिक के लिए अनभिज्ञ है, जो एप्लिकेशन की इच्छित सुरक्षा नीति को दरकिनार कर देता है। मैलवेयर जैसे वायरस या वार्म नहीं! -- **मैलवेयर** – एक्सेक्यूटबल कोड जो उपयोगकर्ता या प्रशासक के ज्ञान के बिना रनटाइम के दौरान एक एप्लिकेशन में पेश किया जाता है। -- **ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट (OWASP)** - ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट (OWASP) एक विश्वव्यापी स्वतंत्र और खुला समुदाय है जो एप्लिकेशन सॉफ्टवेयर की सुरक्षा में सुधार पर केंद्रित है। हमारा मिशन एप्लिकेशन सुरक्षा को "विज़बल" बनाना है, ताकि लोग और संगठन एप्लिकेशन सुरक्षा जोखिमों के बारे में सूचित निर्णय ले सकें। देखें: -- **व्यक्तिगत रूप से पहचान योग्य सूचना (PII)** - PII वह जानकारी है जिसका उपयोग किसी व्यक्ति को पहचानने, संपर्क करने या उसका पता लगाने के लिए या संदर्भ में किसी व्यक्ति की पहचान करने के लिए स्वयं या अन्य जानकारी के साथ किया जा सकता है। -- **स्थिति-स्वतंत्र निष्पादन योग्य (PIE)** - एक PIE मशीन कोड का एक निकाय है जिसे प्राथमिक मेमोरी में कहीं रखा जाता है।, इसके पूर्ण पते की परवाह किए बिना ठीक से निष्पादित होता है। -- **पब्लिक कीय इन्फ्रास्ट्रक्चर (PKI)** - PKI एक ऐसी व्यवस्था है जो संस्थाओं की संबंधित पहचान के साथ पब्लिक कीज़ को बांधती है। बाइंडिंग एक प्रमाणपत्र प्राधिकारी (सीए) द्वारा पंजीकरण और प्रमाण पत्र जारी करने की प्रक्रिया के माध्यम से स्थापित की जाती है। -- **स्टेटिक एप्लिकेशन सिक्योरिटी टेस्टिंग (SAST)** - SAST कोडिंग और डिज़ाइन स्थितियों के लिए एप्लिकेशन सोर्स कोड, बाइट कोड और बायनेरिज़ का विश्लेषण करने के लिए डिज़ाइन की गई तकनीकों का एक सेट है जो सुरक्षा कमजोरियों का संकेत है। SAST समाधान "अंदर से बाहर" एक गैर-आयामी स्थिति में एक एप्लिकेशन का विश्लेषण करते हैं। -- **एसडीएलसी(SDLC)** - सॉफ्टवेयर विकास जीवनचक्र। -- **सिक्योरिटी आर्किटेक्चर** - एक एप्लिकेशन के डिज़ाइन का एक अमूर्त जो पहचानता है और बताता है कि कहां और कैसे सुरक्षा नियंत्रण का उपयोग किया जाता है, और उपयोगकर्ता और एप्लिकेशन डेटा दोनों के स्थान और संवेदनशीलता की पहचान और वर्णन भी करता है। -- **सुरक्षा कॉन्फ़िगरेशन** - किसी एप्लिकेशन का रनटाइम कॉन्फ़िगरेशन जो प्रभावित करता है कि सुरक्षा नियंत्रण कैसे उपयोग किया जाता है। -- **सुरक्षा नियंत्रण** - एक फ़ंक्शन या घटक जो एक सुरक्षा जांच (जैसे एक एक्सेस कंट्रोल चेक) करता है या जब एक सुरक्षा प्रभाव में परिणाम (जैसे एक ऑडिट रिकॉर्ड उत्पन्न करना) होता है। -- **एसक्यूएल इंजेक्शन (SQLi)** - डेटा चालित एप्लिकेशन पर हमला करने के लिए उपयोग की जाने वाली कोड इंजेक्शन तकनीक, जिसमें मालिसियस SQL स्टेटमेंट्स को एक प्रवेश बिंदु में डाला जाता है। -- **SSO ऑथेंटिकेशन** - सिंगल साइन ऑन (SSO) तब होता है जब कोई उपयोगकर्ता किसी क्लाइंट में लॉग इन करता है और फिर उस प्लेटफ़ॉर्म, तकनीक या डोमेन का उपयोग करने वाले उपयोगकर्ता की परवाह किए बिना स्वचालित रूप से अन्य ग्राहकों के लिए साइन इन किया जाता है। उदाहरण के लिए जब आप Google में लॉग इन करते हैं तो आप स्वतः ही youtube, डॉक्स और मेल सेवा में प्रवेश कर जाते हैं। -- **थ्रेट मॉडलिंग** - थ्रेट एजेंटों, सुरक्षा क्षेत्रों, सुरक्षा नियंत्रणों और महत्वपूर्ण तकनीकी और व्यावसायिक संपत्ति की पहचान करने के लिए तेजी से परिष्कृत सुरक्षा आर्किटेक्चर विकसित करने वाली तकनीक। -- **ट्रांसपोर्ट लेयर सिक्योरिटी** - क्रिप्टोग्राफ़िक प्रोटोकॉल जो इंटरनेट पर संचार सुरक्षा प्रदान करते हैं -- **URI और URL** - एक यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर एक अक्षर का एक स्ट्रिंग है जिसका उपयोग किसी नाम या वेब संसाधन की पहचान करने के लिए किया जाता है। एक यूनिफ़ॉर्म रिसोर्स लोकेटर का उपयोग अक्सर किसी संसाधन के संदर्भ के रूप में किया जाता है। -- **उपयोगकर्ता स्वीकृति परीक्षण (UAT)** - परंपरागत रूप से एक परीक्षण वातावरण है जो उत्पादन पर्यावरण की तरह व्यवहार करता है जहां सभी सॉफ्टवेयर परीक्षण लाइव होने से पहले किये जाते है। -- **सत्यापनकर्ता** - वह व्यक्ति या टीम जो OWASP MASVS आवश्यकताओं के विरुद्ध किसी एप्लिकेशन की समीक्षा कर रहा है। -- **श्वेतसूची(Whitelist)** - अनुमत डेटा या संचालन की एक सूची, उदाहरण के लिए वर्णों की एक सूची जो इनपुट सत्यापन करने की अनुमति है। -- **X.509 सर्टिफ़िकट** - X.509 सर्टिफ़िकट एक डिजिटल सर्टिफ़िकट है जो व्यापक रूप से स्वीकार किए गए अंतर्राष्ट्रीय X.509 पब्लिक कीय इंफ्रास्ट्रक्चर (PKI) मानक का उपयोग यह सत्यापित करने के लिए कि पब्लिक कीय उपयोगकर्ता के अंतर्गत आती है, कंप्यूटर या सेवा पहचान प्रमाण पत्र के भीतर होती है। diff --git a/Document-hi/0x91-Appendix-B_References.md b/Document-hi/0x91-Appendix-B_References.md deleted file mode 100644 index aad785cb1..000000000 --- a/Document-hi/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# परिशिष्ट B: संदर्भ - -निम्नलिखित OWASP परियोजनाएं इस मानक के उपयोगकर्ताओं / अपनाने वालों के लिए सबसे अधिक उपयोगी हैं: - -- OWASP मोबाइल सुरक्षा परियोजना - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP मोबाइल सुरक्षा परीक्षण गाइड - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP मोबाइल टॉप 10 रिस्क - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP रिवर्स इंजीनियरिंग और कोड संशोधन रोकथाम(Prevention) - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -इसी तरह, निम्नलिखित वेब साइट इस मानक के उपयोगकर्ताओं / अपनाने वालों के लिए उपयोगी होने की संभावना है: - -- MITER कॉमन वेकनेस एन्यूमरेशन - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- पीसीआई(PCI) सुरक्षा मानक परिषद - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI डाटा सिक्योरिटी स्टैंडर्ड (DSS) v3.0 आवश्यकताएँ और सुरक्षा मूल्यांकन प्रक्रिया - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-hi/CHANGELOG.md b/Document-hi/CHANGELOG.md deleted file mode 100644 index 9420f8cd5..000000000 --- a/Document-hi/CHANGELOG.md +++ /dev/null @@ -1,89 +0,0 @@ -# चेंजलॉग - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 मार्च 2020 - अंतर्राष्ट्रीय रिलीज़ - -## V1.2-RC - 5 अक्टूबर 2019 - पूर्व-रिलीज़ (केवल अंग्रेजी) - -निम्नलिखित परिवर्तन 1.2 रिलीज का हिस्सा हैं: - -- प्रमुख स्थिति के लिए प्रचारित। -- आवश्यकता परिवर्तित: MSTG-STORAGE-1 "का उपयोग करने की आवश्यकता है"। -- आवश्यकताएँ MSTG-STORAGE-13, MSTG-STORAGE-14, और MSTG-STORAGE-15 डेटा सुरक्षा पर ध्यान देने के साथ जोड़े जाते हैं। -- आवश्यकता MSTG-AUTH-11 को प्रासंगिक जानकारी को संरक्षित करने के लिए अद्यतन किया जाता है। -- आवश्यकता MSTG-CODE-4 को केवल डीबगिंग से अधिक कवर करने के लिए अद्यतन किया गया है। -- WebViews के आगे के सुरक्षित उपयोग के लिए MSTG-PLATFORM-10 की आवश्यकता को जोड़ा गया। -- आवश्यकता MSTG-AUTH-12 डेवलपर्स को कार्यान्वित करने वाले प्राधिकरणों को याद दिलाने के लिए जोड़ा गया, खासकर बहु-उपयोगकर्ता ऐप्स के मामले में। -- MASVS का उपयोग कैसे किया जाना चाहिए, इस पर थोड़ा और विवरण जोड़ा गया है। -- भुगतान की गई सामग्री पर थोड़ा और विवरण जोड़ा गया। -- आवश्यकता MSTG-ARCH-11 में L2 अनुप्रयोगों के लिए एक जिम्मेदार प्रकटीकरण नीति को शामिल किया गया। -- आवश्यकता MSTG-ARCH-12 ने एप्लिकेशन डेवलपर्स को यह दिखाने के लिए जोड़ा कि संबंधित अंतर्राष्ट्रीय गोपनीयता कानूनों का पालन किया जाना चाहिए। -- अंग्रेजी संस्करण में सभी संदर्भों के लिए एक सुसंगत शैली बनाई गई। -- आवश्यकता MSTG-PLATFORM-11 को तीसरे पक्ष के कीबोर्ड के माध्यम से जासूसी करने के लिए जोड़ा गया। -- आवश्यकता MSTG-MSTG-RESILIENCE-13 एक आवेदन पर ईव्सड्रोपिंग लगाने के लिए जोड़ा गया। - -## V1.1.4 - 4 जुलाई 2019 - समिट संस्करण(Sumit edition) - -निम्नलिखित परिवर्तन रिलीज़ का हिस्सा हैं 1.1.4: - -- सभी मार्कडाउन मुद्दों को ठीक करें। -- फ्रेंच और स्पेनिश अनुवाद में अपडेट। -- चेंज लॉग को चीनी (ZHTW) और जापानी में अनुवादित किया। -- URL के मार्कडाउन सिंटैक्स और रीचेबिलिटी का स्वचालित सत्यापन। -- आवश्यकताओं में जोड़े गए पहचान कोड, जो आसानी से सिफारिशों और टेस्टकेस को खोजने के लिए एमएसटीजी के भविष्य के संस्करण में शामिल किए जाएंगे। -- रेपो आकार को कम किया गया और .ignignore में जनरेट किया गया। -- आचार संहिता और योगदान दिशानिर्देशों को जोड़ा गया। -- एक पुल-अनुरोध टेम्पलेट जोड़ा गया। -- Gitbook वेबसाइट होस्ट करने के लिए उपयोग में रेपो के साथ सिंक अपडेट किया गया। -- सभी अनुवादों के लिए XML / JSON / CSV उत्पन्न करने के लिए स्क्रिप्ट अपडेट किया गया। -- फॉरवर्ड को चीनी (ZHTW) में अनुवादित किया। - -## V1.1.3 - 9 जनवरी 2019 - छोटे सुधार(small fixes) - -- स्पेनिश संस्करण में आवश्यकता 7.1 का अनुवाद मुद्दा ठीक करें -- स्वीकृतियां में अनुवादकों का नया सेटअप - -## V1.1.2 - 3 जनवरी 2019 - प्रायोजन और अंतर्राष्ट्रीयकरण - -निम्नलिखित परिवर्तन 1.1.2 रिलीज का हिस्सा हैं: - -- ई-बुक के खरीदारों के लिए जोड़ा गया धन्यवाद नोट। -- V4 में अनुपलब्ध प्रमाणीकरण लिंक और अपडेटेड टूटा हुआ प्रमाणीकरण लिंक जोड़ा गया। -- अंग्रेजी में 4.7 और 4.8 की निश्चित स्वैप। -- पहला अंतरराष्ट्रीय रिलीज! -   - स्पेनिश अनुवाद में सुधार। अनुवाद अब अंग्रेजी (1.1.2) के साथ सिंक किया गया है। -   - रूसी अनुवाद में सुधार। अनुवाद अब अंग्रेजी (1.1.2) के साथ सिंक किया गया है। -   - चीनी (ZHTW) फ्रेंच, जर्मन और जापानी की पहली रिलीज! -- अनुवाद में आसानी के लिए सरलीकृत दस्तावेज। -- स्वचालित रिलीज के लिए जोड़ा गया निर्देश। - -## V1.1.0 - 14 जुलाई 2018 - -निम्नलिखित परिवर्तन रिलीज़ 1.1 का हिस्सा हैं: - -- आवश्यकता 2.6 "क्लिपबोर्ड पाठ फ़ील्ड पर समर्पित है जिसमें संवेदनशील डेटा हो सकता है।" हटा लिया गया था। -- 2.2 आवश्यकता "कोई संवेदनशील डेटा ऐप कंटेनर या सिस्टम क्रेडेंशियल स्टोरेज सुविधाओं के बाहर संग्रहीत नहीं किया जाना चाहिए।" जोड़ा गया। -- 2.1 की आवश्यकता थी "सिस्टम क्रेडेंशियल स्टोरेज सुविधाओं का उपयोग PII, उपयोगकर्ता क्रेडेंशियल्स या क्रिप्टोग्राफिक कीज़ जैसे संवेदनशील डेटा को संग्रहीत करने के लिए उचित रूप से किया जाता है।" - -## V1.0 12 - जनवरी 2018 - -निम्नलिखित परिवर्तन रिलीज़ 1.0 का हिस्सा हैं: - -- 8.9 को 8.12 के समान हटाएं -- 4.6 अधिक सामान्य बनाया -- मामूली सुधार (टाइपो आदि) diff --git a/Document-hi/GLOSSARY.md b/Document-hi/GLOSSARY.md deleted file mode 100644 index f104b921d..000000000 --- a/Document-hi/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# परिशिष्ट A: शब्दावली - -## एड्रेस स्पेस लेआउट रैंडमाइजेशन (ASLR) - -मेमोरी करप्शन के बग को और अधिक कठिन बनाने की तकनीक। - -## ऐप्लीकेशन सिक्योरिटी - -अनुप्रयोग-स्तरीय सुरक्षा घटकों के विश्लेषण पर केंद्रित है जिसमें अंतर्निहित ऑपरेटिंग सिस्टम या कनेक्टेड नेटवर्क उदाहरण के लिए ध्यान केंद्रित करने के बजाय ओपन सिस्टम इंटरकनेक्शन रेफरेंस मॉडल (OSI मॉडल) की एप्लिकेशन परत शामिल है। - -## ऐप्लीकेशन सिक्युरटी विरफ़केशन - -OWASP MASVS के विरुद्ध एक एप्लिकेशन का तकनीकी मूल्यांकन। - -## ऐप्लीकेशन सिक्योरिटी वेरीफिकेशन रिपोर्ट - -एक रिपोर्ट जो किसी विशेष एप्लिकेशन के लिए सत्यापनकर्ता द्वारा उत्पादित समग्र परिणामों और सहायक विश्लेषण का दस्तावेजीकरण करती है। - -## ऑथेंटिकेशन - -एक आवेदन उपयोगकर्ता के दावे की गई पहचान का सत्यापन। - -## ऑटोमेटेड वेरिफिकेशन - -ऑटोमेटेड टूल्स (या तो डायनेमिक अनेलसस टूल्स, स्टेटिक अनेलसस टूल्स, या दोनों) का उपयोग जो समस्याओं को खोजने के लिए वल्नरबिलिटी सिग्‍नेचर का उपयोग करते हैं। - -## ब्लैक बॉक्स परीक्षण - -यह सॉफ्टवेयर परीक्षण का एक तरीका है जो किसी एप्लिकेशन की कार्यक्षमता को उसकी आंतरिक संरचनाओं या कामकाज में शामिल किए बिना जांचता है। - -## कॉम्पोनेन्ट - -संबंधित डिस्क और नेटवर्क इंटरफेस के साथ कोड की एक स्व-निहित इकाई, जो अन्य घटकों के साथ संचार करती है। - -## क्रॉस-साइट स्क्रिप्टिंग(XSS) - -एक सिक्योरिटी वल्नेरेबिलिटी आम तौर पर वेब एप्लिकेशन में पाई जाती है जो क्लाइंट-साइड स्क्रिप्ट के कंटेंट को इंजेक्शन की अनुमति देती है। - -## क्रिप्टोग्राफ़िक मॉड्यूल - -हार्डवेयर, सॉफ्टवेयर, और / या फर्मवेयर जो क्रिप्टोग्राफ़िक एल्गोरिदम को लागू करता है और / या क्रिप्टोग्राफ़िक कीस उत्पन्न करता है। - -## CWE - -CWE सामान्य सॉफ़्टवेयर सुरक्षा कमजोरियों की एक समुदाय-विकसित सूची है। यह एक सामान्य भाषा के रूप में, सॉफ्टवेयर सुरक्षा उपकरणों के लिए एक छड़ी और कमजोरी पहचान, शमन और रोकथाम के प्रयासों के लिए आधार रेखा के रूप में कार्य करता है। - -## DAST - -डायनामिक एप्लिकेशन सिक्योरिटी टेस्टिंग (DAST) प्रौद्योगिकियाँ ऐसी स्थिति का पता लगाने के लिए डिज़ाइन की गई हैं जो इसके चलने की स्थिति में किसी सिक्योरिटी वल्नरबिलिटी का संकेत देती हैं। - -## डिज़ाइन वेरिफिकेशन - -एक एप्लिकेशन की सिक्योरिटी आर्किटेक्चर का तकनीकी मूल्यांकन। - -## डायनामिक वेरिफिकेशन - -ऑटोमेटेड टूल का उपयोग जो किसी एप्लिकेशन के निष्पादन के दौरान समस्याओं को खोजने के लिए वल्नरबिलिटी सिग्‍नेचर का उपयोग करते हैं। - -## ग्लोबली यूनिक आइडेंटिफायर(GUID) - -सॉफ्टवेयर में पहचानकर्ता के रूप में उपयोग किया जाने वाला एक अद्वितीय संदर्भ संख्या। - -## हाइपर टेक्स्ट ट्रांसफर प्रोटोकॉल(HTTP) - -वितरित, सहयोगी, हाइपरमीडिया सूचना प्रणाली के लिए एक अनुप्रयोग प्रोटोकॉल। यह वर्ल्ड वाइड वेब के लिए डेटा संचार की नींव है। - -## हार्डकोडेड कीस - -क्रिप्टोग्राफिक कीस जो डिवाइस में ही संग्रहीत हैं। - -## IPC - -इंटर प्रोसेस कम्युनिकेशंस, आईपीसी प्रोसेस में एक-दूसरे के साथ और कर्नेल के साथ अपनी गतिविधियों के समन्वय के लिए संवाद करते हैं। - -## इनपुट वेलिडेशन - -अविश्वसनीय उपयोगकर्ता इनपुट का कैनॉनिकलाइज़ेशन और सत्यापन। - -## JAVA Bytecode - -Java bytecode जावा वर्चुअल मशीन (JVM) का इंस्ट्रक्शन सेट है। प्रत्येक बाइटकोड एक से बना होता है, या कुछ मामलों में दो बाइट्स जो निर्देश (ओपोड) का प्रतिनिधित्व करते हैं, साथ ही साथ गुजरने वाले मापदंडों के लिए शून्य या अधिक बाइट्स के साथ। - -## मालिसियस कोड - -कोड को इसके विकास के दौरान एक एप्लिकेशन में पेश किया जाता है, जो एप्लिकेशन के मालिक के लिए अनभिज्ञ है, जो एप्लिकेशन की इच्छित सुरक्षा नीति को दरकिनार कर देता है। मैलवेयर जैसे वायरस या वॉर्म नहीं! - -## मैलवेयर - -निष्पादन योग्य कोड जो अनुप्रयोग उपयोगकर्ता या व्यवस्थापक के ज्ञान के बिना रनटाइम के दौरान एक एप्लिकेशन में पेश किया जाता है। - -## ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट (OWASP) - -ओपन वेब एप्लिकेशन सिक्योरिटी प्रोजेक्ट (OWASP) एक विश्वव्यापी स्वतंत्र और खुला समुदाय है, जो एप्लिकेशन सॉफ़्टवेयर की सुरक्षा को बेहतर बनाने पर केंद्रित है। हमारा मिशन अनुप्रयोग सुरक्षा को "दृश्यमान" बनाना है, ताकि लोग और संगठन आवेदन सुरक्षा जोखिमों के बारे में सूचित निर्णय ले सकें। देखें: - -## पर्सनली आइडेनटिफ़ाइअबॅल इनफार्मेशन (PII) - -पीआईआई वह जानकारी है जिसका उपयोग किसी व्यक्ति को पहचानने, संपर्क करने या खोजने या संदर्भ में किसी व्यक्ति की पहचान करने के लिए स्वयं या अन्य जानकारी के साथ किया जा सकता है। - -## PIE - -पोजीशन-इंडिपेंडेंट एक्सेक्यूटबले (PIE) मशीन कोड का एक निकाय है, जिसे प्राथमिक मेमोरी में कहीं रखा जा रहा है, इसके पूर्ण पते की परवाह किए बिना ठीक से निष्पादित होता है। - -## PKI - -पीकेआई एक ऐसी व्यवस्था है जो पब्लिक कीस को संस्थाओं की संबंधित पहचान के साथ बांधती है। बाइंडिंग एक प्रमाणपत्र प्राधिकारी (सीए) द्वारा पंजीकरण और प्रमाण पत्र जारी करने की प्रक्रिया के माध्यम से स्थापित की जाती है। - -## SAST - -स्टेटिक एप्लीकेशन सिक्योरिटी टेस्टिंग (SAST) एक ऐसी तकनीक का समूह है जो एप्लीकेशन सोर्स कोड, बाइट कोड और बायनेरिज़ को कोडिंग और डिज़ाइन स्थितियों का विश्लेषण करने के लिए डिज़ाइन किया गया है जो सुरक्षा कमजोरियों का संकेत हैं। SAST समाधान "अंदर से बाहर" एक गैर-आयामी स्थिति में एक अनुप्रयोग का विश्लेषण करते हैं। - -## SDLC - -सॉफ्टवेयर विकास जीवनचक्र। - -## सिक्योरिटी आर्किटेक्चर - -एक एप्लिकेशन के डिज़ाइन का एक अमूर्त जो पहचानता है और बताता है कि कहां और कैसे सुरक्षा नियंत्रण का उपयोग किया जाता है, और उपयोगकर्ता और एप्लिकेशन डेटा दोनों के स्थान और संवेदनशीलता की पहचान और वर्णन भी करता है। - -## सिक्योरिटी कॉन्फ़िगरेशन - -किसी एप्लिकेशन का रनटाइम कॉन्फ़िगरेशन जो प्रभावित करता है कि सुरक्षा नियंत्रण कैसे उपयोग किए जाते हैं। - -## सिक्योरिटी कण्ट्रोल - -एक फ़ंक्शन या घटक जो एक सुरक्षा जांच (जैसे एक एक्सेस कंट्रोल चेक) करता है या जब एक सुरक्षा प्रभाव में परिणाम (जैसे एक ऑडिट रिकॉर्ड उत्पन्न करना) होता है। - -## SQL इंजेक्शन (SQLi) - -डेटा चालित अनुप्रयोगों पर हमला करने के लिए उपयोग की जाने वाली एक कोड इंजेक्शन तकनीक, जिसमें दुर्भावनापूर्ण SQL स्टेटमेंट को एक एंट्री पॉइंट में डाला जाता है। - -## SSO ऑथेंटिकेशन - -सिंगल साइन ऑन (एसएसओ) तब होता है जब कोई उपयोगकर्ता किसी क्लाइंट में लॉग इन करता है और फिर उस प्लेटफ़ॉर्म, तकनीक, या डोमेन का उपयोग करने वाले उपयोगकर्ता की परवाह किए बिना स्वचालित रूप से अन्य ग्राहकों के लिए साइन इन किया जाता है। उदाहरण के लिए जब आप Google में लॉग इन करते हैं तो आप स्वतः ही youtube, डॉक्स और मेल सेवा में प्रवेश कर जाते हैं। - -## थ्रेट मॉडलिंग - -थ्रेट एजेंटों, सुरक्षा क्षेत्रों, सुरक्षा नियंत्रणों और महत्वपूर्ण तकनीकी और व्यावसायिक संपत्तियों की पहचान करने के लिए तेजी से परिष्कृत सुरक्षा आर्किटेक्चर विकसित करने वाली तकनीक। - -## ट्रांसपोर्ट लेयर सिक्योरिटी - -क्रिप्टोग्राफ़िक प्रोटोकॉल जो इंटरनेट पर संचार सुरक्षा प्रदान करते हैं - -## URI and URL - -यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर एक अक्षर का एक स्ट्रिंग है जिसका उपयोग किसी नाम या वेब संसाधन की पहचान करने के लिए किया जाता है। एक यूनिफ़ॉर्म रिसोर्स लोकेटर का उपयोग अक्सर किसी संसाधन के संदर्भ के रूप में किया जाता है। - -## उपयोगकर्ता स्वीकृति परीक्षण (UAT) - -परंपरागत रूप से एक परीक्षण वातावरण जो उत्पादन वातावरण की तरह व्यवहार करता है जहां सभी सॉफ्टवेयर परीक्षण लाइव होने से पहले किए जाते हैं। - -## सत्यापनकर्ता(Verifier) - -वह व्यक्ति या टीम जो OWASP MASVS आवश्यकताओं के विरुद्ध किसी एप्लिकेशन की समीक्षा कर रही है। - -## वाइटलिस्ट(Whitelist) - -अनुमत डेटा या संचालन की एक सूची, उदाहरण के लिए वर्णों की एक सूची जो इनपुट सत्यापन करने की अनुमति है। - -## X.509 सर्टिफिकेट - -एक X.509 सर्टिफिकेट एक डिजिटल प्रमाण पत्र है जो व्यापक रूप से स्वीकार किए गए अंतर्राष्ट्रीय X.509 पब्लिक कीस अवसंरचना (PKI) मानक का उपयोग करता है यह प्रमाणित करने के लिए कि पब्लिक कीस सर्टिफिकेट के भीतर मौजूद उपयोगकर्ता, कंप्यूटर या सेवा पहचान से संबंधित है। diff --git a/Document-hi/SUMMARY.md b/Document-hi/SUMMARY.md deleted file mode 100644 index 66a5024c1..000000000 --- a/Document-hi/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Table of Contents - -- [Changelog](CHANGELOG.md) -- [Foreword](0x01-Foreword.md) -- [Frontispiece](0x02-Frontispiece.md) -- [Using the MASVS](0x03-Using_the_MASVS.md) -- [Assessment and Certification](0x04-Assessment_and_Certification.md) - -## Security Requirements - -- [V1: Architecture, Design and Threat Modeling Requirements](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Data Storage and Privacy Requirements](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Cryptography Requirements](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Authentication and Session Management Requirements](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Network Communication Requirements](0x10-V5-Network_communication_requirements.md) -- [V6: Platform Interaction Requirements](0x11-V6-Interaction_with_the_environment.md) -- [V7: Code Quality and Build Setting Requirements](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Resilience Requirements](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendix - -- [Appendix A - Glossary](GLOSSARY.md) -- [Appendix B - References](0x91-Appendix-B_References.md) diff --git a/Document-hi/book.json b/Document-hi/book.json deleted file mode 100644 index 0c8378bc5..000000000 --- a/Document-hi/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "en" -} diff --git a/Document-hi/images/CC-license.png b/Document-hi/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-hi/images/CC-license.png and /dev/null differ diff --git a/Document-hi/images/MASVS-levels.png b/Document-hi/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-hi/images/MASVS-levels.png and /dev/null differ diff --git a/Document-hi/images/OWASP_logo.png b/Document-hi/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-hi/images/OWASP_logo.png and /dev/null differ diff --git a/Document-hi/images/license.png b/Document-hi/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-hi/images/license.png and /dev/null differ diff --git a/Document-hi/images/masvs-levels-new.jpg b/Document-hi/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-hi/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-hi/images/masvs-mini-cover.jpg b/Document-hi/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-hi/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-hi/images/masvs-mini-cover.png b/Document-hi/images/masvs-mini-cover.png deleted file mode 100644 index 1e3d72f72..000000000 Binary files a/Document-hi/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-hi/metadata.md b/Document-hi/metadata.md deleted file mode 100644 index fc307f7b6..000000000 --- a/Document-hi/metadata.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'hi' # bug in the eisvogel template, switch back to english -languagetext: '' - -# toc-title is translated when `lang` is correctly defined -toc-title: 'Table of Content' - -mainfont: 'Lohit Devanagari' -sansfont: 'Lohit Devanagari' -monofont: 'Noto Sans Mono' - ---- diff --git a/Document-ja/0x01-Foreword.md b/Document-ja/0x01-Foreword.md deleted file mode 100644 index 9055aba5d..000000000 --- a/Document-ja/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# 序文 - -技術革新は迅速に起こります。一昔前、スマートフォンは小さいキーボードを持つ魅力のない端末、技術に精通したビジネスユーザーのための高価な玩具でした。今日、スマートフォンは私たちの生活に不可欠なものです。私たちは情報、ナビゲーション、コミュニケーションのためにそれらに頼っています。ビジネスや社会生活の中の至るところにあります。 - -すべての新しいテクノロジーは新しいセキュリティリスクをもたらし、その変化に対応することはセキュリティ業界が直面する主要な課題のひとつです。防御側は常に数ステップ遅れます。例えば、多くのデフォルトの対応は物事をなすための古い方法を適用することでした。スマートフォンは小さなコンピュータと似ており、モバイルアプリはクラシックなソフトウェアと同様ですから、確かにセキュリティ要件は似ているでしょう？しかしそのようにはいきません。スマートフォンのオペレーティングシステムはデスクトップオペレーティングシステムとは異なりますし、モバイルアプリはウェブアプリとは異なります。例えば、従来の手法であるシグネチャベースのウイルススキャンは最新のモバイルOS環境では意味を成しません。モバイルアプリの配信モデルと互換性がないだけでなく、サンドボックスの制限により技術的にも不可能です。また、バッファオーバーフローやXSSの問題などいくつかの脆弱性クラスは、デスクトップアプリやWebアプリケーションよりも（例外はありますが）一般的なモバイルアプリのコンテキストではあまり意味がありません。 - -時間の経過と共に、私たちの業界はモバイル脅威の状況を把握してきました。結局のところ、モバイルセキュリティはデータ保護に関するすべてのことです。アプリは私たちの個人情報、写真、録音、メモ、アカウントデータ、ビジネス情報、位置などを保存します。アプリは私たちが毎日使っているサービスに接続するクライアントとして動作しており、それぞれすべてのメッセージを処理するコミュニケーションハブとして他の人とやり取りします。人のスマートフォンに侵入し、その人の人生にアクセスすることができます。モバイルデバイスがとてもたやすく失くしたり盗まれたりし、モバイルマルウェアが増加していることを考えるとき、データ保護の必要性がさらに明らかになります。 - -したがってモバイルアプリのセキュリティ標準はモバイルアプリが機密情報を処理、保存、保護する方法に焦点を当てる必要があります。iOSやAndroidなどの最新のモバイルオペレーティングシステムでは安全なデータストレージと通信のための優れたAPIを提供していますが、効果を発揮するには正しく実装され使用されている必要があります。データストレージ、アプリ間通信、暗号APIの適切な使い方や安全なネットワーク通信は慎重な検討が必要な局面のほんの一部です。 - -データの機密性と完全性を保護するためにどれだけ正しく行うべきかが業界のコンセンサスを必要とする重要な質問です。例えば、私たちの多くはモバイルアプリがTLSエクスチェンジの中でサーバー証明書を検証する必要があることに同意します。しかし SSL 証明書ピンニングはどうでしょう？それを行わないと脆弱性が生じるでしょうか？アプリが機密データを処理する場合にそれを要件とすべきでしょうか、それとも逆効果でしょうか？OSがアプリをサンドボックス化していても、SQLiteデータベースに格納されるデータを暗号化する必要があるでしょうか？あるアプリに適切なものでも別のアプリには非現実的かもしれません。MASVS はさまざまな脅威シナリオにあう検証レベルを使用してこれらの要件を標準化する試みです。 - -さらに、ルートマルウェアやリモート管理ツールの登場によりモバイルオペレーティングシステム自体に悪用可能な欠陥が存在することが認識されています。そのため、機密性の高いデータへの追加保護を提供し、クライアント側の改竄を防止するために、コンテナ化戦略がますます使用されています。物事は複雑に入り組んでいます。ハードウェア支援のセキュリティ機能や Android for Work や Samsung Knox などの OS レベルのコンテナ化ソリューションが存在しますが、さまざまなデバイスの間で一貫して利用できるわけではありません。バンドエイドとして、ソフトウェアベースの保護対策を実装できますが、残念ながら、このような種類の保護を検証するための標準やテストプロセスはありません。 - -結果として、モバイルアプリセキュリティテストレポートは混沌としてます。例えば、あるテスト技術者はセキュリティ上の欠陥としてAndroidアプリでの難読化やルート検出の欠如を報告しています。一方、文字列の暗号化、デバッガの検出、制御フローの難読化などの処置は必須ではありません。しかし、このような二元的な方法は理にかなっていません。耐性は二元的な命題ではないためです。これは守ることを目指す特定のクライアント側の脅威に依存します。ソフトウェア保護は無駄ではありませんが、最終的にバイパスすることが可能であるため、ソフトウェア保護をセキュリティコントロールの代わりに使用してはいけないということです。 - -MASVSの全体的な目標はモバイルアプリケーションセキュリティのベースライン (MASVS-L1) を提供することであり、多層防御処置 (MASVS-L2) やクライアント側の脅威に対する保護 (MASVS-R) も可能にします。MASVSは以下を達成するためのものです。 - -- セキュアなモバイルアプリケーションを開発しようとするソフトウェアアーキテクトや開発者に要件を提供する -- モバイルアプリのセキュリティコードレビューとしてテストできる業界標準を提供する -- モバイルセキュリティにおけるソフトウェア保護メカニズムの役割を明確にして、その有効性を検証するための要件を提供する -- さまざまなユースケースに対してどのレベルのセキュリティが推奨されるかに関する具体的な推奨を提供する - -私たちは100%の業界のコンセンサスが達成不可能であることを認識しています。それでも、私たちはMASVSがモバイルアプリの開発やテストのすべてのフェーズでガイダンスを提供するのに役立つことを願っています。オープンソース標準として、MASVSは時間の経過と共に進化するでしょう。そして、私たちは寄稿や提案を歓迎します。 - -Bernhard Mueller より diff --git a/Document-ja/0x02-Frontispiece.md b/Document-ja/0x02-Frontispiece.md deleted file mode 100644 index bf9459f40..000000000 --- a/Document-ja/0x02-Frontispiece.md +++ /dev/null @@ -1,56 +0,0 @@ -# 本標準について - -![OWASP Logo](images/OWASP_logo.png) - -Mobile Application Security Verification Standard (MASVS) へようこそ。MASVS は iOS および Android 上のセキュアなモバイルアプリケーションを設計、開発、テストするときに必要となるセキュリティ要件のフレームワークを確立するためのコミュニティの取組みです。 - -MASVS はコミュニティにおける取組みと業界からのフィードバックの成果です。私たちは本標準が時間の経過とともに進化することを期待しており、コミュニティからのフィードバックを歓迎します。私たちと連絡を取る最善の方法は OWASP Mobile Project Slack チャンネルを利用することです。 - - - -アカウントは以下の URL で作成できます。 - -[https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/) - -## 著作権とライセンス - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. 本著作物は [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/) に基づいてライセンスされています。再使用または配布する場合は、他者に対し本著作物のライセンス条項を明らかにする必要があります。 - - - -## 謝辞 - -| プロジェクトリーダー | 主執筆者 | 共同執筆者およびレビュー担当者 | -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| 言語 | 翻訳者およびレビュー担当者 | -| --------------- | ------------------------------------------------------------ | -| ブラジルポルトガル語 | Mateus Polastro, Humberto Junior, Rodrigo | -| 繁体字中国語 | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| 簡体字中国語 | Bob Peng, Harold Zang, Jack S | -| フランス語 | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| ドイツ語 | Rocco Gränitz, Sven Schleier (Review) | -| 日本語 | Koki Takeyama, Riotaro Okada (Review) | -| 韓国語 | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| ヒンディー語 | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| ペルシア語 | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| ポルトガル語 | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| ロシア語 | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| スペイン語 | Martin Marsicano, Carlos Holguera | -| トルコ語 | Anıl Baş, Haktan Emik | -| ギリシャ語 | Panagiotis Yialouris | - -本ドキュメントは Jim Manico により執筆された OWASP Web アプリケーションセキュリティ検証標準のフォークとして始まりました。 - -## スポンサー - -MASVS と MASTG のいずれもコミュニティにより無償奉仕で作成および維持されていますが、時にはいくらかの外的支援が必要となることもあります。したがって、テクニカルエディタを雇うことができる資金を提供したスポンサーに感謝します。彼らのスポンサーシップは MASVS や MASTG の内容にいかなる形であれ影響を与えないことに注意します。スポンサーシップパッケージは [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages") に記載されています。 - - - -最後に、[Leanpub](https://leanpub.com/mobile-security-testing-guide)からこの本を購入し私たちを支援してくれた皆様に感謝します。 diff --git a/Document-ja/0x03-Using_the_MASVS.md b/Document-ja/0x03-Using_the_MASVS.md deleted file mode 100644 index 4577541b3..000000000 --- a/Document-ja/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,83 +0,0 @@ -# モバイルアプリケーションセキュリティ検証標準 - -MASVSを使用することでモバイルアプリのセキュリティに信頼レベルを確立することができます。要件は以下の目標を念頭において開発されました。 - -- メトリックとして使用する - 開発者およびアプリケーション所有者により既存のモバイルアプリと比較できるセキュリティ標準を提供すること。 -- ガイダンスとして使用する - モバイルアプリ開発およびテストのすべてのフェーズでのガイダンスを提供すること。 -- 調達時に使用する - モバイルアプリのセキュリティ検証のベースラインを提供すること。 - -## モバイルアプリセキュリティモデル - -MASVSは2つのセキュリティ検証レベル(MASVS-L1およびMASVS-L2)と一連のリバースエンジニアリング耐性要件(MASVS-R)を定義しています。MASVS-L1 は一般的なセキュリティ要件であり、すべてのモバイルアプリに推奨されます。MASVS-L2 は機密性の高いデータを扱うアプリに適用します。MASVS-R は追加の保護コントロールを対象としています。クライアント側の脅威を防止することが設計の目標である場合に適用できます。 - -MASVS-L1 の要件を満たすことで、セキュリティベストプラクティスに従い、一般的な脆弱性に苦しむことのないセキュアなアプリケーションを実現します。MASVS-L2 は SSL ピンニングなどの追加の多層防御コントロールを加えて、より洗練された攻撃に対し耐性のあるアプリをもたらします。モバイルオペレーティングシステムのセキュリティコントロールが損なわれていないこと、およびエンドユーザーが潜在的な敵対者とみなされないことを仮定しています。MASVS-R のソフトウェア保護要件のすべてもしくは一部を満たすことは、エンドユーザーに悪意のある場合やモバイルOSが侵害された場合に、特定のクライアントサイドの脅威に対しての防御に役立ちます。 - -**I: すべてのアプリに MASVS-L1 コントロールを実装することを推奨しますが、コントロールを実装するかどうかは最終的にはリスクに基づいて決定する必要があります。その決定はビジネスオーナーとともに対話して行います。** - -**II: 注意。MASVS-R や OWASP Mobile Application Security Testing Guide に列挙されているソフトウェア保護対策は、根本的にバイパスできないわけではありません。それで、種々のセキュリティコントロールの代用として使用すべきではありません。むしろ、MASVS-L1 もしくは MASVS-L2 として示した MASVS 要件をも満たす、脅威に対応した、適切なソフトウェア保護対策を施してください。** - -![Verification Levels](images/masvs-levels-new.jpg) - -### ドキュメントの構成 - -MASVS の最初のパートには、セキュリティモデルおよび利用可能な検証レベルの説明と、実際に標準の使用方法に関する推奨事項が含まれます。次のパートには、詳細なセキュリティ要件と検証レベルへのマッピングが記載されています。要件は技術的な目的／スコープに基づいて8つのカテゴリ (V1～V8) に分類されています。MASVS および MASTG 全体で以下の命名法が使用されています。 - -- *要件カテゴリ:* MASVS-Vx, 例. MASVS-V2: データストレージとプライバシー -- *要件:* MASVS-Vx.y, 例. MASVS-V2.2: 「機密データがアプリケーションログに書き込まれていない。」 - -### 検証レベルの詳細 - -#### MASVS-L1: 標準セキュリティ - -MASVS-L1 を実現するモバイルアプリはモバイルアプリケーションセキュリティのベストプラクティスに準拠しています。コード品質、機密データの取り扱い、モバイル環境との連携に関して基本的な要件を満たしています。セキュリティコントロールを検証するにはテストプロセスを実行する必要があります。このレベルはすべてのモバイルアプリケーションに適しています。 - -#### MASVS-L2: 多層防御 - -MASVS-L2 は標準要件を超える高度なセキュリティコントロールを導入します。MASVS-L2 を満たすためには、脅威モデルが存在する必要があり、セキュリティはアプリのアーキテクチャおよび設計の不可欠な部分である必要があります。脅威モデルに基づいて、適切な MASVS-L2 コントロールが選択され、正しく実装されているはずです。このレベルはモバイルバンキングアプリなどの機密性の高いデータを処理するアプリに適しています。 - -#### MASVS-R: リバースエンジニアリングと改竄への耐性 - -このアプリは最高水準のセキュリティを備えており、機密コードやデータを抽出するための改竄、改造、リバースエンジニアリングなどの特定の明確に定義されたクライアントサイドの攻撃に対しても耐性があります。このようなアプリはハードウェアのセキュリティ機能や十分に強力で検証可能なソフトウェア保護技術を活用しています。MASVS-R は機密性の高いデータを扱うアプリに適用され、知的財産を保護し、アプリの改竄を防止する手段となります。 - -### 推奨される使い方 - -アプリは事前のリスクアセスメントや要求される全体のセキュリティレベルに応じて MASVS L1 もしくは L2 に沿って検証できます。L1 はすべてのモバイルアプリに適用され、L2 は一般的により機密性の高いデータや機能を扱うアプリに推奨されます。MASVS-R（もしくはその一部）は適切なセキュリティ検証に *追加する* ことで、再パッケージ化や機密データの抽出などの特定の脅威に対する耐性を検証することができます。 - -要約すると、以下の検証タイプが利用できます。 - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -それぞれの組み合わせには異なるグレードのセキュリティと耐性が反映されています。その目的は柔軟性を確保することです。例えば、モバイルゲームにはユーザビリティ上の理由から二要素認証などの MASVS-L2 セキュリティコントロールを加えることは容認されないかもしれませんが、改竄防止のための強いビジネスニーズがあります。 - -#### どの検証タイプを選択するか - -MASVS L2 の要件を実装することでセキュリティが向上すると同時に、開発コストが増加し、エンドユーザーエクスペリエンスが悪化する可能性があります（典型的なトレードオフです）。一般的に、L2 はリスク対コストの観点から意味がある場合のアプリに使用すべきです（つまり、妥協した機密性もしくは完全性により引き起こされる潜在的な損失が追加のセキュリティコントロールによりもたらされるコストより高い場合）。リスクアセスメントは MASVS を適用する前の最初のステップであるべきです。 - -##### 事例 - -###### MASVS-L1 - -- すべてのモバイルアプリ。MASVS-L1 には開発コストとユーザーエクスペリエンスに妥当な影響を与えるセキュリティのベストプラクティスを掲載しています。より高いレベルのものに該当しないアプリには MASVS-L1 の要件を適用します。 - -###### MASVS-L2 - -- ヘルスケア業界：なりすまし犯罪や不正支払などのさまざまな犯罪行為に使用される個人識別情報を保管するモバイルアプリ。米国のヘルスケア分野では、医療保険の相互運用性と説明責任に関する法律 (HIPPA) のプライバシー、セキュリティ、侵害開示に関する規則、患者の安全性に関する規則があります。 - -- 金融業界：クレジットカード番号、個人情報などの機密性の高い情報にアクセスできたり、ユーザーが送金できるアプリ。これらのアプリは詐欺を防止するための追加のセキュリティコントロールを必要とします。金融アプリはPCIデータセキュリティスタンダード (PCIDSS)、グラム・リーチ・ブライリー法、サーベンス・オクスリー (SOX) 法に準拠する必要があります。 - -###### MASVS-L1+R - -- 知的財産 (IP) 保護がビジネスゴールであるモバイルアプリ。MASVS-R に掲載されている耐性コントロールは元のソースコードを取得するのに必要な作業を増やし、改竄／クラッキングを防止するために使用できます。 - -- ゲーム業界：競争の激しいオンラインゲームなど、改造やチート行為を防止することが必要不可欠なゲーム。チート行為はオンラインゲームでの重要な問題です。大量のチート行為者がプレイヤーの不満を招き、最終的にはゲームが失敗となる可能性があります。MASVS-R はチート行為者への負担を増やすために基本的な耐タンパ性コントロールを提供します。 - -###### MASVS-L2+R - -- 金融業界：ユーザーが送金できるオンラインバンキングアプリ。侵入したデバイスでのコードインジェクションやインストルメンテーションなどの技術によるリスクをもたらします。この場合、MASVS-R のコントロールを使用して改竄を防ぐことで、マルウェア作成者のハードルを上げることができます。 - -- 設計上、モバイルデバイス上に機密データを保存する必要があると同時に幅広いデバイスやオペレーティングシステムのバージョンをサポートしなければならないすべてのモバイルアプリ。この場合、機密データを抽出することを目指す攻撃者の負担を増やすために多層防御策として耐性コントロールを使用することができます。 - -- アプリ内購入のあるアプリでは有料コンテンツを保護するためにサーバー側コントロールと MASVS-L2 コントロールを使用するのが理想的です。但し、サーバー側保護を使用できない場合があります。このような場合、リバースや改竄の労力を増やすために MASVS-R コントロールをさらに適用する必要があります。 diff --git a/Document-ja/0x04-Assessment_and_Certification.md b/Document-ja/0x04-Assessment_and_Certification.md deleted file mode 100644 index 2972d4cc7..000000000 --- a/Document-ja/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# 監査と認定 - -## MASVS 認定と認証マークに対する OWASP の見解 - -OWASP はベンダー中立の非営利組織であり、ベンダー、検証者、ソフトウェアの認定は行っていません。 - -そのような保証の表明、認証マーク、認定はいずれも OWASP によって公式に検査、登録、認定されたものではありません。組織は (M)ASVS 認定を主張する第三者や認証マークについて、その信頼性を慎重に検討する必要があります。 - -ただし、OWASP の公式な認定であると主張しない限り、組織がこのような保証サービスを提供することを妨げるものではありません。 - -## モバイルアプリの認定に関するガイダンス - -モバイルアプリの MASVS への準拠を検証するために推奨される方法は「オープンブック」レビューを実行することです。つまり、アプリの設計者や開発者、プロジェクト文書、ソースコード、役割ごとに少なくともひとつのユーザーアカウントへのアクセスを含むエンドポイントへの認証されたアクセスといった、主要リソースへのアクセス権限をテスト技術者に割り当てることです。 - -MASVS は（クライアント側の）モバイルアプリと、アプリとそのリモートエンドポイント間のネットワーク通信のセキュリティを対象とすることに注意することが重要です。また、ユーザー認証とセッション管理に関連するいくつかの基本的かつ一般的な要件も対象とします。アプリに関連付けられた（Webサービスなどの）リモートサービスに対して特定の要件は含まれていません。認証およびセッション管理に関連する限られた一般的要件に対して安全です。ただし、MASVS V1 ではリモートサービスを全体的な脅威モデルでカバーし、OWASP ASVS などの適切な標準に沿って検証する必要があることを明記しています。 - -認定機関は、（特に重要な構成要素が範囲外である場合）検証の範囲、合格したテストと不合格のテストを含む検証結果の要約、不合格のテストへの解決法の明確な指示をレポートに含める必要があります。詳細な調書、スクリーンショットやムービー、問題を確実かつ繰り返し利用するためのスクリプト、傍受したプロキシログなどのテストの電子記録、クリーンアップリストなどの関連メモを保持することは標準的な業界の慣行と考えられます。ツールを実行して不合格を報告するだけでは不十分です。認定レベルのすべての問題がテストされ、余すところなくテストされている十分な証跡を提供していません。係争の場合には、すべての検証要件が実際にテストされたことを実証するのに十分な証跡が必要となります。 - -### OWASP モバイルセキュリティテストガイド (MASTG) を使用する - -OWASP MASTG はモバイルアプリのセキュリティをテストするためのマニュアルです。MASVS に記載されている要件を検証するための技術的プロセスを記述しています。MASTG には MASVS のそれぞれの要件に対応するテストケースのリストが含まれています。MASVS の要件は高レベルで汎用的ですが、MASTG はモバイル OS ごとに詳細な推奨案とテスト手順を提供しています。 - -### 自動セキュリティテストツールの役割 - -可能な限り効率を上げるためにソースコードスキャナやブラックボックステストツールの使用が奨励されています。ただし、自動ツールのみを使用して MASVS 検証を完了することはできません。モバイルアプリはさまざまであり、全体的なアーキテクチャ、ビジネスロジック、使用されている特定のテクノロジーやフレームワークの技術的な落とし穴を理解することはアプリのセキュリティを検証するために必須の要件であるためです。 - -## その他の用途 - -### 詳細なセキュリティアーキテクチャガイダンスとして - -モバイルアプリケーションセキュリティ検証標準のより一般的な用途のひとつはセキュリティアーキテクトのためのリソースとするものです。二つの主要なセキュリティアーキテクチャフレームワーク SABSA と TOGAF にはモバイルアプリケーションセキュリティアーキテクチャのレビューを完了するために必要な多くの情報がありません。MASVS を使用すると、セキュリティアーキテクトがモバイルアプリに共通する問題のコントロールを強化できるようになり、ギャップを埋めることができます。 - -### 既製のセキュアコーディングチェックリストの代替として - -多くの組織は MASVS を採用することにより利益を得ることができます。2つのレベルのいずれかを選択するか、MASVS をフォークし、それぞれのアプリケーションのリスクレベルに必要なものをドメイン固有の方法に変更します。このタイプのフォークはトレーサビリティが維持されている限りにおいて奨励されています。したがって、アプリが要件 4.1 を満たしていれば、標準の派生としてフォークされたコピーにおいても同様であることを意味します。 - -### セキュリティテスト手法の基礎として - -優れたモバイルアプリのセキュリティテスト手法は MASVS に記載されているすべての要件をカバーする必要があります。OWASP モバイルセキュリティテストガイド (MASTG) では検証要件ごとにブラックボックスとホワイトボックスのテストケースについて説明しています。 - -### 自動単体テストと自動統合テストのガイドとして - -MASVS はアーキテクチャ上の要件を除いて高度にテスト可能であるよう設計されています。MASVS の要件に基づいて自動化された単体、統合、受け入れテストは継続的な開発ライフサイクルに統合することができます。これにより開発者のセキュリティ意識が向上するだけでなく、結果としてアプリの全体的な品質が向上し、プレリリースのフェーズでのセキュリティテストの検証量が減少します。 - -### セキュア開発トレーニング用に - -MASVS はセキュアなモバイルアプリの特性を定義するためにも使用できます。多くの「セキュアコーディング」コースは単にコーディングのヒントを少し示すだけの倫理的ハッキングコースにすぎません。これは開発者の助けにはなりません。代わりとして、セキュア開発コースは MASVS を使用できます。トップ 10 コードセキュリティ問題などよりも、MASVS に記載されているプロアクティブなコントロールに強く焦点を当てます。 diff --git a/Document-ja/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-ja/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index c109ea4f4..000000000 --- a/Document-ja/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: アーキテクチャ, 設計, 脅威モデリング要件 - -## 管理目標 - -理想的な世界では、セキュリティは開発の全てのフェーズを通して考慮されることでしょう。しかし実際には、SDLCの後ろのステージでのみセキュリティは考慮されます。技術的なコントロールのほかに、MASVSではセキュリティが明示的に計画フェーズ中に割り当てられ、すべてのコンポーネントについて機能やセキュリティの役割が明確であることを保証する所定のプロセスを要求します。ほとんどのモバイルアプリはリモートサービスのクライアントとして動作しますので、適切なセキュリティ基準がそれらのサービスに適用されることも保証しなければいけません。モバイルアプリをテストするだけでは不十分です。 - -カテゴリ「V1」にはアプリのアーキテクチャと設計に関する要件が記載されています。したがって、これは OWASP モバイルテストガイドの技術的なテストケースに対応していない唯一のカテゴリです。脅威モデル、セキュア SDLC、鍵管理などのトピックをカバーするには、MASVS のユーザーはそれぞれの OWASP プロジェクトや以下にリンクされているような他の標準を参照する必要があります。 - -## セキュリティ検証要件 - -MASVS-L1 および MASVS-L2 の要件を以下に記します。 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | アプリのすべてのコンポーネントを把握し、それらが必要とされている。 | x | x | -| **1.2** | MSTG-ARCH-2 | セキュリティコントロールはクライアント側だけではなくそれぞれのリモートエンドポイントで実施されている。 | x | x | -| **1.3** | MSTG-ARCH-3 | モバイルアプリと接続されるすべてのリモートサービスの高次のアーキテクチャが定義され、そのアーキテクチャにセキュリティが対応されている。 | x | x | -| **1.4** | MSTG-ARCH-4 | モバイルアプリのコンテキストで機密とみなされるデータが明確に特定されている。 | x | x | -| **1.5** | MSTG-ARCH-5 | アプリのすべてのコンポーネントは提供する業務上の機能やセキュリティ上の機能の観点で定義されている。 | | x | -| **1.6** | MSTG-ARCH-6 | モバイルアプリとそれに関連するリモートサービスの脅威モデルが作られ、潜在的な脅威と対策を特定している。 | | x | -| **1.7** | MSTG-ARCH-7 | すべてのセキュリティコントロールは集約実装されている。 | | x | -| **1.8** | MSTG-ARCH-8 | 暗号鍵が（もしあれば）どのように管理されるかについての明確な方針があり、暗号鍵のライフサイクルが施行されている。 NIST SP 800-57 などの鍵管理標準に準拠することが理想的である。 | | x | -| **1.9** | MSTG-ARCH-9 | モバイルアプリの更新を強制するメカニズムが存在している。 | | x | -| **1.10** | MSTG-ARCH-10 | セキュリティはソフトウェア開発ライフサイクルのあらゆる部分で対処されている。 | | x | -| **1.11** | MSTG-ARCH-11 | 責任ある開示ポリシーを用意しており、効果的に適用している。 | | x | -| **1.12** | MSTG-ARCH-12 | アプリはプライバシーに関する法律および規制に準拠している。 | x | x | - -## 参考情報 - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-ja/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-ja/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index fc43da174..000000000 --- a/Document-ja/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: データストレージとプライバシー要件 - -## 管理目標 - -ユーザー資格情報や個人情報などの機密データの保護はモバイルセキュリティで重要な焦点となっています。まず、IPCのようなオペレーティングシステムのメカニズムが不適切に使用されている場合、同じデバイス上で実行されている他のアプリに機密データが意図せず晒されてしまいます。また、データはクラウドストレージ、バックアップ、キーボードキャッシュから意図せず漏れることもあります。さらに、他のタイプのデバイスに比べてモバイルデバイスは簡単に紛失したり盗まれたりします。そのため、第三者が物理的にアクセスできることがより可能性の高いシナリオとなります。その場合、機密データの取得をより困難にするために追加の保護を実装することができます。 - -注意：MASVS はアプリ中心であるため、MDM ソリューションにより行われるようなデバイスレベルのポリシーは対象ではありません。私たちはエンタープライズのコンテキストでこのようなポリシーを使用することにより、データセキュリティをさらに強化することを推奨します。 - -### 機密データの定義 - -MASVS のコンテキストにおける機密データは、以下のように、ユーザー資格情報および特定のコンテキストにおいて機密とみなされるその他のデータの両方に関係します。 - -- なりすまし犯罪に悪用される可能性のある個人識別情報 (PII)：社会保障番号、クレジットカード番号、銀行口座番号、医療情報。 -- 被害を受けた場合に風評被害や財務コストにつながる機密性の高いデータ：契約情報、秘密保持契約の対象となる情報、管理情報。 -- 法律やコンプライアンス上の理由により保護する必要のあるすべてのデータ。 - -## セキュリティ検証要件 - -大部分のデータ開示の問題は単純なルールに従うことで防ぐことが可能です。この章に記載されているほとんどのコントロールはすべての検証レベルで必須です。 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | 個人識別情報、ユーザー資格情報、暗号化鍵などの機密データを格納するために、システムの資格情報保存機能を使用している。 | x | x | -| **2.2** | MSTG-STORAGE-2 | 機密データはアプリコンテナまたはシステムの資格情報保存機能の外部に保存されていない。 | x | x | -| **2.3** | MSTG-STORAGE-3 | 機密データはアプリケーションログに書き込まれていない。 | x | x | -| **2.4** | MSTG-STORAGE-4 | 機密データはアーキテクチャに必要な部分でない限りサードパーティと共有されていない。 | x | x | -| **2.5** | MSTG-STORAGE-5 | 機密データを処理するテキスト入力では、キーボードキャッシュが無効にされている。 | x | x | -| **2.6** | MSTG-STORAGE-6 | 機密データはIPCメカニズムを介して公開されていない。 | x | x | -| **2.7** | MSTG-STORAGE-7 | パスワードやピンなどの機密データは、ユーザーインタフェースを介して公開されていない。 | x | x | -| **2.8** | MSTG-STORAGE-8 | 機密データはモバイルオペレーティングシステムにより生成されるバックアップに含まれていない。 | | x | -| **2.9** | MSTG-STORAGE-9 | バックグラウンドへ移動した際にアプリはビューから機密データを削除している。 | | x | -| **2.10** | MSTG-STORAGE-10 | アプリは必要以上に長くメモリ内に機密データを保持せず、使用後は明示的にメモリがクリアされている。 | | x | -| **2.11** | MSTG-STORAGE-11 | アプリは最低限のデバイスアクセスセキュリティポリシーを適用しており、ユーザーにデバイスパスコードを設定することなどを必要としている。 | | x | -| **2.12** | MSTG-STORAGE-12 | アプリは処理される個人識別情報の種類をユーザーに通知しており、同様にユーザーがアプリを使用する際に従うべきセキュリティのベストプラクティスについて通知している。 | x | x | -| **2.13** | MSTG-STORAGE-13 | 機密データをモバイルデバイス上のローカルに保存していない。代わりに、必要な時にリモートエンドポイントからデータを取得し、メモリ内にのみ保持している。 | | x | -| **2.14** | MSTG-STORAGE-14 | 機密データをローカルに保存する必要がある場合には、認証が必要なハードウェア支援ストレージから取得した鍵を使用して暗号化している。 | | x | -| **2.15** | MSTG-STORAGE-15 | 認証の試行が過度の回数にわたり失敗した後には、アプリのローカルストレージを消去している。 | | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-ja/0x08-V3-Cryptography_Verification_Requirements.md b/Document-ja/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index d500401e0..000000000 --- a/Document-ja/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: 暗号化要件 - -## 管理目標 - -モバイルデバイスに保存されるデータを保護するには暗号化が重要な要素となります。特に標準的な規則に従わない場合、物事が恐ろしく誤った方向に進んでしまうカテゴリでもあります。検証されたアプリケーションが下記のような業界のベストプラクティスに従って暗号化を使用することを確認することがこの章のコントロールの目的です。 - -- 実績のある暗号化ライブラリの使用 -- 暗号化プリミティブの適切な選択と構成 -- 無作為性が必要とされる箇所での適切な乱数生成器 - -## セキュリティ検証要件 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | アプリは暗号化の唯一の方法としてハードコードされた鍵による対称暗号化に依存していない。 | x | x | -| **3.2** | MSTG-CRYPTO-2 | アプリは実績のある暗号化プリミティブの実装を使用している。 | x | x | -| **3.3** | MSTG-CRYPTO-3 | アプリは特定のユースケースに適した暗号化プリミティブを使用している。業界のベストプラクティスに基づくパラメータで構成されている。 | x | x | -| **3.4** | MSTG-CRYPTO-4 | アプリはセキュリティ上の目的で広く非推奨と考えられる暗号プロトコルやアルゴリズムを使用していない。 | x | x | -| **3.5** | MSTG-CRYPTO-5 | アプリは複数の目的のために同じ暗号化鍵を再利用していない。 | x | x | -| **3.6** | MSTG-CRYPTO-6 | すべての乱数値は十分にセキュアな乱数生成器を用いて生成されている。 | x | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-ja/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-ja/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 16b310897..000000000 --- a/Document-ja/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: 認証とセッション管理要件 - -## 管理目標 - -多くの場合、リモートサービスへのユーザーログインはモバイルアプリアーキテクチャ全体の不可欠な要素です。ロジックの大半はエンドポイントで発生しますが、MASVSではユーザーアカウントとセッションの管理方法に関するいくつかの基本的な要件を定義します。 - -## セキュリティ検証要件 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | アプリがユーザーにリモートサービスへのアクセスを提供する場合、ユーザー名/パスワード認証など何らかの形態の認証がリモートエンドポイントで実行されている。 | x | x | -| **4.2** | MSTG-AUTH-2 | ステートフルなセッション管理を使用する場合、リモートエンドポイントはランダムに生成されたセッション識別子を使用し、ユーザーの資格情報を送信せずにクライアントリクエストを認証している。 | x | x | -| **4.3** | MSTG-AUTH-3 | ステートレスなトークンベースの認証を使用する場合、サーバーはセキュアなアルゴリズムを使用して署名されたトークンを提供している。 | x | x | -| **4.4** | MSTG-AUTH-4 | ユーザーがログアウトする際に、リモートエンドポイントは既存のセッションを終了している。 | x | x | -| **4.5** | MSTG-AUTH-5 | パスワードポリシーが存在し、リモートエンドポイントで実施されている。 | x | x | -| **4.6** | MSTG-AUTH-6 | リモートエンドポイントは過度な資格情報の送信に対する保護を実装している。 | x | x | -| **4.7** | MSTG-AUTH-7 | 事前に定義された非アクティブ期間およびアクセストークンの有効期限が切れた後に、セッションはリモートエンドポイントで無効にしている。 | x | x | -| **4.8** | MSTG-AUTH-8 | 生体認証が使用される場合は（単に「true」や「false」を返すAPIを使うなどの）イベントバインディングは使用しない。代わりに、キーチェーンやキーストアのアンロックに基づいている。 | | x | -| **4.9** | MSTG-AUTH-9 | リモートエンドポイントに二要素認証が存在し、リモートエンドポイントで二要素認証要件が一貫して適用されている。 | | x | -| **4.10** | MSTG-AUTH-10 | 機密トランザクションはステップアップ認証を必要としている。 | | x | -| **4.11** | MSTG-AUTH-11 | アプリはユーザーのアカウントでのすべての機密アクティビティをユーザーに通知している。ユーザーはデバイスの一覧を表示したり、コンテキスト情報 (IP アドレス、位置情報など) を表示したり、特定のデバイスをブロックすることができる。 | | x | -| **4.12** | MSTG-AUTH-12 | 認可モデルはリモートエンドポイントで定義および実施されている。 | x | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-ja/0x10-V5-Network_communication_requirements.md b/Document-ja/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 7d9f911c0..000000000 --- a/Document-ja/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: ネットワーク通信要件 - -## 管理目標 - -モバイルアプリとリモートサービスのエンドポイント間で交換される情報の機密性と完全性を確認することがこのセクションで説明されるコントロールの目的です。少なくとも、モバイルアプリは適切な設定でのTLSプロトコルを使用したネットワーク通信のために、セキュアで暗号化されたチャネルを設定する必要があります。レベル2には SSL ピンニングなどの追加の多層防御施策があります。 - -## セキュリティ検証要件 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | データはネットワーク上でTLSを使用して暗号化されている。セキュアチャネルがアプリ全体を通して一貫して使用されている。 | x | x | -| **5.2** | MSTG-NETWORK-2 | TLS 設定は現在のベストプラクティスと一致している。モバイルオペレーティングシステムが推奨される標準規格をサポートしていない場合には可能な限り近い状態である。 | x | x | -| **5.3** | MSTG-NETWORK-3 | セキュアチャネルが確立されたときに、アプリはリモートエンドポイントのX.509証明書を検証している。信頼されたCAにより署名された証明書のみが受け入れられている。 | x | x | -| **5.4** | MSTG-NETWORK-4 | アプリは自身の証明書ストアを使用するか、エンドポイント証明書もしくは公開鍵をピンニングしている。信頼されたCAにより署名された場合でも、別の証明書や鍵を提供するエンドポイントとの接続を確立していない。 | | x | -| **5.5** | MSTG-NETWORK-5 | アプリは登録やアカウントリカバリーなどの重要な操作において（電子メールやSMSなどの）単方向のセキュアでない通信チャネルに依存していない。 | | x | -| **5.6** | MSTG-NETWORK-6 | アプリは最新の接続ライブラリとセキュリティライブラリにのみ依存している。 | | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-ja/0x11-V6-Interaction_with_the_environment.md b/Document-ja/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 017951e3a..000000000 --- a/Document-ja/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: プラットフォーム連携要件 - -## 管理目標 - -アプリがセキュアな方法でプラットフォームAPIや標準コンポーネントを使用していることをこのグループのコントロールは確認します。また、コントロールはアプリ間通信(IPC)も扱います。 - -## セキュリティ検証要件 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | アプリは必要となる最低限のパーミッションのみを要求している。 | x | x | -| **6.2** | MSTG-PLATFORM-2 | 外部ソースおよびユーザーからの入力はすべて検証されており、必要に応じてサニタイズされている。これにはUI、インテントやカスタムURLなどのIPCメカニズム、ネットワークソースを介して受信したデータを含んでいる。 | x | x | -| **6.3** | MSTG-PLATFORM-3 | アプリはメカニズムが適切に保護されていない限り、カスタムURLスキームを介して機密な機能をエクスポートしていない。 | x | x | -| **6.4** | MSTG-PLATFORM-4 | アプリはメカニズムが適切に保護されていない限り、IPC機構を通じて機密な機能をエクスポートしていない。 | x | x | -| **6.5** | MSTG-PLATFORM-5 | 明示的に必要でない限りWebViewでJavaScriptが無効化されている。 | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebViewは最低限必要のプロトコルハンドラのセットのみを許可するよう構成されている（理想的には、httpsのみがサポートされている）。file, tel, app-id などの潜在的に危険なハンドラは無効化されている。 | x | x | -| **6.7** | MSTG-PLATFORM-7 | アプリのネイティブメソッドがWebViewに公開されている場合、WebViewはアプリパッケージ内に含まれるJavaScriptのみをレンダリングしている。 | x | x | -| **6.8** | MSTG-PLATFORM-8 | オブジェクトのデシリアライゼーションは、もしあれば、安全なシリアライゼーションAPIを使用して実装されている。 | x | x | -| **6.9** | MSTG-PLATFORM-9 | アプリはスクリーンオーバーレイ攻撃から自らを保護している。 (Android のみ) | | x | -| **6.10** | MSTG-PLATFORM-10 | WebViewを破棄する前にWebViewのキャッシュ、ストレージ、ロードされたリソース (JavaScript など) をクリアしている。 | | x | -| **6.11** | MSTG-PLATFORM-11 | 機密データを入力する場合は常に、アプリはカスタムサードパーティキーボードを使用できないようにしている。(iOS のみ) | | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-ja/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-ja/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 77cde7cc6..000000000 --- a/Document-ja/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: コード品質とビルド設定要件 - -## 管理目標 - -アプリの開発で基本的なセキュリティコーディングプラクティスに従っており、コンパイラが提供する「フリー」のセキュリティ機能が有効になっていることを確認することがこのコントロールの目標です。 - -## セキュリティ検証要件 - -| # | MSTG-ID | 説明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | アプリは有効な証明書で署名およびプロビジョニングされている。その秘密鍵は適切に保護されている。 | x | x | -| **7.2** | MSTG-CODE-2 | アプリはリリースモードでビルドされている。リリースビルドに適した設定である（デバッグ不可など）。 | x | x | -| **7.3** | MSTG-CODE-3 | デバッグシンボルはネイティブバイナリから削除されている。 | x | x | -| **7.4** | MSTG-CODE-4 | デバッグコードおよび開発者支援コード (テストコード、バックドア、隠し設定など) は削除されている。アプリは詳細なエラーやデバッグメッセージをログ出力していない。 | x | x | -| **7.5** | MSTG-CODE-5 | モバイルアプリで使用されるライブラリ、フレームワークなどのすべてのサードパーティコンポーネントを把握し、既知の脆弱性を確認している。 | x | x | -| **7.6** | MSTG-CODE-6 | アプリは可能性のある例外をキャッチし処理している。 | x | x | -| **7.7** | MSTG-CODE-7 | セキュリティコントロールのエラー処理ロジックはデフォルトでアクセスを拒否している。 | x | x | -| **7.8** | MSTG-CODE-8 | アンマネージドコードでは、メモリはセキュアに割り当て、解放、使用されている。 | x | x | -| **7.9** | MSTG-CODE-9 | バイトコードの軽量化、スタック保護、PIEサポート、自動参照カウントなどツールチェーンにより提供されるフリーのセキュリティ機能が有効化されている。 | x | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、上記の要件を検証するための詳細な手順を提供しています。 - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-ja/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-ja/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 80a92b93e..000000000 --- a/Document-ja/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V8: 耐性要件 - -## 管理目標 - -このセクションでは、機密データや機能を処理したりアクセスを与えたりするアプリに推奨される多層防御施策を取り扱います。これらのコントロールのいずれかが欠如しても脆弱性を引き起こすことはありません。代わりに、リバースエンジニアリングや特定のクライアントサイド攻撃に対する耐性を高めることを意図しています。 - -このセクションのコントロールは、アプリの不正改竄やコードのリバースエンジニアリングにより引き起こされるリスクのアセスメントに基づいて、必要に応じて適用する必要があります。ビジネスリスクと依存する技術的脅威にはOWASPドキュメント "Technical Risks of Reverse Engineering and Unauthorized Code Modification", "Reverse Engineering and Code Modification Prevention" （下記の参考情報を参照）を参考にすることをお勧めします。 - -**ソフトウェア保護はセキュリティコントロールの代わりに使用してはならないことに注意してください。MASVS-Rにリストされているコントロールは、MASVSセキュリティ要件を満たしているアプリに、脅威に特化した追加の保護コントロールを追加することを意図しています。** - -以下の考慮事項が適用されます。 - -1. 防御されるクライアント側の脅威を明確に説明する脅威モデルを定義する必要があります。さらに、そのスキームが提供することを意図している保護グレードを明示している必要があります。例えば、明示された目標にはアプリをインストルメンテーションしようとする標的マルウェアの作者にかなりの手動リバースエンジニアリングの労力を注ぐよう強制することです。 - -2. 脅威モデルは合理的である必要があります。例えば、ホワイトボックス実装で暗号化鍵を隠すことは、攻撃者がホワイトボックス全体を単純にコードリフトできる場合、的外れです。 - -3. 保護の有効性は使用される特定のタイプの耐タンパ性および難読化のテストの経験を有する人間の専門家によって常に検証される必要があります（モバイルセキュリティテストガイドの「リバースエンジニアリング」および「ソフトウェア保護の評価」の章も参照してください）。 - -### 動的解析と改竄の阻止 - -| # | MSTG-ID | 説明 | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | アプリはユーザーに警告するかアプリを終了することでルート化デバイスや脱獄済みデバイスの存在を検知し応答している。 | x | -| **8.2** | MSTG-RESILIENCE-2 | アプリはデバッグを防止し、デバッガのアタッチを検知し応答している。利用可能なすべてのデバッグプロトコルを網羅している必要がある。 | x | -| **8.3** | MSTG-RESILIENCE-3 | アプリはそれ自身のサンドボックス内の実行ファイルや重要なデータの改竄を検知し応答している。 | x | -| **8.4** | MSTG-RESILIENCE-4 | アプリはそのデバイスで広く使用されるリバースエンジニアリングツールやフレームワークの存在を検知し応答している。 | x | -| **8.5** | MSTG-RESILIENCE-5 | アプリは任意の方法を使用してエミュレータ内で動作しているかどうかを検知し応答している。 | x | -| **8.6** | MSTG-RESILIENCE-6 | アプリはそれ自身のメモリ空間内のコードとデータの改竄を検知し応答している。 | x | -| **8.7** | MSTG-RESILIENCE-7 | アプリは各防御カテゴリ(8.1から8.6)で複数のメカニズムを実装している。耐性は使用されるメカニズムのオリジナリティの量、多様性と比例することに注意する。 | x | -| **8.8** | MSTG-RESILIENCE-8 | 検知メカニズムは遅延応答やステルス応答を含むさまざまな種類の応答をトリガーしている。 | x | -| **8.9** | MSTG-RESILIENCE-9 | 難読化はプログラムの防御に適用されており、動的解析による逆難読化を妨げている。 | x | - -### デバイスバインディング - -| # | MSTG-ID | 説明 | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | アプリはデバイスに固有の複数のプロパティから由来するデバイスフィンガープリントを使用して「デバイスバインディング」機能を実装している。 | x | - -### 理解の阻止 - -| # | MSTG-ID | 説明 | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | アプリに属するすべての実行可能ファイルとライブラリはファイルレベルで暗号化されているか、実行可能ファイル内の重要なコードやデータセグメントが暗号化またはパック化されている。簡単な静的解析では重要なコードやデータは明らかにならない。 | x | -| **8.12** | MSTG-RESILIENCE-12 | 難読化の目的が機密性の高い計算を保護することである場合、現在公開されている研究を考慮して、特定のタスクに適しており手動および自動の逆難読化メソッドに対して堅牢な難読化スキームを使用している。難読化スキームの有効性は手動テストにより検証する必要がある。可能であればハードウェアベースの隔離機能が難読化より優先されることに注意する。 | x | - -### 盗聴防止 - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | 多層防御として、通信相手の堅牢化に加えて、アプリケーションレベルのペイロード暗号化を適用して、盗聴をより一層防止している。 | x | - -## 参考情報 - -OWASP モバイルセキュリティテストガイドでは、このセクションに記載されている要件を検証するための詳細な手順を提供しています。 - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -詳しくは以下の情報を参照してください。 - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-ja/0x90-Appendix-A_Glossary.md b/Document-ja/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 2b9bbca49..000000000 --- a/Document-ja/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# 付録 A: 用語集 - -- **アドレス空間配置のランダム化 (Address Space Layout Randomization, ASLR)** – メモリ破壊バグの悪用をより困難にする手法です。 -- **アプリケーションセキュリティ (Application Security)** – アプリケーションレベルのセキュリティは基礎となるオペレーティングシステムや接続されるネットワークにフォーカスするのではなく、開放型システム間相互接続参照モデル（OSIモデル）のアプリケーション層を構成するコンポーネントの分析にフォーカスします。 -- **アプリケーションセキュリティ検証 (Application Security Verification)** – OWASP ASVS に対するアプリケーションの技術的評価です。 -- **アプリケーションセキュリティ検証報告書 (Application Security Verification Report)** – 対象とするアプリケーションの検証者が作成した全体的な結果と分析をまとめた報告書です。 -- **認証 (Authentication)** – アプリケーションのユーザーの申請IDを検証します。 -- **自動検証 (Automated Verification)** – 脆弱性シグネチャを使用して問題を発見する自動ツール（動的分析ツール、静的解析ツール、のいずれかもしくはその両方）を使用する検証です。 -- **ブラックボックステスト (Black Box Testing)** – アプリケーションの機能を内部構造や動作に頼らすに検査するソフトウェアテストの手法です。 -- **コンポーネント (Component)** – 自己完結型のコード単位です。他のコンポーネントと通信するディスクやネットワークに関連するインタフェースを持ちます。 -- **クロスサイトスクリプティング (Cross-Site Scripting, XSS)** – クライアント側のスクリプトをコンテンツに流入することを可能にする、Webアプリケーションで典型的に見られるセキュリティ脆弱性です。 -- **暗号モジュール (Cryptographic Module)** – 暗号アルゴリズムを実装し、暗号鍵を生成するハードウェア、ソフトウェア、ファームウェアです。 -- **CWE** – CWE はコミュニティにより開発された一般的なソフトウェアセキュリティ脆弱性のリストです。これは共通言語、ソフトウェアセキュリティツールのものさし、および脆弱性識別、緩和、予防のためのベースラインとして機能します。 -- **動的アプリケーションセキュリティテスト (Dynamic Application Security Testing, DAST)** – 実行状態のアプリケーションのセキュリティ脆弱性を示す条件を検出するように設計されたテスト技法です。 -- **設計検証 (Design Verification)** – アプリケーションのセキュリティアーキテクチャの技術的評価です。 -- **動的検証 (Dynamic Verification)** – 脆弱性シグネチャを使用してアプリケーションの実行中に問題を発見する自動ツールを使用する検証です。 -- **グローバル一意識別子 (Globally Unique Identifier, GUID)** – ソフトウェアで識別子として使用される一意の参照番号です。 -- **ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol, HTTP)** – 分散、協調、ハイパーメディア情報システムのためのアプリケーションプロトコルです。World Wide Web のためのデータ通信の基盤です。 -- **ハードコードされた鍵 (Hardcoded Keys)** – デバイス自体に格納されている暗号鍵です。 -- **プロセス間通信 (Inter Process Communications, IPC)** – プロセスが他のプロセスやカーネルと調和して活動するための通信です。 -- **入力検証 (Input Validation)** – 信頼できないユーザー入力の正規化および妥当性確認です。 -- **JAVA バイトコード (JAVA Bytecode)** – Java 仮想マシン (JVM) の命令セットです。各バイトコードは、命令（オペコード）をあらわす1バイトもしくは場合によっては2バイトと、パラメータを渡すための0バイト以上で構成されます。 -- **悪性コード (Malicious Code)** – 開発中にアプリケーションに導入された、アプリケーションの意図されたセキュリティポリシーを迂回する、アプリケーションの所有者に知られていないコードです。ウイルスやワームなどのマルウェアと同じではありません。 -- **マルウェア (Malware)** – アプリケーションユーザーや管理者の知識なしに実行時にアプリケーションに導入される実行可能コードです。 -- **Open Web Application Security Project (OWASP)** – アプリケーションソフトウェアのセキュリティを強化することにフォーカスする世界規模のフリーでオープンなコミュニティーです。私たちの使命はアプリケーションのセキュリティを「可視化」することで、人々や組織がアプリケーションのセキュリティリスクについて意思決定を下せるようにすることです。参照： -- **個人識別情報 (Personally Identifiable Information, PII)** – 一人の人間を識別、接触、探索するため、あるいはコンテキストの個人を特定するために、それ自身または他の情報と共に使用することができる情報です。 -- **位置独立実行形式 (Position-independent executable, PIE)** – 一次メモリのどこかに配置され、絶対アドレスに関係なく適切に実行される、マシンコードの本体です。 -- **公開鍵基盤 (Public Key Infrastructure, PKI)** – 公開鍵をエンティティのそれぞれのアイデンティティにバインドする仕組みです。バインディングは認証局 (CA) における証明書の登録および発行のプロセスによって確立されます。 -- **静的アプリケーションセキュリティテスト(Static Application Security Testing, SAST)** – コーディングや設計条件のセキュリティ上の脆弱性を示すため、アプリケーションコード、バイトコード、バイナリを解析するように設計された一連のテスト技法です。SASTソリューションはアプリケーションを非稼動状態で「内側から」分析します。 -- **ソフトウェア開発ライフサイクル (Software Development Lifecycle, SDLC)** – 。 -- **セキュリティアーキテクチャ (Security Architecture)** – アプリケーション設計の抽象概念です。セキュリティコントロールがどこでどのように使用されているかを特定し説明します。また、ユーザーとアプリケーションの両方のデータの場所と機密性を特定し説明します。 -- **セキュリティ設定 (Security Configuration)** – セキュリティコントロールの使用方法に影響を与えるアプリケーションの実行時設定です。 -- **セキュリティコントロール (Security Control)** – （アクセス制御チェックなどの）セキュリティチェックを実行する、もしくは（監査記録の生成などの）呼び出されたときにセキュリティ効果をもたらす、機能やコンポーネントです。 -- **SQL インジェクション (SQLi)** – 悪意のあるSQL文がエントリポイントに挿入される、データ駆動型アプリケーションの攻撃に使用されるコードインジェクション手法です。 -- **シングルサインオン認証 (Single Sign On Authentication, SSO Authentication)** – ユーザーがひとつのクライアントにログインするとき、ユーザーが使用しているプラットフォーム、テクノロジ、ドメインに関係なく、自動的に他のクライアントにサインインするものです。例えば、google にログインすると自動的に youtube、docs、メールサービス にログインします。 -- **脅威モデリング (Threat Modeling)** – 脅威エージェント、セキュリティゾーン、セキュリティコントロール、重要な技術的およびビジネス的資産を特定することにより、より洗練されたセキュリティアーキテクチャを開発することからなる技術です。 -- **トランスポート層のセキュリティ (Transport Layer Security)** – インターネット上の通信セキュリティを提供する暗号プロトコルです。 -- **URI および URL** – Uniform Resource Identifier は名前やWebリソースを識別するために使用される文字列です。Uniform Resource Locator は多くの場合リソースへの参照として使用されます。 -- **ユーザー受け入れテスト (User acceptance testing, UAT)** – 本番環境のように動作するテスト環境で、実稼動前に行われるすべてのソフトウェアテストです。 -- **検証者 (Verifier)** – OWASP MASVS 要件に照らし合わせてアプリケーションをレビューしている人またはチームです。 -- **ホワイトリスト (Whitelist)** – 許可されたデータまたは操作のリストです。例えば、入力の検証を実行できる文字のリストです。 -- **X.509 証明書 (X.509 Certificate)** – X.509 証明書は広く受け入れられている国際X.509公開鍵インフラストラクチャ（PKI）標準を使用するデジタル証明書であり、公開鍵が証明書に含まれるユーザー、コンピュータ、サービスのIDに属することを検証します。 diff --git a/Document-ja/0x91-Appendix-B_References.md b/Document-ja/0x91-Appendix-B_References.md deleted file mode 100644 index ab56e30d8..000000000 --- a/Document-ja/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# 付録 B: 参考情報 - -以下の OWASP プロジェクトはこの標準のユーザーや採用者にとって最も役に立つものです。 - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -同様に以下のWebサイトはこの標準のユーザーや採用者にとって最も役に立つものです。 - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-ja/CHANGELOG.md b/Document-ja/CHANGELOG.md deleted file mode 100644 index e18d99115..000000000 --- a/Document-ja/CHANGELOG.md +++ /dev/null @@ -1,99 +0,0 @@ -# 変更履歴 - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 2020年3月7日 - 国際公開 - -The following changes are part of release 1.2: - -- Translation in simplified Chinese of the MASVS available. -- Change of title in MASVS book cover. -- Removed Mobile Top 10 and CWE from MSTG and merged to existing references in MASVS. - -## V1.2-RC - 2019年10月5日 - プレリリース - -次の変更点は、リリース1.2の一部です: - -- flagshipステータスに昇格。 -- 要件変更: MSTG-STORAGE-1 「使用する必要がある」。 -- 要件 MSTG-STORAGE-13, MSTG-STORAGE-14, および MSTG-STORAGE-15 を追加。データ保護にフォーカス。 -- 要件 MSTG-AUTH-11 を更新。コンテキスト情報を保持。 -- 要件 MSTG-CODE-4 を更新。単なるデバッグ以上をカバー。 -- 要件 MSTG-PLATFORM-10 を追加。 WebView をさらに安全に使用。 -- 要件 MSTG-AUTH-12 を追加。特にマルチユーザーアプリの場合に、認可が実装されていることを開発者に想起。 -- リスク評価を考慮する場合のMASVSの使用方法に関する説明を若干追加。 -- 有料コンテンツに関する説明を若干追加。 -- 要件 MSTG-ARCH-11 を追加。 L2 アプリケーションに責任ある開示ポリシーを含める。 -- 要件 MSTG-ARCH-12 を追加。関連する国際的なプライバシー法に準拠する必要があることをアプリケーション開発者に提示。 -- すべての参照に一貫したスタイルを作成。 -- 要件 MSTG-PLATFORM-11 を追加。サードパーティキーボードを介したスパイ行為に対抗。 -- 要件 MSTG-MSTG-RESILIENCE-13 を追加。アプリケーションでの盗聴を防止。 -- MASVS の各言語版を更新: 中国語(繁体字)、英語、ドイツ語、フランス語、ロシア語、スペイン語、日本語。 - -## V1.1.4 - 2019年6月4日- サミット版 - -次の変更点は、リリース1.1.4に含まれています: - -- Markdownに関わるあらゆる問題を修正 -- フランス語とスペイン語の翻訳を更新 -- 日本語と中国語(簡体字)版において「変更履歴」を翻訳 -- Markdownの検証と文中のURLの到達性を自動テストするよう設定 -- それぞれの要件を特定するための「MSTGコード」ラベルを追加。これは、MSTGの将来のバージョンにおいて、推奨事項やテストケースを容易に見つけられるようにするためのものです。 -- リポジトリサイズを削減。.gitignoreにGeneratedを追加。 -- 行動規範と貢献者向けガイドラインを追加 -- プルリクエストテンプレートを追加 -- Gitbookウェブサイトをホストするのに用いているレポジトリの同期を更新 -- 全翻訳版のXML/JSON/CSV を生成するスクリプトを更新 -- 中国語（簡体字）の前書きを翻訳 - -## V1.1.3 - 2019年1月9日 軽微な修正 - -次の変更点は、リリース1.1.3に含まれています: - -- スペイン語版の要件7.1における翻訳ミスを修正。 -- 謝辞において翻訳者を記載。 -- 日本語版における翻訳の軽微な修正。 - -## V1.1.2 - 2019年1月3日 スポンサーシップと国際化 - -次の変更点は、リリース1.1.2に含まれています: - -- e-bookの購入者への感謝を追加 -- V4において、認証のリンクが欠落していた部分に追加、また認証の欠如についてのリンクを更新。 -- 英語版の4.7と4.8が入れ替わっていた問題を修正 -- 国際版初版 - - スペイン語版を修正し、英語版(1.1.2)に追従。 - - ロシア語版を修正し、英語版(1.1.2)に追従。 - - 中国語(繁体字)版、フランス語版、ドイツ語版、日本語版を初めて追加。 - - 翻訳の便宜のため、ドキュメントをシンプルに。 -- 自動リリースについてのインストラクションを追加。 - -## V1.1.0 - 2018年6月14日 - -次の変更点は、リリース1.1に含まれています:: - -- 要件 2.6 「機微情報を含んでいる可能性のあるテキストフィールドにおいてクリップボードが無効化されている」を削除。 -- 要件 2.2 「機密データはアプリコンテナまたはシステムの資格情報保存機能の外部に保存されていない」を追加。 -- 要件 2.1 を「個人識別情報、ユーザー資格情報、暗号化鍵などの機密データを格納するために、システムの資格情報保存機能が適切に使用されている。」と表現を調整。 - -## V1.0 - 2018年1月12日 - -次の変更点はリリース1.0に含まれています。 - -- 8.9は8.12と同様であるため削除 -- 4.6を一般的な表現に変更 -- 微細な修正 (タイプミスなど) diff --git a/Document-ja/GLOSSARY.md b/Document-ja/GLOSSARY.md deleted file mode 100644 index 396c0589e..000000000 --- a/Document-ja/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# 付録 A: 用語集 - -## アドレス空間配置のランダム化 (Address Space Layout Randomization, ASLR) - -メモリ破壊バグの悪用をより困難にする手法です。 - -## アプリケーションセキュリティ (Application Security) - -アプリケーションレベルのセキュリティは基礎となるオペレーティングシステムや接続されるネットワークにフォーカスするのではなく、開放型システム間相互接続参照モデル（OSIモデル）のアプリケーション層を構成するコンポーネントの分析にフォーカスします。 - -## アプリケーションセキュリティ検証 (Application Security Verification) - -OWASP ASVS に対するアプリケーションの技術的評価です。 - -## アプリケーションセキュリティ検証報告書 (Application Security Verification Report) - -対象とするアプリケーションの検証者が作成した全体的な結果と分析をまとめた報告書です。 - -## 認証 (Authentication) - -アプリケーションのユーザーの申請IDを検証します。 - -## 自動検証 (Automated Verification) - -脆弱性シグネチャを使用して問題を発見する自動ツール（動的分析ツール、静的解析ツール、のいずれかもしくはその両方）を使用する検証です。 - -## ブラックボックステスト (Black Box Testing) - -アプリケーションの機能を内部構造や動作に頼らすに検査するソフトウェアテストの手法です。 - -## コンポーネント (Component) - -自己完結型のコード単位です。他のコンポーネントと通信するディスクやネットワークに関連するインタフェースを持ちます。 - -## クロスサイトスクリプティング (Cross-Site Scripting, XSS) - -クライアント側のスクリプトをコンテンツに流入することを可能にする、Webアプリケーションで典型的に見られるセキュリティ脆弱性です。 - -## 暗号モジュール (Cryptographic Module) - -暗号アルゴリズムを実装し、暗号鍵を生成するハードウェア、ソフトウェア、ファームウェアです。 - -## CWE - -CWE はコミュニティにより開発された一般的なソフトウェアセキュリティ脆弱性のリストです。これは共通言語、ソフトウェアセキュリティツールのものさし、および脆弱性識別、緩和、予防のためのベースラインとして機能します。 - -## 動的アプリケーションセキュリティテスト (Dynamic Application Security Testing, DAST) - -実行状態のアプリケーションのセキュリティ脆弱性を示す条件を検出するように設計されたテスト技法です。 - -## 設計検証 (Design Verification) - -アプリケーションのセキュリティアーキテクチャの技術的評価です。 - -## 動的検証 (Dynamic Verification) - -脆弱性シグネチャを使用してアプリケーションの実行中に問題を発見する自動ツールを使用する検証です。 - -## グローバル一意識別子 (Globally Unique Identifier, GUID) - -ソフトウェアで識別子として使用される一意の参照番号です。 - -## ハイパーテキスト転送プロトコル (Hyper Text Transfer Protocol, HTTP) - -分散、協調、ハイパーメディア情報システムのためのアプリケーションプロトコルです。World Wide Web のためのデータ通信の基盤です。 - -## ハードコードされた鍵 (Hardcoded Keys) - -デバイス自体に格納されている暗号鍵です。 - -## プロセス間通信 (Inter Process Communications, IPC) - -プロセスが他のプロセスやカーネルと調和して活動するための通信です。 - -## 入力検証 (Input Validation) - -信頼できないユーザー入力の正規化および妥当性確認です。 - -## JAVA バイトコード (JAVA Bytecode) - -Java 仮想マシン (JVM) の命令セットです。各バイトコードは、命令（オペコード）をあらわす1バイトもしくは場合によっては2バイトと、パラメータを渡すための0バイト以上で構成されます。 - -## 悪性コード (Malicious Code) - -開発中にアプリケーションに導入された、アプリケーションの意図されたセキュリティポリシーを迂回する、アプリケーションの所有者に知られていないコードです。ウイルスやワームなどのマルウェアと同じではありません。 - -## マルウェア (Malware) - -アプリケーションユーザーや管理者の知識なしに実行時にアプリケーションに導入される実行可能コードです。 - -## Open Web Application Security Project (OWASP) - -アプリケーションソフトウェアのセキュリティを強化することにフォーカスする世界規模のフリーでオープンなコミュニティーです。私たちの使命はアプリケーションのセキュリティを「可視化」することで、人々や組織がアプリケーションのセキュリティリスクについて意思決定を下せるようにすることです。参照： - -## 個人識別情報 (Personally Identifiable Information, PII) - -一人の人間を識別、接触、探索するため、あるいはコンテキストの個人を特定するために、それ自身または他の情報と共に使用することができる情報です。 - -## 位置独立実行形式 (Position-independent executable, PIE) - -一次メモリのどこかに配置され、絶対アドレスに関係なく適切に実行される、マシンコードの本体です。 - -## 公開鍵基盤 (Public Key Infrastructure, PKI) - -公開鍵をエンティティのそれぞれのアイデンティティにバインドする仕組みです。バインディングは認証局 (CA) における証明書の登録および発行のプロセスによって確立されます。 - -## 静的アプリケーションセキュリティテスト(Static Application Security Testing, SAST) - -コーディングや設計条件のセキュリティ上の脆弱性を示すため、アプリケーションコード、バイトコード、バイナリを解析するように設計された一連のテスト技法です。SASTソリューションはアプリケーションを非稼動状態で「内側から」分析します。 - -## ソフトウェア開発ライフサイクル (Software Development Lifecycle, SDLC) - -。 - -## セキュリティアーキテクチャ (Security Architecture) - -アプリケーション設計の抽象概念です。セキュリティコントロールがどこでどのように使用されているかを特定し説明します。また、ユーザーとアプリケーションの両方のデータの場所と機密性を特定し説明します。 - -## セキュリティ設定 (Security Configuration) - -セキュリティコントロールの使用方法に影響を与えるアプリケーションの実行時設定です。 - -## セキュリティコントロール (Security Control) - -（アクセス制御チェックなどの）セキュリティチェックを実行する、もしくは（監査記録の生成などの）呼び出されたときにセキュリティ効果をもたらす、機能やコンポーネントです。 - -## SQL インジェクション (SQLi) - -悪意のあるSQL文がエントリポイントに挿入される、データ駆動型アプリケーションの攻撃に使用されるコードインジェクション手法です。 - -## シングルサインオン認証 (Single Sign On Authentication, SSO Authentication) - -ユーザーがひとつのクライアントにログインするとき、ユーザーが使用しているプラットフォーム、テクノロジ、ドメインに関係なく、自動的に他のクライアントにサインインするものです。例えば、google にログインすると自動的に youtube、docs、メールサービス にログインします。 - -## 脅威モデリング (Threat Modeling) - -脅威エージェント、セキュリティゾーン、セキュリティコントロール、重要な技術的およびビジネス的資産を特定することにより、より洗練されたセキュリティアーキテクチャを開発することからなる技術です。 - -## トランスポート層のセキュリティ (Transport Layer Security) - -インターネット上の通信セキュリティを提供する暗号プロトコルです。 - -## URI および URL - -Uniform Resource Identifier は名前やWebリソースを識別するために使用される文字列です。Uniform Resource Locator は多くの場合リソースへの参照として使用されます。 - -## ユーザー受け入れテスト (User acceptance testing, UAT) - -本番環境のように動作するテスト環境で、実稼動前に行われるすべてのソフトウェアテストです。 - -## 検証者 (Verifier) - -OWASP MASVS 要件に照らし合わせてアプリケーションをレビューしている人またはチームです。 - -## ホワイトリスト (Whitelist) - -許可されたデータまたは操作のリストです。例えば、入力の検証を実行できる文字のリストです。 - -## X.509 証明書 (X.509 Certificate) - -X.509 証明書は広く受け入れられている国際X.509公開鍵インフラストラクチャ（PKI）標準を使用するデジタル証明書であり、公開鍵が証明書に含まれるユーザー、コンピュータ、サービスのIDに属することを検証します。 diff --git a/Document-ja/SUMMARY.md b/Document-ja/SUMMARY.md deleted file mode 100644 index 4b4188e9d..000000000 --- a/Document-ja/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# 目次 - -- [変更履歴](CHANGELOG.md) -- [序文](0x01-Foreword.md) -- [扉](0x02-Frontispiece.md) -- [モバイルアプリケーションセキュリティ検証標準](0x03-Using_the_MASVS.md) -- [監査と認定](0x04-Assessment_and_Certification.md) - -## セキュリティ要件 - -- [V1: アーキテクチャ、設計、脅威モデリング要件](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: データストレージとプライバシー要件](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: 暗号化要件](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: 認証とセッション管理要件](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: ネットワーク通信要件](0x10-V5-Network_communication_requirements.md) -- [V6: プラットフォーム相互作用要件](0x11-V6-Interaction_with_the_environment.md) -- [V7: コード品質とビルド設定要件](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: 耐性要件](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## 付録 - -- [付録 A: 用語集](GLOSSARY.md) -- [付録 B: 参考情報](0x91-Appendix-B_References.md) diff --git a/Document-ja/book.json b/Document-ja/book.json deleted file mode 100644 index efd72a28d..000000000 --- a/Document-ja/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "ja" -} diff --git a/Document-ja/images/CC-license.png b/Document-ja/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-ja/images/CC-license.png and /dev/null differ diff --git a/Document-ja/images/MASVS-levels.png b/Document-ja/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-ja/images/MASVS-levels.png and /dev/null differ diff --git a/Document-ja/images/OWASP_logo.png b/Document-ja/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-ja/images/OWASP_logo.png and /dev/null differ diff --git a/Document-ja/images/license.png b/Document-ja/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-ja/images/license.png and /dev/null differ diff --git a/Document-ja/images/masvs-cover-1.1.xcf b/Document-ja/images/masvs-cover-1.1.xcf deleted file mode 100644 index 7e4ddd1e0..000000000 Binary files a/Document-ja/images/masvs-cover-1.1.xcf and /dev/null differ diff --git a/Document-ja/images/masvs-levels-new.jpg b/Document-ja/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-ja/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-ja/images/masvs-levels-new_ja.jpg b/Document-ja/images/masvs-levels-new_ja.jpg deleted file mode 100644 index c8c595670..000000000 Binary files a/Document-ja/images/masvs-levels-new_ja.jpg and /dev/null differ diff --git a/Document-ja/images/masvs-mini-cover.jpg b/Document-ja/images/masvs-mini-cover.jpg deleted file mode 100644 index bae43fdf8..000000000 Binary files a/Document-ja/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-ja/images/masvs-mini-cover.png b/Document-ja/images/masvs-mini-cover.png deleted file mode 100644 index 15d07d0c2..000000000 Binary files a/Document-ja/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-ja/metadata.md b/Document-ja/metadata.md deleted file mode 100644 index 6887a647c..000000000 --- a/Document-ja/metadata.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'ja' -languagetext: '(Japanese Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: '目次' - -mainfont: 'Noto Sans' -sansfont: 'Noto Sans' -monofont: 'Noto Sans Mono' -CJKmainfont: 'Noto Sans CJK JP' - ---- diff --git a/Document-ko/0x01-Foreword.md b/Document-ko/0x01-Foreword.md deleted file mode 100644 index 1e01dc9d3..000000000 --- a/Document-ko/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# 서문 - -기술 혁명은 빠르게 일어나고 있습니다. 10년전만 하더라도 스마트폰은 작은 키보드가 달린 투박한 디바이스로 기술에 정통한 비즈니스 사용자를 위한 값비싼 장난감에 불과하였습니다. 오늘날, 스마트폰은 우리 삶의 필수적인 부분입니다. 우리는 정보를 검색하고, 길을 찾고, 사람들과 소통하기 위해 스마트폰에 점점 의존하게 되었으며, 스마트폰은 비즈니스와 일상 생활 어디서나 필요한 존재가 되었습니다. - -모든 새로운 기술은 새로운 보안위험을 초래하고 그 변화에 대응하는 것은 보안업계가 직면한 주요 과제 중 하나입니다. 방어적인 측면은 항상 몇 발자국 뒤처집니다. 예를 들어, 많은 사람들의 기본 대응은 오래된 방법들을 적용하는 것이었습니다. 스마트폰은 작은 컴퓨터와 유사하며 모바일 앱은 고전적인 소프트웨어와 마찬가지이기 때문에 보안 요구사항이 동일하다고 생각하지만 그렇지 않습니다. 스마트폰 운영체제는 데스크톱 운영체제와 다르며, 모바일 앱은 웹 앱과 다릅니다. 예를 들어, 시그니처 기반의 바이러스 검색과 같은 전통적인 방법은 최신 모바일 OS 환경에서는 의미가 없습니다: 모바일 앱의 배포 모델과 호환되지 않을뿐만 아니라 샌드박스의 제한으로 인해 기술적으로도 불가능합니다. 또한, 버퍼 오버플로우, XSS와 같은 몇 가지 취약점 종류는 데스크톱 애플리케이션과 웹 애플리케이션과 달리(예외는 있지만) 일반 모바일 앱의 맥락에서 별로 의미가 없습니다. - -시간이 지남에 따라 우리 업계는 모바일 위협 환경을 더 잘 파악하게 되었습니다. 결국, 모바일 보안은 데이터 보호에 관한 모든 것입니다. 앱은 개인 정보, 사진, 녹음, 노트, 계정 데이터, 비즈니스 정보, 위치 등을 저장합니다. 앱은 매일 사용하는 서비스에 연결하는 클라이언트 역할을 하며, 다른 사람들과 주고 받는 모든 메시지를 처리하는 통신 허브의 역할을 합니다. 다른 사람의 스마트폰을 손상시키면 그 사람의 삶에 아무런 제약 없이 접근할 수 있습니다. 모바일 장치가 너무 쉽게 분실 또는 도난당하고 모바일 맬웨어가 증가하고 있다고 생각하면 데이터 보호의 필요성이 더욱 분명해집니다. - -따라서 모바일 앱의 보안 표준은 모바일 앱이 민감한 정보를 처리, 저장 및 보호하는 방법에 초점을 맞추어야 합니다. iOS나 Android와 같은 최신 모바일 운영체제는 안전한 데이터 저장과 통신을 위한 뛰어난 API를 제공하고 있지만, 효과를 발휘하려면 제대로 구현되고 사용되어야 합니다. 데이터 저장, 앱간 통신, 암호화 API의 올바른 사용 및 안전한 네트워크 통신은 신중하게 고려해야하는 측면 중 일부분에 지나지 않습니다. - -산업계의 합의가 필요한 중요한 문제는 '데이터의 기밀성과 무결성을 보호하기 위해 정확히 어디까지 어떻게 할 것인가' 입니다. 예를 들어, 대부분은 모바일 앱이 TLS 교환에서 서버 인증서를 검증해야 한다는 것에 동의할 것입니다. 하지만 SSL 인증서를 피닝하는 것은 어떨까요? 인증서를 검증하지 않으면 취약할까요? 앱이 민감한 데이터를 처리하는 경우 이것이 필수 요건이어야 하나요, 아니면 불필요한 것일까요? OS가 앱을 샌드박스화해도 SQLite 데이터베이스에 저장된 데이터를 암호화해야합니까? 특정 앱에 적합한 것은 다른 앱에는 쓺모가 없을 수 있습니다. MASVS는 다양한 위협 시나리오에 맞는 검증 수준을 사용하여 이러한 요구사항을 표준화하려는 시도입니다. - -또한 루트 맬웨어 및 원격 관리 도구의 출현으로 인해 모바일 운영체제 자체에 악용 가능한 결함이 있다는 사실을 인식하게 되었고, 따라서 민감한 데이터에 대한 추가 보호를 제공하고 클라이언트 변조를 방지하기 위해 컨테이너 전략이 점점 더 많이 사용되고 있습니다. 상황이 복잡하게 얽혀 있습니다. 하드웨어 지원 보안 기능과 Android for Work 및 Samsung Knox 등의 OS 레벨의 컨테이너 솔루션이 존재하지만, 다양한 디바이스에서 일관성 있게 사용할 수 있는 것은 아닙니다. 미봉책으로 소프트웨어 기반의 보호 대책을 구현할 수 있지만, 안타깝게도 이러한 종류의 보호를 검증하기 위한 표준이나 테스트 프로세스는 없습니다. - -그 결과 모바일 앱 보안 테스트 보고서는 체계적이지 못합니다. 예를 들어, 일부 테스터는 Android 앱에서 난독화 또는 루팅 미 탐지를 "보안 결함"으로 보고합니다. 다른 한편에서는 문자열 암호화, 디버거 감지 또는 통제 흐름 난독화와 같은 조치는 필수로 간주하지 않습니다. 하지만, 이러한 것을 이분법적으로 보는 방법은 복원력이 이항 명제가 아니기 때문에 말이 않됩니다: 방어하려는 특정 클라이언트 측 위협에 따라 다릅니다. 소프트웨어 보호는 무용지물은 아니지만 궁극적으로 우회 할 수 있으므로 보안 통제를 대체할 수는 없습니다. - -MASVS의 전반적인 목표는 모바일 애플리케이션 보안 기준(MASVS- L1)을 제시하는 것이며, 심층 방어 조치(MASVS-L2)와 클라이언트 측 위협에 대한 보호(MASVS-R)도 포함할 수 있도록 허용하는 것입니다. MASVS는 다음을 달성하기 위한 것입니다: - -- 안전한 모바일 애플리케이션을 개발하려는 소프트웨어 아키텍트 및 개발자를 위한 요구사항 제공; -- 모바일 앱 보안 검토에서 테스트할 수 있는 업계 표준 제공; -- 모바일 보안에서 소프트웨어 보호 메커니즘의 역할을 명확히하고 그 효과를 검증하기 위한 요구사항 제공; -- 다양한 사용 사례에 권장되는 보안 수준에 대한 구체적인 권장 사항 제공. - -우리는 100 % 업계 합의가 달성 불가능하다는 것을 인식하고 있습니다. 그럼에도 불구하고 MASVS가 모바일 앱 개발 및 테스트의 모든 단계에서 지침을 제공하는 데 유용하기를 바랍니다. 오픈소스 표준으로서, MASVS는 시간이 지남에 따라 발전할 것이며, 우리는 어떠한 기여와 제안도 환영합니다. - -Bernhard Mueller diff --git a/Document-ko/0x02-Frontispiece.md b/Document-ko/0x02-Frontispiece.md deleted file mode 100644 index 7b7ed7fb6..000000000 --- a/Document-ko/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# 본 표준에 대하여 - -![OWASP Logo](images/OWASP_logo.png) - -모바일 애플리케이션 보안 검증 표준(MASVS) 에 오신것을 환영합니다. MASVS는 iOS 및 Android에서 안전한 모바일 앱을 설계, 개발, 테스트하는데 필요한 보안 요구사항의 프레임워크를 확립하기 위한 커뮤니티 활동입니다. - -MASVS는 커뮤니티 활동과 업계 피드백의 성과입니다. 우리는 이 표준이 시간이 지남에 따라 발전하는 것을 기대하고 있으며, 커뮤니티의 피드백을 환영합니다. - -우리와 연락하는 가장 좋은 방법은 OWASP Mobile Project Slack 채널을 이용하는 것입니다: - -계정은 다음의 URL에서 만들 수 있습니다: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/) - -## 저작권 및 라이센스 - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. 본 저작물은 [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/)를 따릅니다. 재사용 또는 배포를 위해 본 저작물의 라이센스 조건을 다른 사람에게 명확하게 제시해야합니다. - - - -## 감사의 말 - -| 프로젝트 리더 | 책임 저자 | 공동저자 및 검토자 -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| 언어 | 번역자 및 검토자 | -| --------------- | ------------------------------------------------------------ | -| 브라질 포르투갈어 | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| 중국어 전통 | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| 중국어 간체 | Bob Peng, Harold Zang, Jack S | -| 프랑스어 | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| 독일어 | Rocco Gränitz, Sven Schleier (Review) | -| 스페인어 | Martin Marsicano, Carlos Holguera | -| 일본어 | Koki Takeyama, Riotaro Okada (Review) | -| 러시어아 | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| 힌디 어 | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 한국어 | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| 페르시아 인 | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| 포르투갈 인 | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| 터키어 | Anıl Baş, Haktan Emik | -| 그리스 어 | Panagiotis Yialouris | - -본 문서는 Jim Manico가 작성한 OWASP 애플리케이션 보안 검증 표준의 포크로 시작되었습니다. - -## 스폰서 - -MASVS와 MASTG는 모두 커뮤니티에서 자발적으로 생성되고 유지되지만, 때때로 약간의 외부 도움이 필요합니다. 따라서 기술 편집자를 고용할 수 있도록 자금을 기부해 주신 스폰서들에게 감사드립니다. 그들의 후원은 어떤식으로든 MASVS 또는 MASTG의 내용에 영향을 미치지 않는다는 점을 알려드립니다. 스폰서 패키지는 [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages")에 설명되어 있습니다.. - - - -마지막으로 [Leanpub](https://leanpub.com/mobile-security-testing-guide)에서 이 책을 구입하여 후원해 주신 모든 분들께 감사드립니다. diff --git a/Document-ko/0x03-Using_the_MASVS.md b/Document-ko/0x03-Using_the_MASVS.md deleted file mode 100644 index d7fa535d6..000000000 --- a/Document-ko/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,83 +0,0 @@ -# 모바일 애플리케이션 보안 검증 표준 - -MASVS를 사용하여 모바일 앱의 보안에 대한 신뢰 수준을 설정하는 데 사용할 수 있습니다. 요구사항은 다음과 같은 목표를 염두에 두고 개발되었습니다: - -- 메트릭으로 사용 - 개발자 및 애플리케이션 소유자가 기존 모바일 앱을 비교할 수 있는 보안 표준 제공. -- 지침으로 사용 - 모바일 앱 개발 및 테스트의 모든 단계에 대한 지침 제공. -- 구매 시 사용 - 모바일 앱 보안 검증을 위한 기준 제공. - -## 모바일 앱 보안 모델 - -MASVS는 두 가지 보안 검증 수준(MASVS-L1 and MASVS-L2)과 일련의 리버스 엔지니어링 복원력 요구사항(MASVS-R)을 정의하고 있습니다. MASVS-L1은 모든 모바일 앱에 권장되는 일반적인 보안 요구사항을 포함하고 있으며, MASVS-L2는 매우 민감한 데이터를 처리하는 앱에 적용해야 합니다. MASVS-R은 클라이언트측 위협을 방지하는 것이 설계 목표인 경우에 적용할 수 있는 추가 보호 요구사항을 다루고 있습니다. - -MASVS-L1의 요구사항을 충족하면 보안 모범 사례에 따라 일반적으로 취약점이 없는 안전한 앱을 완성할 수 있습니다. MASVS-L2는 SSL 피닝과 같은 심층 방어 통제를 추가하여 보다 정교한 공격에 내성이 있는 앱을 제공합니다. 모바일 운영체제의 보안 통제에 문제가 없고 최종 사용자가 잠재적인 공격자로 간주되지 않는다고 가정합니다. MASVS-R의 소프트웨어 보호 요구사항 전부 또는 일부를 충족하면 최종 사용자가 악의적이거나 모바일 OS가 손상되는 특정 클라이언트측 위협을 방지할 수 있습니다. - -**I: 모든 앱에서 MASVS-L1 통제를 구현하는 것을 권고하지만, 통제권 구현은 궁극적으로 비즈니스 소유자와 의사 소통을 통해 위험 기반으로 결정되어야 합니다.** - -**II: MASVS-R에 나열되고 OWASP Mobile Application Security Testing Guide에 설명된 소프트웨어 보호 통제는 궁극적으로 우회될 수 있으며, 보안 통제의 대체 수단으로 사용되어서는 안됩니다. 다만, 신규 위협을 명시하고 MASVS-L1 또는 MASVS-L2에 명시된 MASVS 요구사항을 충족하는 앱의 보호 통제를 추가하기 위한 것입니다.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### 문서의 구성 - -MASVS의 첫 번째 부분에는 보안 모델과 사용 가능한 검증 수준에 대한 설명이 수록되어 있으며, 그 다음이 실제로 표준을 사용하는 방법에 대한 권고사항입니다. 검증 수준에 대한 맵핑과 함께 자세한 보안 요구사항이 두 번째 파트에 나열되어 있습니다. 요구사항은 기술적 목표/범위를 기준으로 8개 범주(V1 ~ V8)로 분류되어 있습니다. MASVS 및 MASTG 전체에서 다음과 같은 명명법이 사용됩니다: - -- *요구사항 카테고리:* MASVS-Vx, 예. MASVS-V2: 데이터 스토리지 및 개인정보보호 -- *요구사항:* MASVS-Vx.y, 예. MASVS-V2.2: "민감한 데이터는 애플리케이션 로그에 기록되지 않습니다." - -### 세부 검증 수준 - -#### MASVS-L1: 표준 보안 - -MASVS-L1을 달성한 모바일 앱은 모바일 애플리케이션 보안 모범 사례를 준수합니다. 코드 품질, 민감한 데이터 처리 및 모바일 환경과의 상호작용 측면에서 기본 요구사항을 충족합니다. 보안 통제를 확인하기 위한 테스트 프로세스가 있어야 합니다. 이 수준은 모든 모바일 애플리케이션에 적합합니다. - -#### MASVS-L2: 심층 방어 - -MASVS-L2에는 표준 요구사항을 능가하는 고급 보안 통제 기능이 도입되었습니다. MASVS-L2를 충족하려면 위협 모델이 존재해야하며 보안은 앱 아키텍처와 디자인에 필수적인 부분이어야 합니다. 위협 모델을 기반으로 올바른 MASVS-L2 컨트롤을 선택하고 성공적으로 구현해야 합니다. 이 수준은 모바일 뱅킹 앱처럼 매우 민감한 데이터를 처리하는 앱에 적합합니다. - -#### MASVS-R: 리버스 엔지니어링 및 탬퍼링에 대한 복원력 - -이 앱은 최첨단 보안을 갖추고 있으며, 민감한 코드나 데이터를 추출하기 위해 변조, 위조, 역공학 등 구체적이고 명확하게 정의된 클라이언트측 공격에 대해서도 탄력적입니다. 이러한 앱은 하드웨어 보안 기능 또는 충분히 강력하고 검증 가능한 소프트웨어 보호 기술을 활용합니다. MASVS-R은 매우 민감한 데이터를 처리하는 앱에 적용할 수 있으며 지적 재산을 보호하거나 앱을 조작 방지하는 수단으로 사용될 수 있습니다. - -### 권장 사용 - -애플리케이션은 사전 위험 평가 및 필요한 전반적인 보안 수준에 근거하여 MASVS L1 또는 L2에 대해 검증할 수 있습니다. L1은 모든 모바일 앱에 적용할 수 있지만 L2는 일반적으로보다 민감한 데이터 또는 기능을 처리하는 앱에 권장됩니다. MASVS-R(또는 그 일부)을 적용하면 적절한 보안 검증 외에도 추가적으로 민감한 데이터의 리패키징 또는 추출과 같은 특정 위협에 대한 복원력을 검증할 수 있습니다. - -요약하면 다음과 같은 검증 유형을 사용할 수 있습니다: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -다른 조합은 다른 등급의 보안 및 복원력을 반영합니다. 목표는 유연성을 허용하는 것입니다: 예를 들어, 모바일 게임은 사용 적합성 이유로 2단계 인증과 같은 MASVS-L2 보안 통제장치를 추가하는 것을 보증하지 않을 수 있지만, 조작 방지에 대한 강력한 비즈니스 요구가 있을 수 있습니다. - -#### 선택할 검증 유형 - -MASVS L2의 요구사항을 구현하면 보안이 향상되는 동시에 개발 비용이 증가하고 최종 사용자 경험이 악화될 수 있습니다.(전통적인 절충) 일반적으로 L2는 위험 대비 비용 관점에서 의미가 있을때 앱에 사용해야 합니다.(즉, 기밀성 또는 무결성의 타협으로 인한 잠재적 손실이 추가 보안 통제에서 발생하는 비용보다 더 큰 경우) MASVS를 적용하기 전에 위험평가가 첫 번째 단계이여야 합니다. - -##### 사례 - -###### MASVS-L1 - -- 모든 모바일 앱. MASVS-L1에는 개발 비용 및 사용자 경험에 합리적인 영향을 줄 수 있는 보안 모범 사례가 나와 있습니다. 상위 레벨 중 하나에 해당하지 않는 앱에 대해서는 MASVS-L1의 요구사항을 적용하십시오. - -###### MASVS-L2 - -- 헬스케어 산업: 신분 도용, 사기 지불 또는 다양한 범죄 행위에 사용할 수 있는 개인 식별 정보를 저장하는 모바일 앱. 미국 의료 부문의 경우 규정 준수 고려 사항에는 미국의 의료보험의 양도 및 책임에 관한 법률(HIPAA)의 개인정보보호, 보안, 위반 통지 규칙 및 환자 안전 규칙이 포함됩니다. - -- 금융 산업: 신용카드번호, 개인정보와 같이 매우 민감한 정보에 액세스하거나 사용자가 송금할 수 있는 앱. 이러한 앱은 사기를 방지하기 위해 추가 보안 통제를 보장해야 합니다. 금융 앱은 신용카드업계 데이터 보안 표준(PCI DSS), 금융서비스현대화법(그램 리치 블라일리법, Gramm Leach Bliley Act) 및 사베인-옥슬리법(Sarbanes-Oxley Act, SOx)를 준수해야 합니다. - -###### MASVS L1+R - -- 지적재산권(IP) 보호가 비즈니스 목표인 모바일 앱. MASVS-R에 나열된 복원력 통제는 원래 소스코드를 획득하는 데 필요한 노력을 증가시키고 위변조를 방해하기 위해 사용할 수 있습니다. - -- 게임 산업: 경쟁력있는 온라인 게임과 같이 부정행위를 방지하는 데 필수적인 필요가 있는 게임. 부정행위는 많은 양의 사기꾼이 불만을 가진 플레이어 기반으로 이어져 궁극적으로 게임이 실패할 수 있기 때문에 온라인 게임에서 중요한 문제입니다. MASVS-R은 부정행위자의 부담을 증가 시키기 위해 기본적인 변조 방지 컨트롤을 제공합니다. - -###### MASVS L2+R - -- 금융 산업: 사용자가 송금할 수 있는 온라인 뱅킹 앱으로, 코드 삽입이나 손상된 장치의 계측과 같은 기술이 위험에 노출될 수 있습니다. 이 경우 MASVS-R의 컨트롤을 사용하여 조작을 방해하여 맬웨어 작성자의 부담을 증가 시킬 수 있습니다. - -- 설계상 민감한 데이터를 모바일 장치에 저장해야하는 동시에 모든 장치와 운영체제 버전을 지원해야하는 모든 모바일 앱. 이 경우 복원력 통제는 민감한 데이터 추출을 목표로하는 공격자의 노력을 증가시키기 위한 심층 방어 수단으로 사용될 수 있습니다. - -- 앱내 구매 기능이 있는 앱은 유료 콘텐츠를 보호하기 위해 서버측 및 MASVS-L2 통제를 이상적으로 사용해야 합니다. 단, 서버측 보호를 이용할 가능성이 없는 경우가 있을 수 있습니다. 이 경우 리버싱 또는 변조 방지력을 높이기 위해 MASVS-R 컨트롤을 추가로 적용해야 합니다. diff --git a/Document-ko/0x04-Assessment_and_Certification.md b/Document-ko/0x04-Assessment_and_Certification.md deleted file mode 100644 index 303fe9431..000000000 --- a/Document-ko/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# 평가 및 인증 - -## MASVS 인증 및 신뢰 마크에 대한 OWASP의 견해 - -OWASP는 벤더 중립적인 비영리 단체로서 벤더, 검증자 또는 소프트웨어 인증은 실시하지 않습니다. - -이러한 모든 보증 주장, 신뢰 마크 또는 인증은 OWASP에 의해 공식적으로 검증, 등록 또는 인증되지 않으므로, 그러한 견해에 의존하는 조직은 (M)ASVS 인증을 주장하는 제3자에 또는 신뢰 마크에 대한 신뢰에 주의를 기울여야 합니다. - -이는 조직이 공식적인 OWASP 인증을 요구하지 않는 한, 그러한 보증 서비스를 제공하는 것을 방해해서는 않됩니다. - -## 모바일 앱 인증 지침 - -모바일 앱이 MASVS를 준수하는지 확인하기 위해 권장되는 방법은 "오픈북" 검토를 수행하는 것이며, 앱 설계자와 개발자, 프로젝트 문서, 소스 코드 및 각 역할에 대해 적어도 하나 이상의 사용자 계정에 대한 액세스를 포함한 엔드 포인트에 인증된 액세스와 같은 주요 리소스에 대한 액세스 권한을 테스트 기술자에 부여하여야 합니다. - -MASVS는 (클라이언트 측) 모바일 앱의 보안 및 앱과 원격 엔드포인트 간의 네트워크 통신뿐만 아니라, 사용자 인증 및 세션 관리와 관련된 몇 가지 기본적이고 일반적인 요구사항을 다루고 있습니다. 앱과 관련된 원격 서비스(예: 웹 서비스)에 대한 특정 요구 사항은 포함하지 않으며, 인증 및 세션 관리와 관련된 제한된 일반적인 요구사항에 대해 안전합니다. 하지만, MASVS V1은 원격 서비스를 전체 위협 모델에서 다루며, OWASP ASVS와 같은 적절한 표준에 따라 검증해야 한다고 명시하고 있습니다. - -인증 기관은 모든 보고서에 검증의 범위(특히 중요한 구성요소가 범위 외인 경우), 합격 및 불합격 테스트를 포함한 검증 결과의 요약, 불합격 테스트에 대한 명확한 해결책을 포함해야합니다. 자세한 작업 문서, 스크린 샷 또는 동영상, 문제를 안정적이고 반복적으로 악용하는 스크립트, 프록시 로그 등 테스트의 전자적 기록을 정리한 목록과 같은 관련 메모를 유지하는 것은 업계 표준 관행으로 간주됩니다. 단순히 도구를 실행하고 실패를 보고하는 것만으로는 충분하지 않습니다. 이는 인증 수준의 모든 문제가 철저히 테스트되고 테스트되었다는 충분한 증거를 제공하지 않습니다. 논란이 있을 경우 검증된 모든 요구사항이 실제로 테스트되었음을 입증할 수 있는 충분한 증거가 있어야 합니다. - -### OWASP 모바일 보안 테스트 가이드(MASTG) 사용 - -OWASP MASTG는 모바일 앱의 보안을 테스트하기 위한 설명서입니다. MASVS에 나열된 요구사항을 확인하기 위한 기술 프로세스를 설명하고 있습니다. MASTG에는 MASVS의 요구사항에 각각 매핑되는 테스트 사례 목록이 포함되어 있습니다. MASVS 요구사항은 수준이 높고 일반적이지만, MASTG는 모바일 OS별로 자세한 권장 사항과 테스트 절차를 제공합니다. - -### 자동 보안 테스트 도구의 역할 - -가능한 경우 효율을 높이기 위해 소스코드 스캐너와 블랙박스 테스트 도구를 사용하는 것이 좋습니다. 하지만 자동화된 도구만으로는 MASVS 검증을 완료할 수 없습니다. 모든 모바일 앱은 서로 다르며, 사용 중인 특정 기술과 프레임워크의 전반적인 아키텍처, 비즈니스 로직 및 기술적 함정을 이해하는 것은 앱의 보안을 검증하기 위한 필수 요건입니다. - -## 기타 용도 - -### 고급 보안 아키텍처 지침 - -모바일 애플리케이션 보안 검증 표준의 가장 일반적인 용도 중 하나는 보안 설계자를 위한 리소스입니다. SABSA 또는 TOGAF의 두 가지 주요 보안 아키텍처 프레임워크에는 모바일 애플리케이션 보안 아키텍처 검토를 완료하는 데 필요한 많은 정보가 누락되어 있습니다. MASVS를 사용하면 보안 설계자가 모바일 앱에서 흔히 발생하는 문제에 대해 더 나은 통제를 선택할 수 있으므로 이러한 격차를 해소할 수 있습니다. - -### 상용 시큐어코딩 체크리스트 대체 - -대부분의 조직에서 MASVS를 채택하여 두 가지 수준 중 하나를 선택하거나, MASVS를 분기하여 각 애플리케이션의 위험 수준에 필요한 사항을 도메인별로 변경하여 적용함으로써 이점을 얻을 수 있습니다. 추적성이 유지되는 한 이러한 유형의 분기를 권장하므로 앱이 4.1 요구사항을 통과한 경우 표준이 발전함에 따라 분기 사본과 동일한 의미를 갖습니다. - -### 보안 테스트 방법론의 기초 - -우수한 모바일 앱 보안 테스트 방법은 MASVS에 나열된 모든 요구사항을 포함해야 합니다. OWASP 모바일 보안 테스트 가이드(MASTG)는 검증 요구사항에 대한 블랙박스와 화이트박스 테스트 사례에 대해 설명하고 있습니다. - -### 자동화된 단위 및 통합 테스트 가이드 - -MASVS는 아키텍처 요구사항을 제외하고는 테스트가 가능하도록 설계되었습니다. MASVS 요구사항을 기반으로 한 자동화된 단일, 통합 및 승인 테스트는 지속적인 개발 라이프사이클에 통합할 수 있습니다. 이를 통해 개발자 보안 인식이 향상될 뿐만 아니라, 결과적으로 앱의 전반적인 품질이 향상되고, 릴리즈 전 단계에서 보안 테스트 검증량이 감소합니다. - -### 개발 보안 교육 - -MASVS를 사용하여 안전한 모바일 앱의 특성을 정의할 수도 있습니다. 대부분의 "개발 보안" 과정은 간단한 코딩 팁이 포함된 윤리적 해킹 과정입니다. 이는 개발자에게 도움이 되지 않습니다. 대신, 개발 보안 과정에서는 MASVS를 사용할 수 있으며, MASVS에 문서화된 사전 예방적 통제에 중점을 두고 상위 10가지 코드 보안 문제를 중점적으로 다룰 수 있습니다. diff --git a/Document-ko/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-ko/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index d993f0e0b..000000000 --- a/Document-ko/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: 아키텍처, 디자인 및 위협 모델링 요구사항 - -## 통제 목표 - -이상적인 세계에서는 모든 개발 단계에서 보안이 고려될 것입니다. 그러나 실제로 보안은 SDLC의 마지막 단계에서만 고려되는 경우가 많습니다. 기술적인 통제 외에도, MASVS는 모바일 앱의 아키텍처를 계획할 때 보안이 명시적으로 해결되었는지 확인하고, 모든 구성 요소의 기능 및 보안 역할이 명확하다는 것을 보장하는 프로세스를 갖추는 것을 요구합니다. 대부분의 모바일 앱은 원격 서비스 클라이언트로 동작하기 때문에 해당 서비스에도 적절한 보안 기준을 적용해야 합니다. - 모바일 앱을 단독으로 테스트하는 것만으로는 충분하지 않습니다. - -"V1" 카테고리에는 앱의 아키텍처와 디자인에 관련된 요구사항이 나열되어 있습니다. 따라서, OWASP 모바일 테스트 가이드의 기술 테스트 사례에 매핑되지 않는 카테고리는 이 카테고리가 유일합니다. 위협 모델링, 보안 SDLC, 키 관리와 같은 주제를 다루기 위해 MASVS 사용자는 각 OWASP 프로젝트 또는 아래에 링크된 것과 같은 다른 표준을 참조해야 합니다. - -## 보안 검증 요구사항 - -MASVS-L1 및 MASVS-L2의 요구사항은 다음과 같습니다. - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | 모든 앱 구성 요소가 필요한 것으로 식별되어야 한다. | x | x | -| **1.2** | MSTG-ARCH-2 | 보안 통제는 클라이언트측에서만 적용되는 것이 아니라 각각의 원격 엔드 포인트에서도 적용되어야 한다. | x | x | -| **1.3** | MSTG-ARCH-3 | 모바일 앱과 연결되는 모든 원격 서비스에 수준 높은 아키텍처가 정의되어야 하고 해당 아키텍처에서 보안이 지원되어야 한다. | x | x | -| **1.4** | MSTG-ARCH-4 | 모바일 앱의 컨텍스트에서 민감한 것으로 간주되는 데이터가 명확하게 식별되어야 한다. | x | x | -| **1.5** | MSTG-ARCH-5 | 모든 앱 구성 요소는 비즈니스 기능과 보안 기능이 적용되어야 한다. | | x | -| **1.6** | MSTG-ARCH-6 | 모바일 앱과 연관된 원격 서비스의 위협 모델을 만들어 잠재적인 위협에 대한 대책을 적용하여야 한다. | | x | -| **1.7** | MSTG-ARCH-7 | 모든 보안 통제는 중앙 집중식으로 구현되어야 한다. | | x | -| **1.8** | MSTG-ARCH-8 | 암호화 키(있는 경우)를 관리하는 방법에 대한 명시적인 정책이 있으며 암호화 키의 수명주기가 적용되어야 한다. (NIST SP 800-57 등과 같은 키 관리 표준을 준수하는 것이 좋음) | | x | -| **1.9** | MSTG-ARCH-9 | 모바일 앱의 업데이트를 강제화하는 메커니즘이 존재하여야 하다. | | x | -| **1.10** | MSTG-ARCH-10 | 소프트웨어 개발 수명주기의 모든 부분에서 보안을 적용하여야 한다. | | x | -| **1.11** | MSTG-ARCH-11 | 책임 있는 공개 정책이 시행되고 있으며 효과적으로 적용되어야 한다. | | x | -| **1.12** | MSTG-ARCH-12 | 앱은 개인정보 보호법 및 규정을 준수해야 한다. | x | x | - -## 참고 - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-ko/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-ko/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 8c6fb29b6..000000000 --- a/Document-ko/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: 데이터 저장 및 개인 정보 요구사항 - -## 통제 목표 - -사용자 자격 증명 및 개인 정보와 같은 민감한 데이터를 보호하는 것이 모바일 보안의 핵심 초점입니다. 먼저, IPC와 같은 운영체제 메커니즘을 부적절하게 사용하게 되면 민감한 데이터가 의도하지 않게 동일한 장치에서 실행되는 다른 앱에 노출될 수 있습니다. 또한 데이터가 실수로 클라우드 저장소, 백업 또는 키보드 캐시로 유출될 수 있습니다. 또한 모바일 기기는 다른 유형의 기기에 비해 더 쉽게 분실하거나 도난당할 수 있으므로 공격자가 물리적으로 접근하기에 더 용이한 시나리오가 될 수 있습니다. 이 경우 민감한 데이터의 취득을 더 어렵게하기 위해 추가적인 보호대책이 필요합니다. - -주의 : MASVS는 앱 중심이므로 MDM 솔루션에 의해 시행되는 것과 같은 장치 수준 정책은 다루지 않습니다. 우리는 기업적 측면에에서 데이터 보안을 보다 강화하기 위해 이러한 정책을 사용하는 것을 권장합니다. - -### 민감한 데이터의 정의 - -MASVS의 민감한 데이터는 사용자 자격 증명과 특정 상황에서 민감한 것으로 간주되는 기타 모든 데이터를 포함합니다. - -- 신분 도용에 악용될 수 있는 개인 식별 정보(PII): 사회보장번호(주민등록번호), 신용카드 번호, 은행 계좌번호, 건강 정보 -- 유출될 경우 명예 실추 및 금전적 손실로 이어질 민감한 데이터: 계약 정보, 비공개 계약에 포함된 정보, 관리 정보 -- 법률 또는 컴플라이언스 이유로 보호되어야 하는 모든 데이터. - -## 보안 검증 요구사항 - -대부분의 데이터 공개의 문제는 아래의 간단한 규칙을 따르면 예방할 수 있습니다. 이 장에 나열된 대부분의 통제는 모든 검증 수준에서 필수 사항입니다. - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | 개인 식별 정보(PII), 사용자 자격 증명 암호화 키 같은 중요한 데이터를 저장할 경우 시스템 자격 증명 저장소를 적절하게 사용하여야 한다. | x | x | -| **2.2** | MSTG-STORAGE-2 | 민감한 데이터는 앱 컨테이너 또는 시스템 자격 증명 저장 시설 외부에 저장하지 않아야 한다. | x | x | -| **2.3** | MSTG-STORAGE-3 | 민감한 데이터는 응용 프로그램 로그에 기록하지 않아야 한다. | x | x | -| **2.4** | MSTG-STORAGE-4 | 민감한 데이터는 아키텍처에서 필요한 부분이 아닌 한 제3자와 공유하지 않아야 한다. | x | x | -| **2.5** | MSTG-STORAGE-5 | 민감한 데이터를 처리하는 텍스트 입력에서 키보드 캐시가 비활성화 되어야 한다. | x | x | -| **2.6** | MSTG-STORAGE-6 | 민감한 데이터는 IPC 메커니즘을 통해 노출되지 않아야 한다. | x | x | -| **2.7** | MSTG-STORAGE-7 | 비밀번호 또는 핀과 같은 민감한 데이터는 사용자 인터페이스를 통해 노출되지 않아야 한다. | x | x | -| **2.8** | MSTG-STORAGE-8 | 민감한 데이터는 모바일 운영체제에서 생성된 백업에 포함되지 않아야 한다. | | x | -| **2.9** | MSTG-STORAGE-9 | 민감한 데이터는 앱이 백그라운드로 이동할 때 뷰에서 제거되어야 한다. | | x | -| **2.10** | MSTG-STORAGE-10 | 민감한 데이터는 앱이 필요한 것보다 더 긴 시간 동안 메모리에 유지되지 않아야 하며, 사용 후에는 메모리에서 명시적으로 삭제하여야 한다. | | x | -| **2.11** | MSTG-STORAGE-11 | 앱은 사용자에게 장치 암호를 설정하도록 요구하는 것과 같은 최소한의 장치 액세스 보안 정책을 설정하도록 하여야 한다. | | x | -| **2.12** | MSTG-STORAGE-12 | 앱은 처리되는 개인 식별 정보가 처리되는 방식과 사용자가 앱 사용시 준수해야하는 보안 모범 사례에 대해 통지하여야 한다. | x | x | -| **2.13** | MSTG-STORAGE-13 | 민감한 데이터는 모바일 장치 로컬에 저장해서는 안된다. 대신 필요한 경우 원격 엔드포인트에서 데이터를 검색하고 메모리에만 보관하여야 한다. | | x | -| **2.14** | MSTG-STORAGE-14 | 민감한 데이터를 여전히 로컬에 저장해야하는 경우라면, 인증이 필요한 하드웨어 지원 저장소에서 파생된 키를 사용하여 암호화하여야 한다. | | x | -| **2.15** | MSTG-STORAGE-15 | 과도한 인증 시도 실패 후에는 앱의 로컬 저장소를 지워야 한다. | | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- Android: 데이터 저장소 테스트 - -- iOS: 데이터 저장소 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-ko/0x08-V3-Cryptography_Verification_Requirements.md b/Document-ko/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 2d247a8fd..000000000 --- a/Document-ko/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: 암호화 요구사항 - -## 통제 목표 - -암호화는 모바일 장치에 저장된 데이터를 보호하는데 필수적인 요소입니다. 또한 표준 규칙을 따르지 않을 때 상황이 끔찍하게 잘못될 수 있는 영역이기도 합니다. 이 장의 통제 목적은 검증된 애플리케이션이 다음과 같은 업계 모범 사례에 따라 암호화를 사용하는지 확인하는 것입니다. - -- 검증된 암호화 라이브러리 사용 -- 암호화 기본 요소의 올바른 선택 및 구성 -- 무작위 값이 필요한 경우 적절한 난수 발생기 사용 - -## 보안 검증 요구사항 - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | 앱은 암호화의 유일한 방법으로 하드 코드 된 키를 사용하는 암호화에 의존하지 않아야 한다. | x | x | -| **3.2** | MSTG-CRYPTO-2 | 앱은 검증된 암호화 알고리즘으로 구현하여야 한다. | x | x | -| **3.3** | MSTG-CRYPTO-3 | 앱은 업계 모범 사례를 준수하는 매개 변수로 구성된 특정 유스케이스에 적합한 암호화 알고리즘을 사용하여야 한다. | x | x | -| **3.4** | MSTG-CRYPTO-4 | 앱은 보안적인 목적으로 더 이상 사용되지 않고 사라질 암호화 프로토콜과 알고리즘을 사용하지 않아야 한다. | x | x | -| **3.5** | MSTG-CRYPTO-5 | 앱은 여러 목적으로 동일한 암호화 키를 재사용하지 않아야 한다. | x | x | -| **3.6** | MSTG-CRYPTO-6 | 모든 난수 값은 충분히 안전한 난수 생성기를 사용하여 생성하여야 한다. | x | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- Android: 암호화 테스트 - -- iOS: 암호화 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-ko/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-ko/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 2b1911824..000000000 --- a/Document-ko/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: 인증 및 세션 관리 요구사항 - -## 통제 목표 - -대부분의 경우 원격 서비스에 로그인하는 사용자는 전체 모바일 앱 아키텍처에서 필수적인 부분입니다. 대부분의 로직이 엔드포인트에서 발생하더라도 MASVS는 사용자 계정 및 세션을 관리하는 방법에 대한 몇 가지 기본 요구사항을 정의하고 있습니다. - -## 보안 검증 요구사항 - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | 앱이 사용자에게 원격 서비스에 대한 액세스를 제공하는 경우 사용자 이름과 암호로의 인증 방식은 원격 엔드 포인트에서 수행되어야 한다. | x | x | -| **4.2** | MSTG-AUTH-2 | 상태 저장 세션 관리를 사용하는 경우 원격 엔드 포인트는 무작위로 생성된 세션 식별자를 사용하여 사용자의 자격 증명을 보내지 않고 클라이언트 요청을 인증하여야 한다. | x | x | -| **4.3** | MSTG-AUTH-3 | 상태 비 저장 토큰 기반 인증을 사용하는 경우 서버는 보안 알고리즘을 사용하여 서명된 토큰을 제공하여야 한다. | x | x | -| **4.4** | MSTG-AUTH-4 | 사용자가 로그아웃하면 원격 엔드 포인트는 기존의 세션을 종료하여야 한다. | x | x | -| **4.5** | MSTG-AUTH-5 | 비밀번호 정책이 존재하며 원격 엔드 포인트에서 검증되어야 한다. | x | x | -| **4.6** | MSTG-AUTH-6 | 원격 엔드 포인트는 과도한 인증 시도에 대한 보호 메커니즘을 구현하여야 한다. | x | x | -| **4.7** | MSTG-AUTH-7 | 사전 정의 된 비 활동 기간 및 액세스 토큰이 만료 된 후 원격 엔드 포인트에서 세션이 무효화되어야 한다. | x | x | -| **4.8** | MSTG-AUTH-8 | 생체 인식 인증이 사용되는 경우 이벤트 바인딩(예: 단순히 "true"또는 "false"를 반환하는 API 사용) 되어서는 안된다. 대신 키 체인 및 키 스토어 잠금 해제를 할 때만 사용하여야 한다. | | x | -| **4.9** | MSTG-AUTH-9 | 2단계 인증 요소는 원격 엔드 포인트에 존재하여야 하며, 2FA 요구 사항이 지속적으로 적용되어야 한다. | | x | -| **4.10** | MSTG-AUTH-10 | 민감한 트랜잭션에는 단계별 인증을 적용하여야 한다. | | x | -| **4.11** | MSTG-AUTH-11 | 앱은 사용자에게 사용자 계정의 모든 민감한 활동을 알려야 한다. 사용자는 장치 목록을 보거나, 상태 정보(IP 주소, 위치 등)를 보고 특정 장치를 차단할 수 있어야 한다. | | x | -| **4.12** | MSTG-AUTH-12 | 인증 모델은 원격 엔드포인트에서 정의되고 시행되어야 한다. | x | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-ko/0x10-V5-Network_communication_requirements.md b/Document-ko/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index c545e169d..000000000 --- a/Document-ko/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: 네트워크 통신 요구사항 - -## 통제 목표 - -이 장에서 다루는 통제의 목적은 모바일 앱과 원격 서비스 엔드 포인트 간에 교환되는 정보의 기밀성과 무결성을 보장하기 위한 것입니다. 최소한 모바일 앱은 적절한 설정을 적용한 TLS 프로토콜을 사용하여 네트워크 통신을 위한 암호화된 보안 채널을 제공해야 합니다. 레벨 2에는 SSL 피닝과 같은 심층 방어 조치가 추가되어 있습니다. - -## 보안 검증 요구사항 - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | 데이터는 TLS를 사용하여 네트워크에서 암호화되어야 한다. 보안 채널은 앱 전체에 일관되게 사용하여야 한다. | x | x | -| **5.2** | MSTG-NETWORK-2 | TLS 설정은 현재 모범 사례와 일치하여야 하며, 모바일 운영 체제가 권장 표준을 지원하지 않는 경우 가능한 한 가장 가까운 모범 사례와 일치하여야 한다. | x | x | -| **5.3** | MSTG-NETWORK-3 | 보안 채널이 설정되면 앱은 원격 앤드 포인트의 X.509 인증서를 검증하여야 한다. 신뢰할 수 있는 CA가 서명한 인증서만 허용하여야 한다. | x | x | -| **5.4** | MSTG-NETWORK-4 | 앱은 자체 인증서 저장소를 사용하거나 앤드 포인트 인증서 또는 공개 키를 피닝하여야 한다. 그 후 신뢰할 수 있는 CA가 서명한 경우에도 다른 인증서 또는 키를 제공하는 앤드 포인트와의 연결을 거부할 수 있어야 한다. | | x | -| **5.5** | MSTG-NETWORK-5 | 앱은 등록 및 계정 복구와 같은 중요한 작업을 처리할 때 안전하지 않은 단일 통신 채널(이메일 또는 SMS)에 의존하지 않아야 한다. | | x | -| **5.6** | MSTG-NETWORK-6 | 앱은 최신 연결 라이브러리 및 보안 라이브러리에만 의존하여야 한다. | | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- General: 네트워크 통신 테스트 - -- Android: 네트워크 통신 테스트 - -- iOS: 네트워크 통신 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-ko/0x11-V6-Interaction_with_the_environment.md b/Document-ko/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index f8203f2fd..000000000 --- a/Document-ko/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: 플랫폼 상호 작용 요구사항 - -## 통제 목표 - -이 그룹의 통제는 앱이 플랫폼 API와 표준 구성요소를 안전한 방식으로 사용한다는 것을 보장합니다. 또한, 이 통제에는 애플리케이션 간의 통신(IPC)을 포함합니다. - -## 보안 검증 요구사항 - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | 앱은 필요한 최소한의 권한만 요구하여야 한다. | x | x | -| **6.2** | MSTG-PLATFORM-2 | 외부 소스 및 사용자의 모든 입력에 대해 검증하고 필요한 경우 적절하게 처리하여야 한다. 여기에는 UI를 통해 수신된 데이터, 인텐트, 사용자 정의 URL 및 네트워크 소스와 같은 IPC 메커니즘이 포함된다. | x | x | -| **6.3** | MSTG-PLATFORM-3 | 앱은 메커니즘이 제대로 보호되지 않는 한 사용자 정의 URL 체계를 통해 민감한 기능을 내보내지 않아야 한다. | x | x | -| **6.4** | MSTG-PLATFORM-4 | 엡은 메커니즘이 제대로 보호되지 않는 한 IPC 메터니즘을 통해 민감한 기능을 내보내지 않아야 한다. | x | x | -| **6.5** | MSTG-PLATFORM-5 | 명시적으로 필요한 경우가 아니면 웹뷰에서 자바스크립트를 사용하지 않아야 한다. | x | x | -| **6.6** | MSTG-PLATFORM-6 | 웹뷰는 필요 최소한의 프로토콜 핸들러 세트만 허용하도록 구성되어야 한다. (이상적으로는 https만 지원) file, tel 및 app-id와 같은 잠재적으로 위험한 핸들러는 비활성화하여야 한다. | x | x | -| **6.7** | MSTG-PLATFORM-7 | 앱의 네이티브 메소드가 웹뷰에 노출되는 경우 웹뷰가 앱 패키지에 포함된 자바스크립트만 렌더링하는지 검증하여야 한다. | x | x | -| **6.8** | MSTG-PLATFORM-8 | 객체 역직렬화는 안전한 직렬화 API를 사용하여 구현하여야 한다. | x | x | -| **6.9** | MSTG-PLATFORM-9 | 애플리케이션은 화면 오버레이 공격으로부터 자신을 보호하여야 한다. (Android 만 해당) | | x | -| **6.10** | MSTG-PLATFORM-10 | WebView를 종효하기 전에 WebView의 캐시, 스토리지 및 로드된 리소스(JavaScript 등)를 지워야 한다. | | x | -| **6.11** | MSTG-PLATFORM-11 | 민감한 데이터가 입력될 때마다 앱에서 사용자 지정 타사 키보드 사용을 방지하는지 확인하여야 한다. (iOS 만 해당) | | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- Android: 플랫폼 상호 작용 테스트 - -- iOS: 플랫폼 상호 작용 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-ko/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-ko/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index f9e499c6d..000000000 --- a/Document-ko/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,47 +0,0 @@ -# V7: 코드 품질 및 빌드 설정 요구사항 - -## 통제 목표 - -이 통제의 목표는 앱을 개발할 때 기본적인 보안 코딩 방법을 준수하고, 컴파일러에서 제공하는 "무료" 보안 기능이 활성화되도록 하는 것입니다. - -## 보안 검증 요구사항 - -| # | MSTG-ID | 설명 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | 앱이 유효한 인증서로 서명 및 프로비저닝되어야 하며, 개인 키가 올바르게 보호되어야 한다. | x | x | -| **7.2** | MSTG-CODE-2 | 앱은 릴리 모드로 빌드되어 있어야 한다. (디버그 불가) | x | x | -| **7.3** | MSTG-CODE-3 | 네이티브 바이너리에서 디버그 기호가 제거되어야 한다. | x | x | -| **7.4** | MSTG-CODE-4 | 디버깅 코드 및 개발자 지원 코드(예 : 테스트 코드, 백도어, 숨겨진 설정)가 제거되어야 한다. 앱은 자세한(verbose) 오류나 디버깅 메시지를 기록하지 않아야 한다. | x | x | -| **7.5** | MSTG-CODE-5 | 앱에서 사용되는 라이브러리 및 프레임워크 등은 모든 타사 구성 요소를 식별하고 알려진 취약점이 있는지 확인하여야 한다. | x | x | -| **7.6** | MSTG-CODE-6 | 앱은 가능한 모든 예외를 포착하고 처리하여야 한다. | x | x | -| **7.7** | MSTG-CODE-7 | 보안 통제의 오류 처리 로직은 기본적으로 액세스를 거부하여야 한다. | x | x | -| **7.8** | MSTG-CODE-8 | 관리되지 않는 코드에서 메모리는 할당, 해제 및 안전하게 사용되어야 한다. | x | x | -| **7.9** | MSTG-CODE-9 | 바이트 코드의 경량화, 스택 보호, PIE 지원 및 자동 참조 카운팅과 같은 툴체인에서 제공하는 무료 보안 기능이 활성화되어야 한다. | x | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- Android: 코드 품질 및 빌드 설정 테스트 - -- iOS: 코드 품질 및 빌드 설정 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-ko/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-ko/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index d4e062960..000000000 --- a/Document-ko/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V8: 복원력 요구사항 - -## 통제 목표 - -이 섹션에서는 민감한 데이터 또는 기능을 처리하거나 액세스하는 앱에 권장되는 심층 방어 조치에 대해 설명합니다. 이러한 통제를 적용하지 않더라도 취약점이 발생하지는 않습니다. 대신 리버스 엔지니어링 및 특정 클라이언트측 공격에 대한 앱의 복원력을 향상 시키기 위한 것입니다. - -이 섹션의 통제는 앱의 무단 변조 또는 코드 리버스 엔지니어링으로 인한 위험 평가를 기반으로 필요에 따라 적용하여야 합니다. 비즈니스 위험 및 관련 기술 위협에 대해서는 OWASP 문서 "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention"(아래 자료 참조)를 참조하십시오. - -**메모 : 해당 소프트웨어 보호 기능을 보안 통제 대신 사용해서는 안됩니다. MASVR-R에 나열된 통제는 MASVS 보안 요구사항을 충족하는 앱에 위협별 보호 통제를 추가하기 위한 것입니다.** - -다음과 같은 고려 사항이 적용됩니다: - -1. 위협 모델은 방어하는 클라이언트측 위협을 명확하게 정의해야 합니다. 또한 체계가 제공하는 보호 등급을 지정해야 합니다. 예를 들어, 악성코드 작성자가 앱을 분석하는데 수동 리버스 엔지니어링에 상당한 노력을 투자하도록 만드는 것이 목표일 수 있습니다. - -2. 위협 모델은 민감해야 합니다. 예를 들어, 공격자가 화이트박스 전체를 단순히 코드 리프팅 할 수 있다면 화이트박스 구현에서 암호화 키를 숨기는 것이 중요합니다. - -3. 보호의 효과는 사용된 특정 유형의 변조 방지 및 난독화를 테스트한 경험이 있는 전문가가 항상 검증해야 합니다.(모바일 보안 테스트 가이드(MASTG)의 "리버스 엔지니어링" 및 "소프트웨어 보호 평가" 부분을 참조하십시오.) - -### 동적 분석 및 변조 방지 - -| # | MSTG-ID | 설명 | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | 앱은 사용자에게 경고하거나 앱을 종료하여 루팅 또는 탈옥 된 기기의 존재를 감지하여야 한다. | x | -| **8.2** | MSTG-RESILIENCE-2 | 앱은 디버깅을 방지하거나 디버거 연결을 감지하여야 한다. 사용 가능한 모든 디버깅 프로토콜이 포함되어야 한다. | x | -| **8.3** | MSTG-RESILIENCE-3 | 앱은 자체 샌드박스에서 실행 파일 및 중요한 데이터의 변조를 감지하여야 한다. | x | -| **8.4** | MSTG-RESILIENCE-4 | 앱은 장치에 널리 사용되는 리버스 엔지니어링 도구 및 프레임워크의 존재를 감지하여야 한다. | x | -| **8.5** | MSTG-RESILIENCE-5 | 앱은 에뮬레이터에서 실행되고 있는지 여부를 감지하고 대응하여야 한다. | x | -| **8.6** | MSTG-RESILIENCE-6 | 앱은 자체 메모리 공간에서 코드와 데이터 변조를 감지하여야 한다. | x | -| **8.7** | MSTG-RESILIENCE-7 | 앱은 각 방어 유형(8.1~8.6)에서 여러 메커니즘을 구현하여야 한다. 복원력은 사용된 메커니즘의 독창성의 양 및 다양성과 비례합니다. | x | -| **8.8** | MSTG-RESILIENCE-8 | 감지 메커니즘은 지연 응답과 스텔스 응답을 포함하여 다양한 종류 응답을 트리거하여야 한다. | x | -| **8.9** | MSTG-RESILIENCE-9 | 프로그램 난독화가 적용되고, 동적 분석을 통한 역 난독처리를 방해하여야 한다. | x | - -### 장치 바인딩 - -| # | MSTG-ID | 설명 | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | 앱은 장치 고유의 여러 속성에서 파생되는 장치 지문을 사용하여 '장치 바인딩' 기능을 구현하여야 한다. | x | - -### 이해 방해(Impede Comprehension) - -| # | MSTG-ID | 설명 | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | 앱에 속하는 모든 실행 파일 및 라이브러리는 파일 수준에서 암호화되거나 실행 파일 내의 중요한 코드 및 데이터 세그먼트가 암호화되거나 압축되어야 한다. 간단한 정적 분석은 중요한 코드나 데이터가 노출되지 않아야 한다. | x | -| **8.12** | MSTG-RESILIENCE-12 | 난독화의 목표가 민감한 계산을 보호하는 것이라면, 현재 공개된 연구를 고려하여 특정 작업에 적합하고 수동 및 자동화된 역 난독화 방법에 대해 강력한 난독화 체계가 사용되어야 한다. 난독화의 효과는 수동 테스트를 통해 검할 필요가 있다. 하드웨어 기반 격리 기능이 난독화 처리보다 우선시 된다. | x | - -### 도청 방해(Impede Eavesdropping) - -| # | MSTG-ID | 설명 | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | 심층 방어로서, 통신 당사자를 확실하게 강화하는 것 외에도, 애플리케이션 레벨 페이로드 암호화를 적용하여 도청을 더욱 방해할 수 있다. | x | - -## 참고 - -OWASP 모바일 보안 테스트 안내서(MASTG)는 이 섹션에 나열된 요구사항을 확인하기 위한 자세한 지침을 제공합니다. - -- Android: 리버스 엔지니어링에 대한 복원력 테스트 - -- iOS: 리버스 엔지니어링에 대한 복원력 테스트 - - -자세한 내용은 다음을 참조하십시오: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-ko/0x90-Appendix-A_Glossary.md b/Document-ko/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 2c9dfa504..000000000 --- a/Document-ko/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# 부록 A: 용어집 - -- **주소 공간 레이아웃 랜덤화(Address Space Layout Randomization, ASLR)** – 메모리 오염 버그를 더 어렵게 만드는 기술. -- **애플리케이션 보안(Application Security)** – 애플리케이션 수준 보안은 기본 운영체제 또는 연결된 네트워크와 같은 것에 초점을 맞추는 대신 OSI(Open Systems Interconnect Reference) 모델의 애플리케이션 계층을 구성하는 구성 요소의 분석에 초점을 맞춥니다. -- **애플리케이션 보안 검증(Application Security Verification)** – OWASP MASVS에 대한 애플리케이션의 기술적 평가입니다. -- **애플리케이션 보안 검증 보고서(Application Security Verification Report)** – 특정 애플리케이션에 대해 검증자가 작성한 전체 결과 및 지원 분석을 문서화 한 보고서입니다. -- **인증(Authentication)** – 애플리케이션 사용자가 요청한 ID를 확인합니다. -- **자동 검증(Automated Verification)** – 취약점 시그니처를 사용하여 문제점을 찾는 자동화 된 도구(동적 분석 도구, 정적 분석 도구 또는 둘 다)를 사용하는 검증입니다. -- **블랙 박스 테스트(Black box testing)** – 내부 구조나 작동 방식에 신경 쓰지 않고 애플리케이션의 기능을 검사하는 소프트웨어 테스트 방법입니다. -- **컴포넌트(Component)** – 다른 구성 요소와 통신하는 관련 디스크 및 네트워크 인터페이스가 있는 독립적인 코드 단위입니다. -- **크로스 사이트 스크립팅(Cross-Site Scripting, XSS)** – 클라이언트측 스크립트를 콘텐츠에 삽입할 수 있는 웹 애플리케이션에서 일반적으로 볼 수 있는 보안 취약점입니다. -- **암호화 모듈(Cryptographic module)** – 암호화 알고리즘을 구현하고 암호화 키를 생성하는 하드웨어, 소프트웨어 또는 펌웨어입니다. -- **CWE** – CWE는 커뮤니티에서 개발한 공통적인 소프트웨어 보안 취약점 목록입니다. 이것은 공통 언어, 소프트웨어 보안 도구의 잣대, 취약점 식별, 완화 및 예방 활동의 기준 역할을 합니다. -- **동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST)** – 실행 중인 애플리케이션의 보안 취약점을 나타내는 조건을 감지하도록 설계된 테스트 기법입니다. -- **설계 검증 (Design Verification)** – 애플리케이션 보안 아키텍처에 대한 기술 평가입니다. -- **동적 검증(Dynamic Verification)** – 취약점 시그니처를 사용하여 애플리케이션을 실행하는 동안 문제를 발견하는 자동 도구를 사용하여 확인합니다. -- **전역 고유 식별자 (Globally Unique Identifier, GUID)** – 소프트웨어에서 식별자로 사용되는 고유한 참조 번호입니다. -- **하이퍼 텍스트 전송 프로토콜 (Hyper Text Transfer Protocol, HTTP)** – 분산, 협업 및 하이퍼미디어 정보 시스템을 위한 애플리케이션 프로토콜입니다. 이것은 월드 와이드 웹을 위한 데이터 통신의 기초입니다. -- **하드 코드 된 키(Hardcoded keys)** – 장치 자체에 저장된 암호화 키입니다. -- **프로세스 간 통신 (Inter Process Communications, IPC)** – 프로세스가 다른 프로세스 또는 커널과 활동을 조율하기 위한 통신입니다. -- **입력 검증(Input Validation)** – 신뢰할 수 없는 사용자 입력에 대한 표준화 및 유효성 검사입니다. -- **JAVA 바이트 코드(JAVA Bytecode)** – Java 가상 머신(JVM)의 명령 세트입니다. 각각의 바이트 코드는 매개 변수를 전달하기 위한 0개 이상의 바이트와 함께 명령어(opcode)를 나타내는 1개 또는 2개 바이트로 구성됩니다. -- **악성 코드(Malicious Code)** – 개발 과정에서 애플리케이션의 의도된 보안 정책을 우회하기 위해 애플리케이션 소유자에게 잘 알려지지 않은 애플리케이션에 포함된 코드입니다. 바이러스나 웜과 같은 맬웨어와 동일하지 않습니다. -- **맬웨어(Malware)** – 애플리케이션 사용자와 관리자가 알지 못하세 런타임 동안 애플리케이션에 삽입되어 실행되는 코드입니다. -- **Open Web Application Security Project (OWASP)** – 애플리케이션 소프트웨어의 보안을 향상시키는 데 초점을 맞춘 전 세계 무료 오픈 커뮤니티입니다. 우리의 사명은 사용자와 조직이 애플리케이션 보안 위험에 대한 정보에 근거한 결정을 내릴 수 있도록 애플리케이션 보안을 "가시성"있게 만드는 것입니다. 참조: -- **개인 식별 정보(Personally Identifiable Information, PII)** – 개인 식별 정보는 단독 또는 다른 정보와 함께 사용하여 정보주체를 식별, 접촉 또는 찾아내는 등 개인을 식별하는 데 사용할 수 있는 정보입니다. -- **위치 독립 실행 형식 (Position-independent executable, PIE)** – 기본 메모리의 어딘가에 배치되어 절대 주소에 관계없이 올바르게 실행되는 기계 코드의 본문입니다. -- **공개 키 기반 구조 (Public Key Infrastructure, PKI)** – PKI는 공개 키를 엔터티의 각 ID와 바인딩하는 구조입니다. 바인딩은 인증기관(CA)의 인증서 등록 및 게시 프로세스에 의해 확립됩니다. -- **정적 애플리케이션 보안 테스트 (Static Application Security Testing, SAST)** – 보안 취약점을 나타내는 코딩 및 설계 조건에 대한 애플리케이션 소스 코드, 바이트 코드 및 이진 파일을 분석하기 위해 설계된 기술 모음입니다. SAST 솔루션은 애플리케이션을 비 작동 상태에서 구석구석까지 분석합니다. -- **SDLC** – 소프트웨어 개발 라이프 사이클. -- **보안 아키텍처 (Security Architecture)** – 보안 통제가 사용되는 위치와 방법을 식별하고 기술하며, 사용자 및 애플리케이션 데이터의 위치와 민감도를 식별하고 기술하는 애플리케이션 설계의 추상화입니다. -- **보안 설정 (Security Configuration)** – 보안 통제 사용 방법에 영향을 미치는 애플리케이션의 런타임 설정입니다. -- **보안 통제(Security Control)** – 보안 점검(예 : 액세스 통제 점검)을 수행하거나 호출될 때 보안 효과(예 : 감사 레코드 생성)를 수행하는 기능 또는 구성 요소입니다. -- **SQL 인젝션(SQL Injection, SQLi)** – 데이터 기반 애플리케이션을 공격하기 위해 악의적인 SQL문을 엔트리 포인트에 코드를 삽입하는 공격기법입니다. -- **싱글 사인온 인증 (Single Sign On Authentication, SSO Authentication)** – 사용자가 한 클라이언트에 로그인 한 후 사용자가 사용중인 플랫폼, 기술 또는 도메인에 관계없이 다른 클라이언트에 자동으로 로그인하는 것을 의미합니다. 예를 들어, 구글에 로그인하면 자동으로 유튜브, 드라이브, 메일 서비스에 로그인됩니다. -- **위협 모델링(Threat Modeling)** – 위협 에이전트, 보안 영역, 보안 통제, 중요한 기술 및 비즈니스 자산을 식별하기 위해 보다 정교한 보안 아키텍처를 개발하기 위한 기술입니다. -- **전송 계층 보안(Transport Layer Security)** – 인터넷을 통한 통신 보안을 제공하는 암호화 프로토콜입니다. -- **URI and URL** – URI는 이름 또는 웹 리소스를 식별하는 데 사용되는 문자열입니다. URL은 종종 자원에 대한 참조로 사용됩니다. -- **사용자 수용 테스트 (User acceptance testing, UAT)** – 운영 환경처럼 작동하도록 테스트 환경에서 프로덕션 전에 행해지는 모든 소프트웨어 테스트를 의미합니다. -- **검토자(Verifier)** – OWASP MASVS 요구사항에 따라 신청서를 검토하는 사람 또는 팀을 의미합니다. -- **화이트리스트(Whitelist)** – 허용 된 데이터 또는 작업의 목록입니다. (예: 입력 유효성 검사를 수행할 수 있는 문자 목록) -- **X.509 인증서 (X.509 Certificate)** – X.509 인증서는 널리 사용되는 국제 X.509 공개 키 인프라(PKI) 표준으로, 공개 키 인증서에 포함 된 사용자, 컴퓨터 또는 서비스 ID에 속하는지 확인하는 디지털 인증서입니다. diff --git a/Document-ko/0x91-Appendix-B_References.md b/Document-ko/0x91-Appendix-B_References.md deleted file mode 100644 index 944ebc4d0..000000000 --- a/Document-ko/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# 부록 B: 참고 자료 - -다음 OWASP 프로젝트는 이 표준의 사용자 및 채택자에게 가장 유용할 수 있습니다. - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -마찬가지로 이 표준의 사용자 및 채택자에게 가장 유용할 수 있는 웹 사이트는 다음과 같습니다. - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-ko/CHANGELOG.md b/Document-ko/CHANGELOG.md deleted file mode 100644 index 32df9419a..000000000 --- a/Document-ko/CHANGELOG.md +++ /dev/null @@ -1,96 +0,0 @@ -# 변경이력 - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 2020년 3월 7일 - 국제 릴리스 - -다음 변경 사항은 릴리스 1.2의 일부입니다: - -- MASVS의 중국어 간체 번역. -- MASVS 책 표지에서 제목 변경. -- MSTG에서 Mobile Top 10 및 CWE를 제거하고 MASVS의 기존 참조와 병합. - -## V1.2-RC - 2019년 10월 5일 - 시험판 - -다음 변경 사항은 시험판 1.2의 일부입니다: - -- 플래그십 상태로 승격됨. -- 요구사항 변경: MSTG-STORAGE-1 "사용 필요". -- 데이터 보호에 중점을 두기 위해 요구사항 MSTG-STORAGE-13, MSTG-STORAGE-14 및 MSTG-STORAGE-15 요구사항 추가. -- 요구사항 MSTG-AUTH-11은 상황별 정보를 보존하도록 업데이트. -- 요구 사항 MSTG-CODE-4는 단순한 디버깅 이상을 포함하도록 업데이트. -- WebView의 더 안전하게 사용하기 위해 MSTG-PLATFORM-10 요구사항 추가. -- 개발자에게 특히 다중 사용자 앱의 경우 개발자에게 인증 구현을 상기시키기 위해 MSTG-AUTH-12 요구사항 추가. -- 위험 평가 시에 MASVS를 사용하는 방법에 대한 설명 추가. -- 유료 컨텐츠에 대한 설명 추가. -- L2 애플리케이션에 대한 책임 있는 공개 정책을 포함하기 위해 MSTG-ARCH-11 요구사항 추가. -- 애플리케이션 개발자에게 관련 국제 개인정보보호법을 준수해야 함을 보여주기 위해 MSTG-ARCH-12 요구사항 추가. -- 영어 버전의 모든 참조에 대해 일관된 스타일을 만듦. -- MSTG-PLATFORM-11 요구 사항이 타사 키보드를 통한 스파이 감시에 추가. -- 요구사항 MSTG-MSTG-RESILIENCE-13이 추가되어 애플리케이션에서 도청을 막을 수 있음. -- MASVS를 중국어(ZHTW:번체), 영어, 독일어, 프랑스어, 일본어, 한국어, 러시아어 및 스페인어로 업데이트했습니다. - -## V1.1.4 - 2019년 7월 4일 - 서밋 에디션 - -다음 변경 사항은 릴리스 1.1.4의 일부입니다: - -- 모든 마크다운 문제 해결. -- 프랑스어 및 스페인어 번역 업데이트. -- 변경이력을 중국어(ZHTW:번체) 및 일본어로 번역. -- 마크다운 구문 및 URL의 접근성에 대한 자동 검증. -- 권장 사항과 테스트 사례를 쉽게 찾을 수 있도록 요구사항에 식별 코드를 추가했으며, 향후 버전의 MSTG에 포함. -- repo 크기를 줄이고 .gitignore에 생성 추가. -- 행동 강령 및 기여 가이드라인 추가. -- 풀 요청(Pull-Request) 템플릿 추가. -- 깃북 웹 사이트 호스팅에 사용 중인 리포지토리와 동기화 업데이트. -- 모든 번역에 대해 XML/JSON/CSV를 생성하도록 스크립트 업데이트. -- 서문을 중국어(ZHTW:번체)로 번역. - -## V1.1.3 - 2019년 1월 9일 - 작은 수정 - -- 스페인어 버전에서 요구사항 7.1의 번역 문제 수정 -- 감사의 글에 새로운 번역자 추가 - -## V1.1.2 - 2019년 1월 3일 - 후원 및 국제화 - -다음 변경 사항은 릴리스 1.1.2의 일부입니다: - -- 전자책 구매자에게 감사의 말 추가. -- V4에서 누락 된 인증 링크 및 업데이트 된 인증 링크 추가. -- 영어 버전 4.7과 4.8가 바뀌어 있던 문제 수정. -- 국제 버전 초판 출시! - - 스페인어 번역 수정. 번역은 현재 영어(1.1.2)와 일치. - - 러시아어 번역 수정. 번역은 현재 영어(1.1.2)와 일치. - - 중국어(ZHTW:번체), 프랑스어, 독일어, 일본어를 처음 추가! -- 번역이 용이하도록 문서 간소화. -- 자동 릴리스에 대한 지침 추가. - -## V1.1.0 - 2018년 7월 14일 - -다음 변경 사항은 릴리스 1.1.0의 일부입니다: - -- 요구사항 2.6 "민감한 데이터를 포함할 수 있는 텍스트 필드에서 클립보드를 비활성화하여야 한다." 제거. -- 요구사항 2.2 "민감한 데이터는 앱 컨테이너 또는 시스템 자격 증명 저장 시설 외부에 저장하지 않아야 한다." 추가. -- 요구사항 2.1 "개인 식별 정보(PII), 사용자 자격 증명 암호화 키 같은 중요한 데이터를 저장하기 위해 시스템 자격 증명 저장 기능을 적절하게 사용하여야 한다."로 수정. - -## V1.0 - 2018년 1월 12일 - -다음 변경 사항은 릴리스 1.0의 일부입니다: - -- 8.12와 동일하게 8.9 삭제 -- 4.6 일반적인 표현으로 변경 -- 사소한 수정 (오타 등) diff --git a/Document-ko/GLOSSARY.md b/Document-ko/GLOSSARY.md deleted file mode 100644 index 3f692d77a..000000000 --- a/Document-ko/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# 부록 A: 용어집 - -## 주소 공간 레이아웃 랜덤화(Address Space Layout Randomization, ASLR) - -메모리 오염 버그를 더 어렵게 만드는 기술. - -## 애플리케이션 보안(Application Security) - -애플리케이션 수준 보안은 기본 운영체제 또는 연결된 네트워크와 같은 것에 초점을 맞추는 대신 OSI(Open Systems Interconnect Reference) 모델의 애플리케이션 계층을 구성하는 구성 요소의 분석에 초점을 맞춥니다. - -## 애플리케이션 보안 검증(Application Security Verification) - -OWASP MASVS에 대한 애플리케이션의 기술적 평가입니다. - -## 애플리케이션 보안 검증 보고서(Application Security Verification Report) - -특정 애플리케이션에 대해 검증자가 작성한 전체 결과 및 지원 분석을 문서화 한 보고서입니다. - -## 인증(Authentication) - -애플리케이션 사용자가 요청한 ID를 확인합니다. - -## 자동 검증(Automated Verification) - -취약점 시그니처를 사용하여 문제점을 찾는 자동화 된 도구(동적 분석 도구, 정적 분석 도구 또는 둘 다)를 사용하는 검증입니다. - -## 블랙 박스 테스트(Black box testing) - -내부 구조나 작동 방식에 신경 쓰지 않고 애플리케이션의 기능을 검사하는 소프트웨어 테스트 방법입니다. - -## 컴포넌트(Component) - -다른 구성 요소와 통신하는 관련 디스크 및 네트워크 인터페이스가 있는 독립적인 코드 단위입니다. - -## 크로스 사이트 스크립팅(Cross-Site Scripting, XSS) - -클라이언트측 스크립트를 콘텐츠에 삽입할 수 있는 웹 애플리케이션에서 일반적으로 볼 수 있는 보안 취약점입니다. - -## 암호화 모듈(Cryptographic module) - -암호화 알고리즘을 구현하고 암호화 키를 생성하는 하드웨어, 소프트웨어 또는 펌웨어입니다. - -## CWE - -CWE는 커뮤니티에서 개발한 공통적인 소프트웨어 보안 취약점 목록입니다. 이것은 공통 언어, 소프트웨어 보안 도구의 잣대, 취약점 식별, 완화 및 예방 활동의 기준 역할을 합니다. - -## 동적 애플리케이션 보안 테스트 (Dynamic Application Security Testing, DAST) - -실행 중인 애플리케이션의 보안 취약점을 나타내는 조건을 감지하도록 설계된 테스트 기법입니다. - -## 설계 검증 (Design Verification) - -애플리케이션 보안 아키텍처에 대한 기술 평가입니다. - -## 동적 검증(Dynamic Verification) - -취약점 시그니처를 사용하여 애플리케이션을 실행하는 동안 문제를 발견하는 자동 도구를 사용하여 확인합니다. - -## 전역 고유 식별자 (Globally Unique Identifier, GUID) - -소프트웨어에서 식별자로 사용되는 고유한 참조 번호입니다. - -## 하이퍼 텍스트 전송 프로토콜 (Hyper Text Transfer Protocol, HTTP) - -분산, 협업 및 하이퍼미디어 정보 시스템을 위한 애플리케이션 프로토콜입니다. 이것은 월드 와이드 웹을 위한 데이터 통신의 기초입니다. - -## 하드 코드 된 키(Hardcoded keys) - -장치 자체에 저장된 암호화 키입니다. - -## 프로세스 간 통신 (Inter Process Communications, IPC) - -프로세스가 다른 프로세스 또는 커널과 활동을 조율하기 위한 통신입니다. - -## 입력 검증(Input Validation) - -신뢰할 수 없는 사용자 입력에 대한 표준화 및 유효성 검사입니다. - -## JAVA 바이트 코드(JAVA Bytecode) - -Java 가상 머신(JVM)의 명령 세트입니다. 각각의 바이트 코드는 매개 변수를 전달하기 위한 0개 이상의 바이트와 함께 명령어(opcode)를 나타내는 1개 또는 2개 바이트로 구성됩니다. - -## 악성 코드(Malicious Code) - -개발 과정에서 애플리케이션의 의도된 보안 정책을 우회하기 위해 애플리케이션 소유자에게 잘 알려지지 않은 애플리케이션에 포함된 코드입니다. 바이러스나 웜과 같은 맬웨어와 동일하지 않습니다. - -## 맬웨어(Malware) - -애플리케이션 사용자와 관리자가 알지 못하세 런타임 동안 애플리케이션에 삽입되어 실행되는 코드입니다. - -## Open Web Application Security Project (OWASP) - -애플리케이션 소프트웨어의 보안을 향상시키는 데 초점을 맞춘 전 세계 무료 오픈 커뮤니티입니다. 우리의 사명은 사용자와 조직이 애플리케이션 보안 위험에 대한 정보에 근거한 결정을 내릴 수 있도록 애플리케이션 보안을 "가시성"있게 만드는 것입니다. 참조: - -## 개인 식별 정보(Personally Identifiable Information, PII) - -개인 식별 정보는 단독 또는 다른 정보와 함께 사용하여 정보주체를 식별, 접촉 또는 찾아내는 등 개인을 식별하는 데 사용할 수 있는 정보입니다. - -## 위치 독립 실행 형식 (Position-independent executable, PIE) - -기본 메모리의 어딘가에 배치되어 절대 주소에 관계없이 올바르게 실행되는 기계 코드의 본문입니다. - -## 공개 키 기반 구조 (Public Key Infrastructure, PKI) - -PKI는 공개 키를 엔터티의 각 ID와 바인딩하는 구조입니다. 바인딩은 인증기관(CA)의 인증서 등록 및 게시 프로세스에 의해 확립됩니다. - -## 정적 애플리케이션 보안 테스트 (Static Application Security Testing, SAST) - -보안 취약점을 나타내는 코딩 및 설계 조건에 대한 애플리케이션 소스 코드, 바이트 코드 및 이진 파일을 분석하기 위해 설계된 기술 모음입니다. SAST 솔루션은 애플리케이션을 비 작동 상태에서 구석구석까지 분석합니다. - -## SDLC - -소프트웨어 개발 라이프 사이클. - -## 보안 아키텍처 (Security Architecture) - -보안 통제가 사용되는 위치와 방법을 식별하고 기술하며, 사용자 및 애플리케이션 데이터의 위치와 민감도를 식별하고 기술하는 애플리케이션 설계의 추상화입니다. - -## 보안 설정 (Security Configuration) - -보안 통제 사용 방법에 영향을 미치는 애플리케이션의 런타임 설정입니다. - -## 보안 통제(Security Control) - -보안 점검(예 : 액세스 통제 점검)을 수행하거나 호출될 때 보안 효과(예 : 감사 레코드 생성)를 수행하는 기능 또는 구성 요소입니다. - -## SQL 인젝션(SQL Injection, SQLi) - -데이터 기반 애플리케이션을 공격하기 위해 악의적인 SQL문을 엔트리 포인트에 코드를 삽입하는 공격기법입니다. - -## 싱글 사인온 인증 (Single Sign On Authentication, SSO Authentication) - -사용자가 한 클라이언트에 로그인 한 후 사용자가 사용중인 플랫폼, 기술 또는 도메인에 관계없이 다른 클라이언트에 자동으로 로그인하는 것을 의미합니다. 예를 들어, 구글에 로그인하면 자동으로 유튜브, 드라이브, 메일 서비스에 로그인됩니다. - -## 위협 모델링(Threat Modeling) - -위협 에이전트, 보안 영역, 보안 통제, 중요한 기술 및 비즈니스 자산을 식별하기 위해 보다 정교한 보안 아키텍처를 개발하기 위한 기술입니다. - -## 전송 계층 보안(Transport Layer Security) - -인터넷을 통한 통신 보안을 제공하는 암호화 프로토콜입니다. - -## URI and URL - -URI는 이름 또는 웹 리소스를 식별하는 데 사용되는 문자열입니다. URL은 종종 자원에 대한 참조로 사용됩니다. - -## 사용자 수용 테스트 (User acceptance testing, UAT) - -운영 환경처럼 작동하도록 테스트 환경에서 프로덕션 전에 행해지는 모든 소프트웨어 테스트를 의미합니다. - -## 검토자(Verifier) - -OWASP MASVS 요구사항에 따라 신청서를 검토하는 사람 또는 팀을 의미합니다. - -## 화이트리스트(Whitelist) - -허용 된 데이터 또는 작업의 목록입니다. (예: 입력 유효성 검사를 수행할 수 있는 문자 목록) - -## X.509 인증서 (X.509 Certificate) - -X.509 인증서는 널리 사용되는 국제 X.509 공개 키 인프라(PKI) 표준으로, 공개 키 인증서에 포함 된 사용자, 컴퓨터 또는 서비스 ID에 속하는지 확인하는 디지털 인증서입니다. diff --git a/Document-ko/SUMMARY.md b/Document-ko/SUMMARY.md deleted file mode 100644 index e767a566f..000000000 --- a/Document-ko/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# 목차 - -- [변경이력](CHANGELOG.md) -- [서문](0x01-Foreword.md) -- [시작](0x02-Frontispiece.md) -- [MASVS 사용](0x03-Using_the_MASVS.md) -- [평가 및 인증](0x04-Assessment_and_Certification.md) - -## 보안 요구사항 - -- [V1: 아키텍처, 설계 및 위협 모델링 요구사항](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: 데이터 저장 및 개인정보 요구사항](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: 암호화 요구사항](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: 인증 및 세션 관리 요구사항](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: 네트워크 통신 요구사항](0x10-V5-Network_communication_requirements.md) -- [V6: 플랫폼 상호 작용 요구사항](0x11-V6-Interaction_with_the_environment.md) -- [V7: 코드 품질 및 빌드 설정 요구사항](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: 복원력 요구사항](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## 부록 - -- [부록 A - 용어집](GLOSSARY.md) -- [부록 B - 참고 자료](0x91-Appendix-B_References.md) diff --git a/Document-ko/book.json b/Document-ko/book.json deleted file mode 100644 index 544f95580..000000000 --- a/Document-ko/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "ko" -} diff --git a/Document-ko/images/CC-license.png b/Document-ko/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-ko/images/CC-license.png and /dev/null differ diff --git a/Document-ko/images/MASVS-levels.png b/Document-ko/images/MASVS-levels.png deleted file mode 100644 index 243abded4..000000000 Binary files a/Document-ko/images/MASVS-levels.png and /dev/null differ diff --git a/Document-ko/images/OWASP_logo.png b/Document-ko/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-ko/images/OWASP_logo.png and /dev/null differ diff --git a/Document-ko/images/license.png b/Document-ko/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-ko/images/license.png and /dev/null differ diff --git a/Document-ko/images/masvs-levels-new.jpg b/Document-ko/images/masvs-levels-new.jpg deleted file mode 100644 index 3b0c8db69..000000000 Binary files a/Document-ko/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-ko/images/masvs-mini-cover.jpg b/Document-ko/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-ko/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-ko/images/masvs-mini-cover.png b/Document-ko/images/masvs-mini-cover.png deleted file mode 100644 index 1e3d72f72..000000000 Binary files a/Document-ko/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-ko/metadata.md b/Document-ko/metadata.md deleted file mode 100644 index fbbd824ef..000000000 --- a/Document-ko/metadata.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'ko' # bug with polyglossia, switch back to english -languagetext: '(Korean Translation)' - -mainfont: 'Noto Sans' -sansfont: 'Noto Sans' -monofont: 'Noto Sans Mono' -CJKmainfont: 'Noto Sans CJK KR' - -# toc-title is translated when `lang` is correctly defined -toc-title: '목차' - ---- diff --git a/Document-ptbr/0x01-Foreword.md b/Document-ptbr/0x01-Foreword.md deleted file mode 100644 index 0f9ddaaef..000000000 --- a/Document-ptbr/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# 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 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? Mas não funciona 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 é 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 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, 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 _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 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 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 defesa (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 desenvolver 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 recomendado 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 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 diff --git a/Document-ptbr/0x02-Frontispiece.md b/Document-ptbr/0x02-Frontispiece.md deleted file mode 100644 index 424445199..000000000 --- a/Document-ptbr/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Sobre o Padrão - -![OWASP Logo](images/OWASP_logo.png) - -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 seguranç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: . - -Contas podem ser criadas a partir da seguinte URL: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Direitos de Uso e Licença - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Este documento é licenciado sob a licença [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). Para qualquer reuso ou redistribuição, você deve deixar claro os termos de licença deste trabalho. - - - -## Agradecimentos - -| Líderes de Projeto | Autor Principal | Colaboradores e Revisores -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 (Simplificado) | Bob Peng, Harold Zang, Jack S | -| Chinês (Tradicional) | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| 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| -| Português (Brasileiro) | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Russo | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Turco | Anıl Baş, Haktan Emik | -| Grego | Panagiotis Yialouris | - -Este documento começou como um _fork_ do Padrão de Verificação de Segurança de Aplicativos Móveis da OWASP escrito por Jim Manico. - -## Patrocinadores - -Ainda que tanto o MASVS quanto o MASTG tenham sido criados e mantidos pela comunidade de forma voluntária, às vezes é necessária uma pequena ajuda externa. Nós, portanto, 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 MASTG de maneira alguma. Os pacotes de patrocínio estão descritos em [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -Por fim, gostaríamos de agradecer a todos que compraram o livro no _[Leanpub](https://leanpub.com/mobile-security-testing-guide)_ e nos patrocinaram dessa maneira. diff --git a/Document-ptbr/0x03-Using_the_MASVS.md b/Document-ptbr/0x03-Using_the_MASVS.md deleted file mode 100644 index f50ec0351..000000000 --- a/Document-ptbr/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,85 +0,0 @@ -# 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 objetivos: - -- 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 desenvolvimento 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), assim 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 aplicativos 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 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 de segurança recomendadas 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ç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 subconjunto 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 operacional 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 descritos no _OWASP Mobile Application Security Testing Guide_ podem ser ignorados e nunca devem ser usados como substitutos de controles adicionais de proteção e específicos para ameaças a aplicativos que também atendem aos requisitos do MASVS no MASVS-L1 ou MASVS-L2.** - -![Níveis de Verificação](images/masvs-levels-new.jpg) - -### 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 MASTG: - -- *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 seguranç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 processo de teste deve estar em vigor para verificar os controles de segurança. Este nível é apropriado para todas as aplicações móveis. - -#### 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 todos 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 objetivo é 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 - -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 aplicativo 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 identificá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 consideraçõ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 segurança para evitar fraudes. Os aplicativos financeiros precisam garantir a conformidade 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 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 movimentar fundos, onde técnicas como injeção de código e instrumentação em dispositivos 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 dispositivos 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 servidor 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. diff --git a/Document-ptbr/0x04-Assessment_and_Certification.md b/Document-ptbr/0x04-Assessment_and_Certification.md deleted file mode 100644 index 246899873..000000000 --- a/Document-ptbr/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,49 +0,0 @@ -# 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 oficialmente 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, documentaçã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 remotos (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 resultados 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 notas 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 evidências suficientes de que todas as questões em nível de certificação foram testadas e 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 (MASTG) da OWASP - -O OWASP MASTG é um manual para testar a segurança dos aplicativos móveis. Descreve os processos técnicos para verificar os requisitos listados no MASVS. O MASTG 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 MASTG 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 principais 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 seguranç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. - -### 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 (MASTG) descreve os casos de teste de caixa preta e caixa branca para cada requisito de verificaçã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 melhora 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 seguros. 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. diff --git a/Document-ptbr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-ptbr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index c5560e3dd..000000000 --- a/Document-ptbr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# 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 desenvolvimento. 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 seguranç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 Application Security 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 identificados e conhecidos como necessários. | x | x | -| **1.2** | MSTG-ARCH-2 | Os controles de segurança nunca são aplicados apenas no lado do cliente, mas nos respectivos terminais remotos. | x | x | -| **1.3** | MSTG-ARCH-3 | Uma arquitetura de alto nível para o aplicativo móvel e todos os serviços remotos conectados foi definida e a segurança foi abordada nessa arquitetura. | x | x | -| **1.4** | MSTG-ARCH-4 | Os dados considerados confidenciais no contexto do aplicativo móvel são claramente identificados. | x | x | -| **1.5** | MSTG-ARCH-5 | Todos os componentes do aplicativo são definidos em termos das funções de negócios e/ou funções de segurança que eles fornecem. | | x | -| **1.6** | MSTG-ARCH-6 | Foram produzidos um modelo de ameaça para o aplicativo móvel e os serviços remotos associados, que identificam possíveis ameaças e contramedidas. | | x | -| **1.7** | MSTG-ARCH-7 | Todos os controles de segurança têm uma implementação centralizada. | | x | -| **1.8** | MSTG-ARCH-8 | Há uma política explícita sobre como as chaves 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. | | x | -| **1.9** | MSTG-ARCH-9 | Existe um mecanismo para aplicar atualizações do aplicativo móvel. | | x | -| **1.10** | MSTG-ARCH-10 | A segurança é abordada em todas as partes do ciclo de vida de desenvolvimento de software. | | x | -| **1.11** | MSTG-ARCH-11 | Uma responsável política de divulgação está em vigor e é efetivamente aplicada. | | x | -| **1.12** | MSTG-ARCH-12 | O aplicativo deve estar em conformidade com as leis e regulamentos de privacidade. | x | x | - -## Referências - -Para mais informações, consulte também (em inglês): - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-ptbr/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-ptbr/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 518f43b2a..000000000 --- a/Document-ptbr/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Requisitos de Armazenamento de Dados e Privacidade - -## Objetivo do Controle - -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 usados 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 dispositivos, 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 dispositivo, 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 exemplo: - -- 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 financeiros 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. - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Recursos de armazenamento de credenciais do sistema devem ser utilizados para armazenar dados sensíveis, como dados pessoais (PII), credenciais de usuário ou chaves criptográficas. | x | x | -| **2.2** | MSTG-STORAGE-2 | Dados sensíveis não devem ser armazenados fora do contêiner do aplicativo ou de recursos de armazenamento de credenciais do sistema. | x | x | -| **2.3** | MSTG-STORAGE-3 | Dados sensíveis não podem aparecer nos *logs* de aplicação. | x | x | -| **2.4** | MSTG-STORAGE-4 | Dados sensíveis não devem ser compartilhados com terceiros exceto se for uma parte necessária da arquitetura. | x | x | -| **2.5** | MSTG-STORAGE-5 | O _cache_ do teclado deve estar desabilitado nas entradas de usuário que processam dados sensíveis. | x | x | -| **2.6** | MSTG-STORAGE-6 | Dados sensíveis não devem ser expostos através de mecanismos IPC. | x | x | -| **2.7** | MSTG-STORAGE-7 | Dados sensíveis, como senhas ou PINs, não devem ser expostos através da interface de usuário. | x | x | -| **2.8** | MSTG-STORAGE-8 | Dados sensíveis não devem ser incluídos nos _backups_ gerados pelo sistema operacional móvel. | | x | -| **2.9** | MSTG-STORAGE-9 | O aplicativo deve remover dados sensíveis da visualização quando ficar em segundo plano. | | x | -| **2.10** | MSTG-STORAGE-10 | O aplicativo não deve manter dados sensíveis em memória mais tempo do que o necessário, e a memória deve ser completamente limpa depois do uso. | | x | -| **2.11** | MSTG-STORAGE-11 | O aplicativo deve reforçar o uso de políticas mínimas de segurança no acesso ao dispositivo, como pedir que o usuário defina um código de acesso ao dispositivo. | | x | -| **2.12** | MSTG-STORAGE-12 | O aplicativo deve ensinar o usuário sobre os 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. | x | x | -| **2.13** | MSTG-STORAGE-13 | Dados sensíveis não devem ser armazenados 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. | | x | -| **2.14** | MSTG-STORAGE-14 | Se ainda assim for necessário armazenar dados pessoais localmente, eles devem ser cifrados utilizando uma chave derivada do armazenamento suportado pelo _hardware_ que requeira autenticação. | | x | -| **2.15** | MSTG-STORAGE-15 | O armazenamento local do aplicativo deve ser completamente apagado (_wipe_) após um número excessivo de tentativas de autenticação sem sucesso. | | x | - -## Referências - -O Guia de Teste de Segurança de Aplicações Móveis da OWASP provê instruções detalhadas para verificar os requerimentos listados nesta seção (em inglês). - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -Para mais informações, veja também (em inglês): - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-ptbr/0x08-V3-Cryptography_Verification_Requirements.md b/Document-ptbr/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index f5dc269c2..000000000 --- a/Document-ptbr/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Requisitos de Criptografia - -## Objetivo do Controle - -A criptografia é um componente essencial quando se trata da proteção dos dados armazenados 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 criptografia 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. - -## Requisitos de Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | O aplicativo não se baseia em criptografia simétrica com chaves fixas no código fonte como único método de criptografia. | x | x | -| **3.2** | MSTG-CRYPTO-2 | O aplicativo usa implementações comprovadas de primitivas criptográficas. | x | x | -| **3.3** | MSTG-CRYPTO-3 | O aplicativo usa primitivas criptográficas que 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. | x | x | -| **3.4** | MSTG-CRYPTO-4 | O aplicativo não utiliza protocolos criptográficos ou algoritmos que são considerados amplamente obsoletos para uso em segurança. | x | x | -| **3.5** | MSTG-CRYPTO-5 | O aplicativo não reutiliza a mesma chave criptográfica para vários fins. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Todos os valores aleatórios são gerados usando um gerador de números aleatórios suficientemente seguro. | x | x | - -## Referências - -O Guia de Teste de Segurança de Aplicações Móveis da OWASP fornece instruções detalhadas para verificar os requisitos listados nesta seção (em inglês). - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -Para mais informações, consulte também (em inglês): - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-ptbr/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-ptbr/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 69aeebcc0..000000000 --- a/Document-ptbr/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Requisitos de Autenticação e Gerenciamento de Sessão - -## Objetivo do Controle - -Na maioria dos casos, o _login_ de usuários a um serviço remoto é parte integrante da arquitetura global das aplicações móveis. Embora a maior parte da lógica aconteça no terminal, o MASVS define alguns requisitos básicos sobre a forma como as contas e sessões dos usuários devem ser gerenciadas. - -## Requisitos de Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Se o aplicativo fornecer aos usuários acesso a um serviço remoto, alguma forma de autenticação, como autenticação de nome de usuário e senha, será executada no terminal remoto. | x | x | -| **4.2** | MSTG-AUTH-2 | Se o gerenciamento de sessão com estado for 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. | x | x | -| **4.3** | MSTG-AUTH-3 | Se a autenticação baseada em _token_ sem estado for usada _(stateless token-based authentication)_, o servidor fornecerá um _token_ que foi assinado usando um algoritmo seguro. | x | x | -| **4.4** | MSTG-AUTH-4 | O _endpoint_ remoto termina a sessão existente quando o usuário efetuar _logout_. | x | x | -| **4.5** | MSTG-AUTH-5 | Uma política de senha existe e é imposta no terminal remoto. | x | x | -| **4.6** | MSTG-AUTH-6 | O terminal remoto implementa um mecanismo para proteger contra o envio de credenciais em um número excessivo. | x | x | -| **4.7** | MSTG-AUTH-7 | As sessões são invalidadas pelo terminal remoto após um período predefinido de inatividade e os _tokens_ de acessos expiram. | x | x | -| **4.8** | MSTG-AUTH-8 | A autenticação biométrica, se houver, não é 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). | | x | -| **4.9** | MSTG-AUTH-9 | Existe um segundo fator de autenticação no terminal remoto e o requisito de 2FA é aplicado de maneira consistente. | | x | -| **4.10** | MSTG-AUTH-10 | Transações confidenciais requerem autenticação adicional. | | x | -| **4.11** | MSTG-AUTH-11 | O aplicativo informa o usuário de todas as 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. | | x | -| **4.12** | MSTG-AUTH-12 | Os modelos de autorização devem ser definidos e aplicados no terminal remoto. | x | x | - -## Referências - -O Guia de Teste de Segurança de Aplicações Móveis da OWASP fornece instruções detalhadas para verificar os requisitos listados nesta seção (em inglês). - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -Para mais informações, consulte também (em inglês): - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-ptbr/0x10-V5-Network_communication_requirements.md b/Document-ptbr/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 44abbe1d4..000000000 --- a/Document-ptbr/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Requisitos de Comunicação de Rede - -## Objetivo do Controle - -O propósito dos controles listados nessa seção é garantir a confidencialidade e integridade 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 comunicaçã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_). - -## Requisitos de Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Os dados são criptografados na rede utilizando TLS. O canal seguro é utilizado de forma consistente através do aplicativo. | x | x | -| **5.2** | MSTG-NETWORK-2 | As configurações do TLS estão alinhadas com as 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. | x | x | -| **5.3** | MSTG-NETWORK-3 | O aplicativo verifica o certificado X.509 do terminal remoto quando o canal seguro é estabelecido. Apenas certificados assinados por uma CA confiável são aceitos. | x | x | -| **5.4** | MSTG-NETWORK-4 | O aplicativo utiliza seu próprio armazenamento 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. | | x | -| **5.5** | MSTG-NETWORK-5 | O aplicativo não confia em um único canal de comunicações inseguro (email ou SMS) para operações críticas, como registros/cadastros ou recuperação de conta. | | x | -| **5.6** | MSTG-NETWORK-6 | O aplicativo depende de conectividade e bibliotecas de segurança atualizadas. | | x | - -## Referências - -O Guia de Teste de Segurança de Aplicações Móveis da OWASP provê instruções detalhadas para verificar os requerimentos listados nesta seção (em inglês). - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -Para mais informações, veja também (em inglês): - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-ptbr/0x11-V6-Interaction_with_the_environment.md b/Document-ptbr/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index ea1689159..000000000 --- a/Document-ptbr/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Requisitos de Interação com a Plataforma - -## Objetivo de Controle - -Os controles deste grupo garantem que o aplicativo use APIs da plataforma e componentes padrão de forma segura. Além disso, os controles cobrem a comunicação entre aplicativos (IPC). - -## Requisitos de Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | O aplicativo só solicita o conjunto mínimo de permissões necessárias. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Todas as entradas de fontes externas e do 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.| x | x | -| **6.3** | MSTG-PLATFORM-3 | O aplicativo não exporta funcionalidades sensíveis através de esquemas de URL personalizado, a menos que esses mecanismos estejam devidamente protegidos. | x | x | -| **6.4** | MSTG-PLATFORM-4 | O aplicativo não exporta funcionalidades sensíveis através do IPC, a menos que esses mecanismos estejam devidamente protegidos. | x | x | -| **6.5** | MSTG-PLATFORM-5 | Código JavaScript é desativado nos _WebViews_, a menos que explicitamente necessário. | x | x | -| **6.6** | MSTG-PLATFORM-6 | O _WebViews_ está configurado para permitir 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. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Se os métodos nativos do aplicativo forem expostos a um _WebView_, verifique se o _WebView_ só renderiza o código JavaScript contido no pacote do aplicativo. | x | x | -| **6.8** | MSTG-PLATFORM-8 | A desserialização de objetos, se houver, é implementada usando APIs de serialização seguras. | x | x | -| **6.9** | MSTG-PLATFORM-9 | O aplicativo se protege contra ataques de sobreposição de tela. (somente para Android) | | x | -| **6.10** | MSTG-PLATFORM-10 | O _cache_, o armazenamento e os recursos carregados (JavaScript, etc.) devem ser eliminados antes que o _WebView_ seja destruído. | | x | -| **6.11** | MSTG-PLATFORM-11 | Verifique se o aplicativo impede o uso de teclados de terceiros personalizados sempre que dados confidenciais são inseridos. (somente para iOS) | | x | - -## References - -O Guia de Teste de Segurança Móvel da OWASP fornece instruções detalhadas para verificar os requisitos listados nesta seção (em inglês). - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -Para mais informações, veja (em inglês): - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-ptbr/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-ptbr/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 2c2bdf6fa..000000000 --- a/Document-ptbr/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Requisitos de Qualidade de Código e Configuração do Compilador - -## Objetivo do Controle - -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. - -## Requisitos de Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | O aplicativo é assinado e disponibilizado com um certificado válido e cuja chave privada está devidamente protegida. | x | x | -| **7.2** | MSTG-CODE-2 | O aplicativo foi criado em modo de _release_ e com as configurações apropriadas para ela (ex.: _non-debuggable_). | x | x | -| **7.3** | MSTG-CODE-3 | Os símbolos de depuração foram removidos dos binários nativos. | x | x | -| **7.4** | MSTG-CODE-4 | Todo código de depuração e de assistência ao 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. | x | x | -| **7.5** | MSTG-CODE-5 | Todos componentes de terceiros utilizados pelo aplicativo móvel, como blibliotecas e _frameworks_, são identificados e revisados quanto às vulnerabilidades conhecidas. | x | x | -| **7.6** | MSTG-CODE-6 | O aplicativo captura e trata devidamente as possíveis exceções. | x | x | -| **7.7** | MSTG-CODE-7 | Os controles de segurança não permitem acesso por padrão no tratamento de erros. | x | x | -| **7.8** | MSTG-CODE-8 | No código não gerenciado a memória é alocada, liberada e usada com segurança. | x | x | -| **7.9** | MSTG-CODE-9 | As funcionalidades de segurança gratuitas das ferramentas, tais como minificação do _byte-code_, proteção de pilha, suporte PIE e contagem automática de referência, devem estar habilitadas. | x | x | - -## 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 - -- iOS: Testing Code Quality and Build Settings - - -Para mais informações, veja também (em inglês): - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-ptbr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-ptbr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index d4d8fa0b2..000000000 --- a/Document-ptbr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,70 +0,0 @@ -# V8: Requisitos de Resiliência - -## Objetivo do Controle - -Esta seção cobre as medidas de proteção recomendadas para aplicativos móveis que processam, 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 aumentar 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 "_Technical Risks of Reverse Engineering and Unauthorized Code Modification_" e "_Reverse Engineering 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. - -**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 atacante 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 experiê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 protections_" no Guia de Teste de Segurança de Dispositivos Móveis). - - - -### 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 de um dispositivo com _root_ ou _jailbreak_ alertando o usuário ou fechando o aplicativo. | x | -| **8.2** | MSTG-RESILIENCE-2 | O aplicativo previne a depuração e/ou detecta e reponde a ela. Todos os protocolos de depuração disponíveis devem ser cobertos. | x | -| **8.3** | MSTG-RESILIENCE-3 | O aplicativo detecta e responde para a manipulação de executáveis e dados críticos do próprio aplicativo. | x | -| **8.4** | MSTG-RESILIENCE-4 | O aplicativo detecta e responde para a presença no dispositivo de ferramentas de engenharia reversa e _frameworks_ amplamente utilizados. | x | -| **8.5** | MSTG-RESILIENCE-5 | O aplicativo detecta e responde para quando executada em um emulador. | x | -| **8.6** | MSTG-RESILIENCE-6 | O aplicativo detecta e responde para manipulação de código e dados em seu espaço de memória. | x | -| **8.7** | MSTG-RESILIENCE-7 | O aplicativo implementa múltiplos mecanismos 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. | x | -| **8.8** | MSTG-RESILIENCE-8 | Os mecanismos de detecção provocam diferentes tipos de respostas, inclusive respostas tardias e silenciosas. | x | -| **8.9** | MSTG-RESILIENCE-9 | A ofuscação é aplicada às defesas do programa que, por sua vez, impede a desofuscação por meio de análise dinâmica. | x | - -### Vinculação ao Dispositivo - -| # | MSTG-ID | Descrição | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | O aplicativo implementa uma funcionalidade de 'vinculação ao dispositivo' usando um identificador único derivado de múltiplas propriedades únicas do dispositivo. | x | - - - -### Impedir a Compreensão - -| # | MSTG-ID | Descrição | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Todos os arquivos executáveis e bibliotecas 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. | x | -| **8.12** | MSTG-RESILIENCE-12 | Se o objetivo da ofuscação é proteger códigos 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. | x | - -### Impedir o _Eavesdropping_ - -| # | MSTG-ID | Descrição | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Como defesa mais forte, além de ter um sólido 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_. | x | - - - -## 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 - -- iOS: Testing Resiliency Against Reverse Engineering - - -Para mais informação, veja também (em inglês): - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-ptbr/0x90-Appendix-A_Glossary.md b/Document-ptbr/0x90-Appendix-A_Glossary.md deleted file mode 100644 index fbab2a8ae..000000000 --- a/Document-ptbr/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,41 +0,0 @@ -# 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 també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 automaticamente, independente da plataforma, tecnologia ou domínio que o usuário está utilizando. Por exemplo, quando você se autentica no Google você será autenticado 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 representam 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 dispositivo. -- **Código Malicioso** - Código introduzido dentro da aplicação durante o seu desenvolvimento 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 interfaces 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 encontrada 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 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 Autoridade Certificadora (CA). -- **Injeção de SQL (SQLi)** - Uma técnica de injeção de código usada para atacar aplicaçõ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 exemplo 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 desenvolver 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 algoritmos 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: . -- **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 erros de corrupção da memória. -- **Relatório de Verificação da Segurança de Aplicações** - Um relatório que documenta 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)** - Protocolos 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 tecnologias planejadas para analisar o código fonte, *bytecode* e binários de uma aplicação para identificar condições de codificação e planejamento que sejam indicativos 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 ferramentas 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 assinaturas 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. diff --git a/Document-ptbr/0x91-Appendix-B_References.md b/Document-ptbr/0x91-Appendix-B_References.md deleted file mode 100644 index 12e23d747..000000000 --- a/Document-ptbr/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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/](https://owasp.org/www-project-mobile-security/) -- Guia OWASP de Teste de Segurança em Dispositivos Móveis - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Top 10 Riscos em Dispositivos Móveis - [https://owasp.org/www-project-mobile-top-10/](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_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_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/](http://cwe.mitre.org/) -- Conselho PCI de Padrões de Segurança (em português) - [https://pt.pcisecuritystandards.org/](https://pt.pcisecuritystandards.org/) -- Padrão PCI de Segurança de Dados (PCI-DSS) v3.2.1 Requisitos e Procedimentos de Avaliação de Segurança - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-ptbr/CHANGELOG.md b/Document-ptbr/CHANGELOG.md deleted file mode 100644 index 997cf9d3c..000000000 --- a/Document-ptbr/CHANGELOG.md +++ /dev/null @@ -1,95 +0,0 @@ -# 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent 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 adicionados com foco em proteção de dados. -- 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 implementarem 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 Responsável para aplicações L2. -- Requisito MSTG-ARCH-12 foi adicionado para mostrar aos desenvolvedores de aplicaçõ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 (*eavesdropping*) 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. - -## 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 - -As seguintes alterações fazem parte da versão 1.1: - -- 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 contêiner do aplicativo ou de recursos de armazenamento de credenciais do sistema". -- Requisito 2.1 foi reescrito para "Recursos de armazenamento de credenciais do sistema devem ser utilizados para armazenar dados sensíveis, como Dados de Identificação Pessoal (PII), credenciais de usuário ou chaves criptográficas." - -## V1.0 - 12 de Janeiro de 2018 - -As seguintes alterações fazem parte da versão 1.0: - -- 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.). diff --git a/Document-ptbr/GLOSSARY.md b/Document-ptbr/GLOSSARY.md deleted file mode 100644 index 10b71c0e6..000000000 --- a/Document-ptbr/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# 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 també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 automaticamente, independente da plataforma, tecnologia ou domínio que o usuário está utilizando. Por exemplo, quando você se autentica no Google você será autenticado 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 representam 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 dispositivo. - -## Código Malicioso - -Código introduzido dentro da aplicação durante o seu desenvolvimento 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 interfaces 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 encontrada 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 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 Autoridade Certificadora (CA). - -## Injeção de SQL (SQLi) - -Uma técnica de injeção de código usada para atacar aplicaçõ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 exemplo 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 desenvolver 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 algoritmos 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: . - -## 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 erros de corrupção da memória. - -## Relatório de Verificação da Segurança de Aplicações - -Um relatório que documenta 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) - -Protocolos 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 tecnologias planejadas para analisar o código fonte, *bytecode* e binários de uma aplicação para identificar condições de codificação e planejamento que sejam indicativos 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 ferramentas de análise dinâmica, ferramentas de análise estática, quanto ambas) que usam assinaturas de vulnerabilidade para identificar problemas. - -## Verificação de *Design* - -Avaliação técnica da arquitetura de segurança de uma aplicação. - -## 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 assinaturas 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. diff --git a/Document-ptbr/SUMMARY.md b/Document-ptbr/SUMMARY.md deleted file mode 100644 index 560173000..000000000 --- a/Document-ptbr/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Lista de Conteúdos - -- [Controle de Alterações](CHANGELOG.md) -- [Prefácio](0x01-Foreword.md) -- [Frontispício](0x02-Frontispiece.md) -- [Usando o MASVS](0x03-Using_the_MASVS.md) -- [Avaliação e Certificação](0x04-Assessment_and_Certification.md) - -## Requisitos de Segurança - -- [V1: Requisitos de Arquitetura, Design e Modelagem de Ameaças](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Requisitos de Armazenamento de Dados e Privacidade](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Requisitos de Criptografia](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Requisitos de Autenticação e Gerenciamento de Sessão](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Requisitos de Comunicação de Rede](0x10-V5-Network_communication_requirements.md) -- [V6: Requisitos de Interação com a Plataforma](0x11-V6-Interaction_with_the_environment.md) -- [V7: Requisitos de Qualidade de Código e Configuração do Compilador](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Requisitos de Resiliência](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Apêndice - -- [Apêndice A - Glossário](GLOSSARY.md) -- [Apêndice B - Referências](0x91-Appendix-B_References.md) diff --git a/Document-ptbr/book.json b/Document-ptbr/book.json deleted file mode 100644 index e01dd0b66..000000000 --- a/Document-ptbr/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "ptbr" -} diff --git a/Document-ptbr/images/CC-license.png b/Document-ptbr/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-ptbr/images/CC-license.png and /dev/null differ diff --git a/Document-ptbr/images/MASVS-levels.png b/Document-ptbr/images/MASVS-levels.png deleted file mode 100644 index f27278243..000000000 Binary files a/Document-ptbr/images/MASVS-levels.png and /dev/null differ diff --git a/Document-ptbr/images/OWASP_logo.png b/Document-ptbr/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-ptbr/images/OWASP_logo.png and /dev/null differ diff --git a/Document-ptbr/images/license.png b/Document-ptbr/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-ptbr/images/license.png and /dev/null differ diff --git a/Document-ptbr/images/masvs-levels-new.jpg b/Document-ptbr/images/masvs-levels-new.jpg deleted file mode 100644 index 054f91bd3..000000000 Binary files a/Document-ptbr/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-ptbr/images/masvs-mini-cover.jpg b/Document-ptbr/images/masvs-mini-cover.jpg deleted file mode 100644 index 81663c3ff..000000000 Binary files a/Document-ptbr/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-ptbr/images/masvs-mini-cover.png b/Document-ptbr/images/masvs-mini-cover.png deleted file mode 100644 index 58dba8003..000000000 Binary files a/Document-ptbr/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-ptbr/metadata.md b/Document-ptbr/metadata.md deleted file mode 100644 index 16a5a3380..000000000 --- a/Document-ptbr/metadata.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'pt-BR' -languagetext: '(Brazilian Portuguese Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: "Índice" - ---- diff --git a/Document-ptpt/0x01-Foreword.md b/Document-ptpt/0x01-Foreword.md deleted file mode 100644 index 0245436d9..000000000 --- a/Document-ptpt/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Prefácio - -Revoluções tecnológicas podem acontecer muito rápido. Há menos de uma década atrás, os smartphones eram dispositivos desajeitados com pequenos teclados - brinquedos caros para utilizadores de empresas altamente tecnológicas. Hoje os smartphones são uma parte essencial das nossas vidas. Tornamo-nos dependentes deles para aceder à informação, comunicar e nos deslocarmos, e passaram a estar sempre presentes na nossa vida, tanto social como profissional. - -Toda nova tecnologia apresenta novos riscos de segurança e acompanhar essas mudanças é um dos principais desafios que a indústria da segurança enfrenta. O lado defensivo está sempre uns passos atrás. Por exemplo, uma prática comum para muitos foi aplicar formas ultrapassadas de fazer as coisas: os smartphones são como pequenos computadores, e as aplicação móveis são como software clássico, então certamente os requisitos de segurança são similares? Não, não é assim que funciona. Os sistemas operativos dos smartphones são diferentes dos sistemas operativos dos computadores de secretária e as aplicações móveis são diferentes das aplicações web. Por exemplo, o método clássico de procura de vírus baseado em assinaturas não faz sentido em ambientes de sistemas operativos móveis modernos, não é só incompatível com o modelo de distribuição de aplicações móveis, como também é tecnicamente impossível devido a restrições de sandboxing. Algumas classes de vulnerabilidades tais com buffer overflows e XSS são menos relevantes no contexto das aplicações móveis do que o são em aplicações web ou em aplicações Desktop (existem exceções). - -Com o tempo, a nossa indústria percebeu melhor cenário das ameaças móveis. Como se vê, a segurança móvel tem tudo a ver com proteção de dados: as aplicações guardam a nossa informação pessoal, fotos, gravações, notas, dados de contas, informações de negócio, localização e muito mais. Elas atuam como clientes que nos ligam aos serviços que usamos diariamente e como centros de comunicação que processam toda e cada uma das mensagens que trocamos com os outros. Comprometer o smartphone de uma pessoa permite o acesso sem restrições à vida pessoal dessa pessoa. Quando consideramos a facilidade com que dispositivos móveis se perdem ou são roubados juntamente com a ascensão do malware móvel, a necessidade da proteção de dados torna-se mais evidente. - -Um padrão de segurança para aplicações móveis deve portanto focar-se na forma como as aplicações manipulam, guardam e protegem a informação sensível. Embora os sistemas operativos móveis modernos, como iOS e Android ofereçam boas interfaces de programador (APIs) para o armazenamento e comunicação seguros de dados, eles precisam der ser implementados e usados corretamente para serem eficazes. O armazenamento de dados, a comunicação entre aplicações, o uso adequado de APIs criptográficas e a comunicação de rede de forma segura são apenas alguns aspetos que requerem um especial cuidado. - -Uma questão importante que precisa de consenso da indústria é até que ponto é que se deve ir para proteger a confidencialidade e integridade dos dados. Por exemplo, a maioria de nós iria concordar que as aplicações móveis devem verificar os certificados do servidor numa troca de TLS. Mas e a fixação de certificados SSL? O não faze-lo pode resultar numa vulnerabilidade? Isso deve ser um requisito quando a aplicação lida com informação sensível, ou é talvez até contraproducente? Precisamos de cifrar dados armazenados em bases de dados SQLite, mesmo que o SO execute a aplicação numa sandbox? O que é apropriado para uma aplicação pode não ser realista para outra. O MASVS é uma tentativa de padronizar esses requisitos usando níveis de verificação que se ajustam aos diferentes cenários de ameaças. - -Além disso, o surgimento de root malware e ferramentas de administração remota criou a consciencialização para o facto de os próprios sistemas operativos móveis terem falhas exploráveis, portanto as estratégias de containerização são cada vez mais usadas para se proporcionar proteção adicional aos dados sensíveis e prevenir a adulteração no lado do cliente. -É aqui que as coisas ficam complicadas. Recursos de segurança suportados por hardware e soluções containerizadas ao nível do SO, como Android for Work e Samsung Knox, existem, mas não estão disponíveis de forma consistente entre dispositivos diferentes. Tal como um curativo, é possível implementar medidas de proteção baseadas em software - mas, infelizmente, não existem padrões ou processos de teste para verificar esses tipos de proteções. - -Como resultado, os relatórios de testes de segurança de aplicações móveis estão por todo lado: por exemplo, alguns testers relatam a falta de ofuscação ou deteção de root nas aplicações Android como uma "falha de segurança". Por outro lado, medidas como encriptação de string, deteção de depuração ou ofuscação de controlo de fluxo não são consideradas obrigatórias. Contudo, essa forma binária de olhar para as coisas não faz sentido porque a resiliência não é uma proposição binária: depende das ameaças especificas do cliente que queremos defender. As proteções de software não são inúteis, mas podem eventualmente ser ultrapassadas, portanto nunca devem ser usadas como substituto de controlos de segurança. - -O objetivo geral do MASVS é oferecer um ponto de partida para a segurança de aplicações móveis (MASVS-L1), enquanto permite a introdução de medidas de defesa em profundidade (MASVS-L2) e proteções contra ameaças do cliente (MASVS-R). O MASVS via atingir o seguinte: - -- Fornecer requisitos para arquitetos e programadores de software que procuram desenvolver aplicações móveis seguras. -- Oferecer um padrão da indústria que possa ser testado nas revisões de segurança de aplicações móveis. -- Esclarecer o papel dos mecanismos de proteção de software na segurança de aplicações móveis e fornecer requisitos para verificar a sua eficácia. - -Estamos cientes que é impossível atingir um consenso de 100% na indústria. No entanto, esperamos que o MASVS seja útil para fornecer orientação em todas as fases do desenvolvimento e teste de aplicações móveis. Como um padrão de código aberto, o MASVS evoluirá com o tempo e agradecemos quaisquer contribuições e sugestões. - -Por Bernhard Mueller diff --git a/Document-ptpt/0x02-Frontispiece.md b/Document-ptpt/0x02-Frontispiece.md deleted file mode 100644 index 9cc2dd88c..000000000 --- a/Document-ptpt/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Sobre as Normas - -![OWASP Logo](images/OWASP_logo.png) - -Bem-vindo ao Mobile Application Security Verification Standard (MASVS). O MASVS é uma comunidade que reúne esforços no sentido de estabelecer uma framework de requisitos de segurança necessários para o design, desenvolvimento e teste de aplicações móveis seguras, em iOS e Android. - -O MASVS é o culminar do esforço comunitário aliado ao feedback da própria indústria. A nossa expectativa é que este conjunto de normas evolua ao logo do tempo e encorajamos toda a comunidade a dar o seu feedback. - -A melhor forma de entrar em contacto connosco é através do canal de slack OWASP Mobile Project: . - -Para criar uma conta basta clicar no seguinte URL: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Direitos de autor e Licença - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation.Este documento está licenciado pela [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/). Para reutilização e distribuição é necessário expor de forma clara os termos da licença. - - - -## Agradecimentos - -| Lider do Projecto | Autor Principal | Contribuidores e Revisores -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Idioma | Tradutores & Revisores | -| --------------- | ------------------------------------------------------------ | -| Chinês (Traditonal) | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| Chinês (Simplificado) | Bob Peng, Harold Zang, Jack S | -| Francês | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Revisão) | -| Alemão | Rocco Gränitz, Sven Schleier (Revisão) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| Japonês | Koki Takeyama, Riotaro Okada (Revisão) | -| Coreano | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| Persa | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari | -| Russo | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Espanhol | Martin Marsicano, Carlos Holguera | -| Portugês | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Português (Brasileiro) | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Turco | Anıl Baş, Haktan Emik | -| Grego | Panagiotis Yialouris | - -Este documento começou como um fork do OWASP Application Security Verification Standard produzido por Jim Manico. - -## Patrocinadores - -Apesar de tanto o MASVS como o MASTG terem sido criados e mantidos por uma equipa de voluntários, por vezes é necessária alguma ajuda externa. Nesse sentido, queremos agradecer a todos os patrocinadores que contribuíram com os fundos necessários para a contratação de editores técnicos. O patrocínio disponibilizado não influencia, no entanto, o conteúdo publicado quer no MASVS ou no MASTG em nenhuma forma. Os patrocínios estão descritos em [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -E por fim, gostaríamos, ainda, de agradecer a todos aqueles que nos patrocinaram de forma indireta, adquirindo o livro através da [Leanpub](https://leanpub.com/mobile-security-testing-guide). diff --git a/Document-ptpt/0x03-Using_the_MASVS.md b/Document-ptpt/0x03-Using_the_MASVS.md deleted file mode 100644 index 7980a7821..000000000 --- a/Document-ptpt/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,85 +0,0 @@ -# O Mobile Application Security Verification Standard - -O MASVS pode ser usado para estabelecer um nível de confiança na segurança de aplicações móveis. Os requisitos foram estabelecidos tendo em conta os seguintes objetivos: - -- Usar como uma métrica - Para providenciar um padrão de segurança com o qual as aplicações móveis podem ser comparadas pelos programadores e proprietários das aplicações; -- Usar como um guia - Para orientar durante todas as fases de desenvolvimento e teste das aplicações móveis; -- Usar durante o aprovisionamento - Para fornecer um ponto de partida para a verificação da segurança das aplicações móveis. - -## Modelo de Segurança em Aplicações Móveis - -O MASVS define dois níveis de verificação de segurança (MASVS-L1 e MASVS-L2), bem como um conjunto de requisitos de resiliência de engenharia reversa (MASVS-R). O MASVS-L1 contém requisitos de segurança genéricos recomendados para todas as aplicações móveis, enquanto que o MASVS-L2 deve ser aplicado a aplicações que lidam com dados extremamente sensíveis. O MASVS-R cobre os controlos de proteção adicional que podem ser aplicados para prevenir vulnerabilidades do lado do cliente, caso isso seja um objectivo. - -Cumprir os requisitos em MASVS-L1 resulta numa aplicação segura que segue as melhores práticas de segurança e que não sofre vulnerabilidades comuns. o MASVS-L2 adiciona controlos para uma maior profundidade na defesa como SSL pinning, que resulta numa aplicação resiliente contra ataques mais sofisticados - assumindo que os controlos de segurança do sistema operativo móvel estão intactos e que o utilizador final não é visto como um potencial adversário. Satisfazer todos os requsitos de proteção do software em MASVS-R, ou subgrupos, ajuda a impedir riscos especificos nos quais o utilzador final é malicioso e/ou o sistema operativo móvel está comprometido. - -**I: Ainda que a nossa recomendação seja implementar os controlos MASVS-L1 em todas as aplicações, aplicar um controlo efectivamente ou não deverá ser em último caso uma decisão baseada no risco, que é decidida/comunicada com os seus proprietários.** - -**II: De notar que os controlos de proteção de software listados em MASVS-R e descritos no OWASP Mobile Application Security Testing Guide podem em última instância ser contornados e nunca ser usados como substitutos para os controlos de segurança. Em vez disso, eles têm como propósito adicionarameças controlos de proteção a ameaças específicas em aplicações que também cumpram os requistos MASVS em MASVS-L1 e MASVS-L2.** - -![Níveis de Verificação](images/masvs-levels-new.jpg) - -### Estrutura do Documento - -A primeira parte do MASVS contaem uma descrição do modelo de segurança e respectivos níveis de verificaçãos disponiveis, seguido de recomendações acerca da utilização do modelo na prática. Os requisitos de segurança detalhados, bem como o mapeamento com os níveis de verificação, estão listados na segunda parte. Os requsitos foram agrupados em oito categorias (V1 ao V8) consoante os objectivos tecnicos e o âmbito. A seguinte numencatura é usada ao longo do MASVS e do MASTG: - -- *Categoria do requisito:* MASVS-Vx, ex MASVS-V2: Armazenamento de dados e privacidade -- *Requisito:* MASVS-Vx.y, ex MASVS-V2.2: "Nenhuma informação sensível está a ser escrita nos logs." - -### Níveis de Verificação em Detalhe - -#### MASVS-L1: Padrão de Segurança - -Uma apllicação móvel que atinga o MASVS-L1 aceita as melhores práticas de segurança. Preenche requisitos básicos em termos de qualidade de código, tratamento de informação sensível, e interação com o ambiente móvel. Deve ser implementado um processo de teste para verificar os controlos de segurança. Este nível é apropriado para todas as aplicações móveis. - -#### MASVS-L2: Defesa em Profundidade - -O nível MASVS-L2 introduz controlos de segurança avançados que vão para além dos requisitos padrão. Para estar em concordância com o MASVS-L2, deve existir um modelo de ataque e a segurança deve ser parte integral da arquitetura e desenho da aplicação. Baseado no modelo de ataque, devem ser escolhidos os controlos MASVS-L2 corretos e implementados com sucesso. Este nível é apropriado para aplicações que lidam com grandes volumes de dados sensíveis, como aplicações bancárias. - -#### MASVS-R: Resiliência Contra Engenharia Reversa e Adulteração - -A aplicação tem segurança de ponta, e também é resiliente contra ataques específicos e claramente definidos do lado do cliente, como adulteração, alteração da aparência ou engenharia reversa para extrair código ou informação sensivel. Uma aplicação deste género ou deverá possuir recursos de hardware de segurança ou técnicas de proteção suficientemente fortes e verificáveis. O MASVS-R é extensível a todas as aplicações que lidam com grandes volumes de dados sensíveis e podem servir como um meio de proteção de propriedade intelectual ou tornar uma aplicação inviolável. - -### Uso Recomendado - -As aplicações podem ser testadas para MASVS L1 ou L2 com base numa avaliação de risco e no nível global de segurança requerido. O nível L1 é aplicável a todas as aplicações móveis, enquanto que o L2 é recomendado em geral para aplicações que operam com dados ou fincionalidades mais sensivéis. Os MASVS-R(ou uma parte deles) podem ser aplicados para verificar resiliência contra ameaças especificas, como reempacotar a aplicação ou extrair dados sensiveis, *em adição* a verificação de segurança apropriada. - -Em resumo, estão disponíveis os seguintes tipos de verificação: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -As diferentes combinações refletem diferentes níveis de segurança e resiliência. O objetivo é permitir flexibilidade: por exemplo, um jogo de télemovel pode não justificar a adição dos controlos de segurança de MASVS-L2, como a verificação de dois fatores, por razões de usabilidade, mas ter uma forte necessidade comercial de prevenção de falsificação. - -#### Que Tipo de Verificação Escolher - -Implementar os requisitos do MASVS L2 aumenta a segurança, enquanto que ao mesmo tempo aumenta o custo de desenvolvimento e diminui potencialmente a usabilidade para o utilizador final (o clássico conflito de escolha). Em geral, o L2 deve ser usado para aplicaçãos sempre que faça sentido do ponto de vista risco *versus* perpectiva de custo (ex quando a potencial perda causada pelo compromisso de confidencialidade ou integridade é maior que o custo incorrido pelos adicionais controlos de segurança). Uma avaliação do risco deve ser o primeiro passo antes de aplicar o MASVS. - -##### Exemplos - -###### MASVS-L1 - -- Todas as aplicações móveis. O MASVS-L1 lista as melhores práticas de segurança que podem ser seguidas com um impacto razoável no custo do desenvolvimento e na experiência do utilizador. Aplique os requisitos em MASVS-L1 para qualquer aplicação que não se qualificar para um dos níveis mais altos. - - - -###### MASVS-L2 - -- Indústria da Saúde: aplicações móveis que guardam informação pessoal e identificável que pode ser usada para roubo de identidade, pagamentos fraudulentos, ou uma variedade de esquemas fraudulentos. Para o sector da saúde dos Estados Unidos, considerações de conformidade incluem a Health Insurance Portability and Accountability Act (HIPAA), Privacidade, Segurança, Regras de Notificações em Caso de Brecha e Regras de Segurança do Utente. - -- Indústria Financeira: aplicações que permitem o acesso a informação altamente sensível como números de cartão de crédito, informação pessoal, ou permitem aos utilizadores movimentar fundos. Estas aplicações garantem controlos de segurança adicionais para prevenir fraude. Aplicações financeiras precisam de assegurar conformidade com o Payment Card Industry Data Security Standard (PCI DSS), Gramm Leech Bliley Act e Sarbanes-Oxley Act (SOX). - -###### MASVS L1+R - -- Aplicações móveis em que a proteção da Propriedade Intelectual é um objetivo de negócio. Os controlos de resiliência listados na MASVS-R podem ser usados para aumentar o esforço necessário para obter o código-fonte original e para impedir a adulteração/quebra do sistema. - -- Indústria dos jogos: jogos com um objetivo essencial de prevenir alteração visual ou fazer batota, como jogos de competição online. Fazer batota é um problema importante em jogos online, sendo que um número elevado de batoteiros leva a que os jogadores fiquem descontentes e em última instância poderá levar a que o jogo falhe. O MASVS-R providencia controlos de anti-falsificação básicos que ajudam a aumentar o esforço dos batoteiros. - -###### MASVS L2+R - -- Indústria Financeira: aplicações online de bancos que permitem a movimentação de fundos, onde técnicas como injecção de código e instrumentalização em equipamentos comprometidos representam um risco. Neste caso, os controlos do MASVS-R podem ser usados pra impedir a adulteração, aumentando a fasquia para autores de malware. - -- Todas as aplicações móveis que, propositadamente, necessitem de guardar dados sensíveis no equipamento móvel, e ao mesmo tempo suportam um leque alargado de equipamentos e versões do sistema operativo. Neste caso, os controlos de resiliência podem ser usados como uma medida da defesa em profundidade para aumentar o esforço para atacantes que queiram extrair dados sensíveis. - -- Aplicações que incluem compras de serviços no seu interior devem usar controloes no lado do servidor e controlos MASVS-L2 para proteger conteúdo pago. Contudo, poderão haver casos em que não haja possibilidade de proteção no lado do servidor. Nestes casos, os controlos MASVS-R devem ser aplicados adicionalmente para aumentar o esforço da engenharia reversa e adulteração. diff --git a/Document-ptpt/0x04-Assessment_and_Certification.md b/Document-ptpt/0x04-Assessment_and_Certification.md deleted file mode 100644 index 10dd59cec..000000000 --- a/Document-ptpt/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,52 +0,0 @@ - -# Avaliação e Certificação - -## A posição da OWASP sobre certificações MASVS e marcas de confiança - -A OWASP, como organização sem fins lucrativos e neutra não certifica nenhuma empresa, nem verifica software. - -Todo o tipo de confirmações de garantias, marcas de confiança ou certificados não são oficialmente verificados, registados, ou certificados pela OWASP, por isso uma organização dependente de tal visão tem de ter cuidado com a confiança depositada em qualquer terceiro ou marca de confiança reivindicando certificação (M)ASVS . - -Isto não deve inibir organizações de garantirem tais serviços de garantias, desde que não afirmem ser uma certificação oficial da OWASP. - -## Orientação para Certificar Aplicações Móveis - -A maneira recomendada de verificar a conformidade de uma aplicação móvel com o MASVS é executando uma revisão de "livro aberto", querendo isto dizer que é dado acesso aos testers a recursos chave tais como arquitetos e programadores da aplicação, documentação do projeto, código fonte, acesso autenticado aos pontos de acesso, incluindo acesso a pelo menos uma conta de utilizador por cada função (role). - -É importante notar que o MASVS apenas cobre a segurança da aplicação móvel (lado do cliente) e da comunicação de rede entre a aplicação e os seus pontos de acesso remotos, assim como alguns requisitos básicos e genéricos relacionados com autenticação do utilizador e gestão de sessão. Isso nao inclui requisitos específicos para serviços remotos (ex: web services) associados à aplicação para além de um conjunto limitado de requisitos genéricos relacionados com autorização, autenticação, verificação de controlo e gestão de sessão. Contudo, MASVS V1 especifica que serviços remotos devem ser abrangidos pelo documento de modelo de ameaças (Threat Modeling) e ser verificados contra padrões apropriados, como o OWASP ASVS. - -Uma organização certificadora deve incluir em qualquer relatório o âmbito da verificação (especialmente se algum componente chave é deixado de fora do âmbito), um sumário dos resultados da verificação, incluindo testes que passaram e falharam, com claras indicações de como resolver os testes que falharam. Manter documentos detalhados do trabalho, capturas de ecrã ou vídeos, scripts para explorar um problema de forma fiável e repetitiva, e registos eletrónicos dos testes, tais como registos de interceção de um proxy e notas associadas como uma lista de organização, são consideradas boas práticas padrão da indústria. Não é suficiente simplesmente correr uma ferramenta e reportar as falhas. Isto não fornece provas suficientes de que todos os possíveis problemas a um nível da certificação foram testados exaustivamente. Em caso de disputa, deve haver um suporte de provas suficientes para demonstrar que todos os requisitos verificados foram de facto testados. - - - -### Usando o OWASP Mobile Application Security Testing Guide (MASTG) - -O OWASP MASTG é um manual para testar a segurança de aplicações móveis. Descreve os processos técnicos para verificar os requisitos listados em MASVS. O MASTG inclui uma lista de casos de teste, cada um que corresponde a um requisito no MASVS. Enquanto que os requisitos do MASVS são de alto nível e genéricos, o MASTG fornece recomendações extensivas e procedimentos de testes separados por Sistema Operativo. - -### O Papel de Ferramentas de Testes de Segurança Automáticas - -O uso de scanners de código fonte e ferramentas de blackbox é aconselhado de forma a aumentar a eficiência sempre que possível. Não é, no entanto, possível completar a verificação MASVS usando apenas ferramentas automatizadas: - -Cada aplicação móvel é diferente, e perceber a arquitetura no geral, lógica de negócio, e problemas técnicos das tecnologias e frameworks específicas usadas, é um requisito obrigatório para verificar a segurança da aplicação. - -## Outros usos - -### Como Orientação Detalhada da Arquitetura de Segurança - -Um dos usos mais comuns para Mobile Application Security Verification Standard é como um recurso para arquitetos de segurança. As duas maiores frameworks de arquitetura de segurança, SABSA ou TOGAF, têm uma grande falta de informação que é necessária para completar revisões de arquitetura de segurança de aplicações móveis. O MASVS pode ser usado para preencher essas falhas, permitindo aos arquitetos de segurança escolher melhores controlos para problemas comuns em aplicações móveis. - -### Como um Substituto a Listas de Verificação de Código Seguro Prontas a Usar - -Muitas organizações podem beneficiar da adoção do MASVS, escolhendo um de dois níveis, ou criando um fork do MASVS e mudando o que é preciso para cada nível de risco da aplicação num domínio específico. Nós aconselhamos este tipo de fork desde que o rastreamento seja mantido, de forma a que se a aplicação passar no requisito 4.1, isso signifique o mesmo para os forks copiados, à medida que o padrão evolui. - -### Como uma Base para Metodologias de Testes de Segurança - -Uma boa metodologia de testes de segurança de aplicações móveis deve cobrir todos os requisitos listados em MASVS. O OWASP Mobile Application Security Testing Guide (MASTG) descreve testes de baclbox e whitebox para cada requisito de verificação. - -### Como um Guia para Testes Unitários e de Integração Automáticos - -O MASVS foi desenhado para ser altamente testável, com a única exceção de requisitos de arquitetura. Testes automatizados, unitários, de integração e de aceitação, baseados nos requisitos do MASVS podem ser integrados no ciclo contínuo de desenvolvimento. Isto não só aumenta a consciência de segurança do programador, como também melhora a qualidade geral das aplicações resultantes e reduz o número de resultados durante testes de segurança na fase anterior ao lançamento de versão. - -### Para Treino de Desenvolvimento Seguro - -O MASVS pode também ser usado para definir características de segurança de aplicações móveis. Muitos cursos de "Programação segura" são apenas cursos de hacking ético com uma pequena amostra de dicas de programação. Isto não ajuda os programadores. Em vez disso, cursos de desenvolvimento seguro podem usar o MASVS com um forte foco nos controlos proactivos documentados no MASVS, em vez de por exemplo o Top 10 de problemas de segurança. diff --git a/Document-ptpt/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-ptpt/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 3363db926..000000000 --- a/Document-ptpt/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,38 +0,0 @@ - -# V1: Requisitos de Arquitetura, Desenho e Modelação de Ameaças - -## Objetivo de controlo - -Num mundo perfeito, a segurança deveria ser considerada em todas as fases de desenvolvimento. Mas na realidade a segurança é apenas considerada muitas vezes num estado tardio do SDLC. Para além dos controlos técnicos a MASVS requer que existam processos que garantam que a segurança foi tida em consideração na fase de planeamento da arquitetura da aplicação móvel e que os papéis de segurança de todos os componentes sejam conhecidos. Uma vez que a maioria das aplicações móveis funcionam como um cliente para serviços remotos, deve ser garantido que padrões de segurança são aplicados a esses serviços. Testar a aplicação de forma isolada não é suficiente. - -A categoria "V1" lista requisitos pertencentes à arquitetura e desenho da aplicação. Como tal, esta é a única categoria que não tem correspondência com os casos de teste em OWASP Mobile Application Security Testing Guide. Para cobrir tópicos como modelação de ameaças, SDLC seguro ou gestão de chaves, os utilizadores da MASVS devem consultar os respetivos projetos e/ou padrões da OWASP, como os listados em baixo. - -## Requisitos para verificações de segurança - -Os requisitos para MASVS-L1 e MASVS-L2 estão listados em baixo. - -| # | MSTG-ID | Descrição| L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Todos os componentes da aplicação estão identificados e são necessários. | x | x | -| **1.2** | MSTG-ARCH-2 | Controlos de segurança nunca são forçados apenas no lado do cliente, mas também no respetivo ponto de acesso remoto. | x | x | -| **1.3** | MSTG-ARCH-3 | Uma arquitetura de alto nível para a aplicação móvel e todos os serviços remotos foi definida e a segurança foi endereçada nessa arquitetura. | x | x | -| **1.4** | MSTG-ARCH-4 | Informação considerada sensível no contexto da aplicação móvel está claramente identificada. | x | x | -| **1.5** | MSTG-ARCH-5 | Todos os componentes da aplicação estão definidos em termos de funções negócio e/ou funções de segurança que os mesmos providenciam. | | x | -| **1.6** | MSTG-ARCH-6 | Modelação de ameaças para a aplicação móvel e os serviços remotos associados que identifica potenciais ameaças e contramedidas foi produzido. | | x | -| **1.7** | MSTG-ARCH-7 | Todos os controlos de segurança têm uma implementação centralizada. | | x | -| **1.8** | MSTG-ARCH-8 | Existe uma política explicita de como chaves de criptografia (caso existam) são geridas, e o ciclo de vida das chaves de criptografia é imposto. O ideal é seguir um padrão para gestão de chaves, como o NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | Existe um mecanismo para impor atualizações da aplicação móvel. | | x | -| **1.10** | MSTG-ARCH-10 | Segurança é endereçada em todas as partes do ciclo de vida do software. | | x | -| **1.11** | MSTG-ARCH-11 | Uma política de divulgação responsável é usada e aplicada de forma efetiva. | | x | -| **1.12** | MSTG-ARCH-12 | A aplicação deverá ser compatível com leis de privacidade e regulações. | x | x | - -## Referências - -Para mais informação, ver também: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-ptpt/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-ptpt/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index da4a6ee14..000000000 --- a/Document-ptpt/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Requisitos de Armazenamento de Dados e de Privacidade - -## Objetivo de Controlo - -A proteção de informação sensível, como por exemplo as credenciais do utilizador, e informação privada, é fulcral em segurança de dispositivos móveis. Informação sensível pode ser exposta de forma não intencional a outras aplicações em funcionamento no mesmo dispositivo se os mecanismos do sistema operativo, como o IPC, não são usados de forma apropriada. A informação também pode de forma não intencional vazar para armazenamento na nuvem, cópias de segurança ou cache to teclado. Adicionalmente os dispositivos móveis podem serem perdidos ou roubados mais facilmente comparados a outros dispositivos, então um atacante ganhar acesso fisico ao sistema é um cenário mais provável. Para evitar estes casos proteções adicionais podem ser implementadas forma a tornar a obtenção de informação sensível mais difícil. - -Repare que, a MASVS é focada na aplicação, e não cobre políticas a nível do dispositivo tais como as impostas por soluções MDM . Nós recomendamos o uso de tais políticas num contexto empresarial para melhorar a proteção da informação. - -### Definição de Informação Sensível - -Informação privada, no contexto da MASVS, diz respeito não só às credenciais do utilizador mas também a outros dados sensíveis, como por exemplo: - -- Informação de Identificação Pessoal (PII) que pode ser abusada para roubo de identidade: números de segurança social, números de cartões de crédito, números de conta bancária, informação de saúde; -- Informação altamente sensível que pode pôr em causa a reputação do indivíduo, e/ou custos financeiros se comprometida: Informação contratual, Informação de não divulgação, informação de gestão; -- Quaisquer dados que devem ser protegidos por lei ou outras razões. - -## Requisitos para Verificação de Segurança - -A grande maioria dos problemas de exposição de dados pode ser evitada através da aplicação de regras simples. A maioria das controlos listados neste capítulo são obrigatórios para todos os níveis de verificação. - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Sistemas para armazenamento de credenciais têm ser utilizados para guardar informação sensível como PII, credenciais de utilizador ou chaves criptográficas. | x | x | -| **2.2** | MSTG-STORAGE-2 | Nunca guardar informação privada fora do contexto da aplicação ou dos sistemas para armazenamento de credenciais. | x | x | -| **2.3** | MSTG-STORAGE-3 | Nenhuma informação sensível é exposta nos registos de actividade (logs) da aplicação. | x | x | -| **2.4** | MSTG-STORAGE-4 | Nenhuma informação sensível é partilhada com aplicações externas excepto se seja necessário por parte da arquitetura. | x | x | -| **2.5** | MSTG-STORAGE-5 | A cache do teclado está desativada nos controlos de entrada de texto relativos a dados sensíveis. | x | x | -| **2.6** | MSTG-STORAGE-6 | Nenhuma informação sensível é exposta via comunicação inter-processos (IPC). | x | x | -| **2.7** | MSTG-STORAGE-7 | Nenhuma informação sensível, nomeadamente palavras-passe, é exposta na interface apresentada ao utilizador. | x | x | -| **2.8** | MSTG-STORAGE-8 | Nenhuma informação sensível é incluída nas cópias de segurança geradas pelo sistema operativo móvel. | | x | -| **2.9** | MSTG-STORAGE-9 | A aplicação remove informação sensível das vistas, quando a aplicação é enviada para segundo plano. | | x | -| **2.10** | MSTG-STORAGE-10 | A aplicação não guarda em memória informação sensível durante um período maior que o necessário, sendo que essa mesma informação é apagada findo o respectivo uso. | | x | -| **2.11** | MSTG-STORAGE-11 | A aplicação reforça uma política mínima de segurança no acesso ao dispositivo, como por exemplo a necessidade do utilizador definir um código-passe. | | x | -| **2.12** | MSTG-STORAGE-12 | A aplicação educa o utilizador sobre os tipos de informação de identificação pessoal processada, assim como as práticas de segurança que o utilizador deve seguir durante a utilização da mesma. | x | x | -| **2.13** | MSTG-STORAGE-13 | Nenhuns dados sensível são guardados localmente no dispositivo móvel. Em vez disso, os dados devem de ser obtidos através de um pedido a um ponto de acesso remoto quando necessário e apenas serem mantidos em memória. | | x | -| **2.14** | MSTG-STORAGE-14 | Caso seja necessário guardar localmente dados sensíveis, estes devem ser cifrados com uma chave derivada de armazenamento em hardware que exija autenticação. | | x | -| **2.15** | MSTG-STORAGE-15 | O armazenamento local da aplicação deve ser limpo após uma excessiva quantidade de tentativas de autenticação. | | x | - -## Referências - -O OWASP Mobile Application Security Testing Guide providência instruções detalhadas para verificação dos requisitos listados nesta secção. - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -Para mais informação: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-ptpt/0x08-V3-Cryptography_Verification_Requirements.md b/Document-ptpt/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 3fbe5e843..000000000 --- a/Document-ptpt/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Requisitos de Criptografia - -## Objetivo de Controlo - -A criptografia é um ingrediente essencial no que toca à protecção de dados em dispositivos móveis. É também uma categoria onde as coisas podem correr horrivelmente mal, especialmente quando convenções padrão não são seguidas. O propósito dos controlos neste capítulo é assegurar que a aplicação usa criptografia de acordo com as melhores práticas da indústria, o que inclui: - -- O uso de bibliotecas de criptografia verificadas; -- A escolha e configuração corretas das primitivas criptográficas; -- O uso de um gerador de números aleatórios adequado sempre que aleatoriedade é necessária. - -## Requisitos para verificação de segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | A aplicação não se baseia em criptografia simétrica com chaves hardcoded como método único de encriptação. | x | x | -| **3.2** | MSTG-CRYPTO-2 | A aplicação faz uso de primitivas criptográficas verificadas. | x | x | -| **3.3** | MSTG-CRYPTO-3 | A aplicação faz uso de primitivas criptográficas apropriadas ao caso específico, configuradas de acordo com as boas práticas da indústria. | x | x | -| **3.4** | MSTG-CRYPTO-4 | A aplicação não faz uso de protocolos ou algoritmos criptográficos que são amplamente considerados descontinuados por motivos de segurança. | x | x | -| **3.5** | MSTG-CRYPTO-5 | A aplicação não faz uso da mesma chave para múltiplos propósitos. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Todos os valores aleatórios são gerados a partir de um gerador de números aleatórios seguro. | x | x | - -## Referências - -O OWASP Mobile Application Security Testing Guide providencia instruções detalhadas para a verificação dos requisitos listados abaixo. - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -Para mais informação: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-ptpt/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-ptpt/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 2a90a9195..000000000 --- a/Document-ptpt/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Requisitos de Autenticação e Gestão da Sessão - -## Objetivo de Controlo - -Na grande maioria dos casos, a autenticação dos utilizadores em serviços remotos é uma parte integral da arquitetura da aplicação no geral. Ainda que a maior parte da lógica seja feita no ponto de acesso remoto, MASVS define alguns requisitos relativos à gestão da sessão e da conta dos utilizadores. - -## Requisitos para a Verificação de Segurança - -| # | MSTG-ID | Descrição| L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Se a aplicação providencia ao utilizador acesso a um serviço remoto, algum tipo de autenticação, como autenticação por nome de utilizador/palavra passe, é realizada no ponto de acesso remoto. | x | x | -| **4.2** | MSTG-AUTH-2 | Se a gestão da sessão é feita com persistência de estado, o acesso remoto deve fazer uso do identificador de sessão gerado aleatoriamente, para garantir a autenticação do cliente/utilizador a cada pedido ao servidor, sem que seja necessário o repetitivo fornecimento das credenciais do utilizador. | x | x | -| **4.3** | MSTG-AUTH-3 | Se a gestão da sessão é baseada num passe (token), sem persistência de estado, o servidor providencia o passe assinado através de um algoritmo seguro. | x | x | -| **4.4** | MSTG-AUTH-4 | O ponto de acesso remoto termina a existente sessão quando o utilizador sai da aplicação (logout). | x | x | -| **4.5** | MSTG-AUTH-5 | Ao nível do ponto de acesso, deve existir uma colecção de regras para a definição da palavra-passe. | x | x | -| **4.6** | MSTG-AUTH-6 | O ponto de acesso deve implementar um mecanismo que permita proteger a aplicação de uma submissão excessiva de tentativas de autenticação. | x | x | -| **4.7** | MSTG-AUTH-7 | As sessões devem ser invalidadas ao nível do ponto de acesso após um período de inactividade pré-definido, ao fim do qual, os passes de acesso (access token) expiram. | x | x | -| **4.8** | MSTG-AUTH-8 | A autenticação biométrica, se aplicável, não deve ser implementada através de uma API que retorna Verdadeiro ou Falso. Deve ser baseada no desbloqueio de um gestor de credenciais (keychain/keystore). | | x | -| **4.9** | MSTG-AUTH-9 | Existe uma segunda autenticação (second factor authentication, 2FA) no ponto de acesso/ servidor e esse modo de autenticação é reforçado. | | x | -| **4.10** | MSTG-AUTH-10 | A transmissão de informação sensível deve ser feita após o reforço da autenticação. | | x | -| **4.11** | MSTG-AUTH-11 | A aplicação informa o utilizador de qualquer actividade sensível efectuada com a sua conta. Aos utilizadores é providenciada uma lista de dispositivos onde a sua conta está a ser utilizada, assim como outras informações contextuais (localização, identificador respectivo à conexão da internet, entre outras), e também o bloqueio desses mesmos dispositivos. | | x | -| **4.12** | MSTG-AUTH-12 | Os modelos de autorização devem ser definidos e aplicados ao nível do ponto de acesso. | x | x | - -## Referências - -O OWASP Mobile Application Security Testing Guide providencia instruções detalhadas para a verificação dos requisitos listados acima. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -Para mais informação: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-ptpt/0x10-V5-Network_communication_requirements.md b/Document-ptpt/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 1efd69fe0..000000000 --- a/Document-ptpt/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,40 +0,0 @@ - -# V5: Requisitos de comunicação em Rede - -## Objetivo de Controlo - -O objetivo dos controlos detalhados nesta secção é de garantir a confidencialidade e integridade da informação trocada entre a aplicação móvel e os pontos de acesso do serviço remoto. No mínimo, a aplicação móvel deve de usar um canal seguro e cifrados para as comunicações em rede, usando o protocolo TLS com configurações apropriadas. o Nível 2 (L2) lista medidas de defesas em profundidade como 'SSL pinnning' - -## Requisitos de verificação de segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Os dados são cifrados na rede usando TLS. Este canal seguro é usado com consistência ao longo da aplicação. | x | x | -| **5.2** | MSTG-NETWORK-2 | As configurações de TLS estão de acordo com as melhores praticas atuais, ou o mais próximo possível caso o sistema operativo movel não suporte os padrões recomendados. | x | x | -| **5.3** | MSTG-NETWORK-3 | A aplicação verifica o certificado X.509 do ponto de acesso remoto quando o canal seguro é estabelecido. Apenas certificados assinados por uma autoridade certificadora de confiança são aceites. | x | x | -| **5.4** | MSTG-NETWORK-4 | A aplicação ou usa a sua própria loja de certificados ou fixa o certificado da ou chave pública do ponto de acesso, e subsequentemente não estabelece ligações a pontos de acesso que ofereçam um certificado ou chave diferentes, mesmo que assinados por uma Autoridade de Certificação de confiança | | x | -| **5.5** | MSTG-NETWORK-5 | A aplicação não depende apenas de um único canal de comunicação inseguro (email ou SMS) para operações críticas, tais como inscrições e recuperação de contas. | | x | -| **5.6** | MSTG-NETWORK-6 | A aplicação depende apenas de conetividade atualizada e bibliotecas seguras. | | x | - -## Referencias - -O OWASP Mobile Application Security Testing Guide fornece instruções detalhadas de como verificar os requisitos identificados nesta secção. - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -Para mais informações ver também: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-ptpt/0x11-V6-Interaction_with_the_environment.md b/Document-ptpt/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index b50ca48fe..000000000 --- a/Document-ptpt/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Requisitos de Interacção com a plataforma - -## Objetivo de Controlo - -Os controlos neste grupo asseguram que a aplicação utiliza Interfaces de Programação da Aplicação (APIs) e componentes padrão. Adicionalmente é também abordada a comunicação entre aplicações (ICP). - -## Requisitos para Verificação de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | A aplicação apenas requer o conjunto mínimo de permissões necessárias. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Quaisquer dados obtidos por fonte externa (utilizador e outros) são validados e, se necessário, sanitizados. Aqui estão incluídos quaisquer dados obtidos através de interface visual (UI), via comunicação inter-processos (IPC), incorporados nos localizadores de instâncias (URL), assim como por recursos de rede.| x | x | -| **6.3** | MSTG-PLATFORM-3 | A aplicação não exporta qualquer informação sensível via esquemas de localizadores de instâncias (URL) customizados, excepto nos casos em que esses mecanismos estão devidamente protegidos. | x | x | -| **6.4** | MSTG-PLATFORM-4 | A aplicação não exporta qualquer informação sensível via comunicação inter-processos (IPC), excepto nos casos em que esses mecanismos estão devidamente protegidos. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript está inactivo nas vistas da aplicação excepto nos casos em que é estritamente necessário. | x | x | -| **6.6** | MSTG-PLATFORM-6 | As vistas da aplicação estão configuradas de forma a suportar o número mínimo de protocolos , idealmente só https deve ser suportado. Potentially dangerous handlers, such as file, tel and app-id, are disabled. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Se métodos nativos da aplicação estarem expostos na vista web, verificar que esta apenas renderiza o JavaScript contido na aplicação. | x | x | -| **6.8** | MSTG-PLATFORM-8 | A deserialização de objectos, se necessária, é implementada através do uso de interfaces (APIs) de serialização seguras. | x | x | -| **6.9** | MSTG-PLATFORM-9 | A aplicação protege-se contra ataques de sobreposição de ecrãs. (Apenas em Android) | | x | -| **6.10** | MSTG-PLATFORM-10 | A cache da vista web, o armazenamento e os recursos utilizados (JavaScript, etc.) devem ser limpos antes da destruição da vista web. | | x | -| **6.11** | MSTG-PLATFORM-11 | Verificar que a aplicação previne o uso de teclados externos customizados, nos casos em que informação sensivel é inserida. | | x | - -## Referências - -O OWASP Mobile Application Security Testing Guide providencia instruções detalhadas para verificação dos requisitos listados nesta secção. - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -Para mais informação: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-ptpt/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-ptpt/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index dddd1d86e..000000000 --- a/Document-ptpt/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Requisitos de Qualidade de Codigo e Distribuição - -## Objetivo de Controlo - -O objetivo deste controlo é garantir que as práticas básicas de segurança em programação são cumpridas ao longo do desenvolvimento da aplicação, e que os recursos de segurança “gratuitos” oferecidos pelo compilador são ativados. - -## Verificação de Requisitos de Segurança - -| # | MSTG-ID | Descrição | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | A aplicação é fornecida e assinada com um certificado válido, do qual a chave privada se encontra devidamente protegida. | x | x | -| **7.2** | MSTG-CODE-2 | A aplicação é desenvolvida em modo de distribuição, com configurações apropriadas para a implementação de uma nova versão de produção (ex. não depurável). | x | x | -| **7.3** | MSTG-CODE-3 | Os símbolos de depuração são removidos dos binários nativos. | x | x | -| **7.4** | MSTG-CODE-4 | Código de depuração e código de assistência ao programador (ex. código de teste, conteúdo secreto, configurações ocultas) são removidos. A aplicação não regista mensagens de erro detalhadas ou de depuração. | x | x | -| **7.5** | MSTG-CODE-5 | Todos os componentes de terceiros usados pela aplicação móvel, como bibliotecas e frameworks, são identificados e analisados para deteção de vulnerabilidades conhecidas. | x | x | -| **7.6** | MSTG-CODE-6 | A aplicação identifica e trata possíveis exceções. | x | x | -| **7.7** | MSTG-CODE-7 | A lógica de tratamento de erros em controlos de segurança, nega o acesso por defeito. | x | x | -| **7.8** | MSTG-CODE-8 | Em código não administrado, a memória é alocada, libertada e usada de forma segura. | x | x | -| **7.9** | MSTG-CODE-9 | Recursos de segurança gratuitos oferecidos pelo conjunto de ferramentas de programação, como minificação de bytes de código, proteção da pilha (stack), suporte ao PIE e contagem automática de referência, são ativados. | x | x | - -## Referências - -O OWASP Mobile Application Security Testing Guide providencia instruções detalhadas para verificação dos requisitos acima listados. - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -Para mais informação, consulte: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-ptpt/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-ptpt/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index fa059ff44..000000000 --- a/Document-ptpt/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,70 +0,0 @@ -# V8: Requisitos de Resiliência - -## Objetivo de controlo - -Esta secção cobre medidas recomendadas de defesa em profundidade para aplicações que processam ou dão acesso a informação ou funcionalidades sensíveis. A falta de algum destes controlos não causa uma vulnerabilidade - em vez disso, estes são considerados para aumentar a resiliência da aplicação contra ataques de engenharia reversa e ataques específicos do lado do cliente. - -Os controlos nesta secção devem ser aplicados quando necessários, baseados na avaliação dos riscos causados por manipulação não autorizada da aplicação, e/ou engenharia reversa do código. Nós sugerimos consultar o documento da OWASP "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" (ver referências em baixo) para uma lista de riscos de negócio assim como ameaças técnicas associadas. - -**É de notar que proteções de software nunca devem de ser usadas como alternativa a controlos de segurança. Os controlos listados em MASVR-R são planeados para adicionar controlos de proteção adicionais, específicos para ameaças, que também preenchem os requisitos de segurança de MASVS.** - -As seguintes considerações são aplicadas: - -1. Um modelo de ameaças tem de ser definido de tal forma que claramente realce as ameaças do lado do cliente que não devem de ser defendidas. Adicionalmente o nível de proteção que o modelo deve providenciar deve de ser especificado. Por exemplo um objetivo definito pode ser de forçar os autores de malware direcionado à procura de instrumentar a aplicação de investir esforços de engenharia reversa significativos. - -2. O modelo de ameaças deve ser credível e relevante. Por exemplo, esconder uma chave de criptografia numa implementação de caixa branca pode provar-se redundante se um atacante poder simplesmente obter o código da caixa branca como um todo. - -3. A eficácia da proteção deve ser verificada sempre por um humano especialista com experiência em testar particulares tipos de prevenção de adulteração e ofuscação usados (ver também os capítulos "engenharia reversa" e "Avaliação de Proteções de Software" em Mobile Application Security Testing Guide). - - - -### Impedimento de análise dinâmica e manipulação - -| # | MSTG-ID | Descrição| R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | A aplicação deteta, e responde à presença de um dispositivo 'rooted' ou com 'jailbreak' alertando o utilizador ou por fechar a aplicação. | x | -| **8.2** | MSTG-RESILIENCE-2 | A aplicação previne depuração e/ou deteta e responde a um depurador ligado à aplicação. Todos os protocolos de depuração devem de ser tidos em conta. | x | -| **8.3** | MSTG-RESILIENCE-3 | A aplicação deteta e responde a manipulação de ficheiros executáveis e informação critica dentro da sua sandbox. | x | -| **8.4** | MSTG-RESILIENCE-4 | A aplicação deteta e responde à presença de ferramentas ou frameworks de engenharia reversa amplamente usadas no dispositivo. | x | -| **8.5** | MSTG-RESILIENCE-5 | A aplicação deteta e responde a ser corrida num emulador. | x | -| **8.6** | MSTG-RESILIENCE-6 | A aplicação deteta e responde a manipulação de código e informação no seu próprio espaço de memória. | x | -| **8.7** | MSTG-RESILIENCE-7 | A aplicação implementa vários mecanismos em cada categoria de defesa(8.1 to 8.6). É de notar que a resiliência aumenta com o número, diversidade e originalidade dos sistemas usados. | x | -| **8.8** | MSTG-RESILIENCE-8 | Os mecanismos de deteção desencadeiam respostas de diferentes tipos, incluindo respostas atrasadas e furtivas. | x | -| **8.9** | MSTG-RESILIENCE-9 | Ofuscação é aplicada a defesas de programação que por sua vez impedem a desofuscação por via de análise dinâmica. | x | - -### Device Binding - -| # | MSTG-ID | Descrição| R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | A aplicação implementa uma funcionalidade de 'DEVICE BINDING' usando uma impressão digital do dispositivo derivada de várias propriedades únicas do mesmo. | x | - - - -### Impedimento de Compreensão - -| # | MSTG-ID | Descrição | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Todos os ficheiros executáveis e bibliotecas pertencentes à aplicação são ou cifrados ao nível do ficheiro, e/ou código importante ou segmentos de informação dentro dos executáveis são cifrados ou embalados. Analise estática básica não revela código ou informação importante. | x | -| **8.12** | MSTG-RESILIENCE-12 | Se o objetivo da ofuscação é proteger contra computações sensíveis, um esquema de ofuscação é usado que seja tanto apropriado para a tarefa em particular como robusto contro métodos de desofuscação manuais e automáticos, considerando investigações publicadas. A efetividade do esquema de ofuscação deve ser verificada com testes manuais. É de notar que características de isolamento baseado em hardware são preferidas em relação a ofuscação sempre que possível. | x | - -### Impedimento de espionagem - -| # | MSTG-ID | Descrição | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Como uma defesa em profundidade a seguir a ter uma comunicação entre as várias entidades bem protegida, encriptação a nível aplicacional pode ser usada para impedir ainda mais a espionagem. | x | - - - -## Referências - -A OWASP Mobile Application Security Testing Guide fornece instruções detalhadas para verificar os requisitos listados nesta secção: - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -Para mais informação, ver também: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-ptpt/0x90-Appendix-A_Glossary.md b/Document-ptpt/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 4843a6db9..000000000 --- a/Document-ptpt/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Apêndice A: Glossário - -- **Aleatorização da disposição do espaço de endereços (ASLR)** - Uma técnica que dificulta a exploração de defeitos relacionados com a corrupção de memória. -- **Segurança de aplicações** - Segurança ao nível da aplicação focada na analise de componentes que constituem a camada aplicaçional do modelo OSI (acrónimo do inglês Open System Interconnection), em vez de se focar por exemplo no sistema operativo que suporta as aplicações ou as redes às quais estão ligadas. -- **Verificação de Segurança de Aplicações** - A avaliação técnica de uma aplicação de acordo com o OWASP MASVS. -- **Relatório de Verificação de Segurança de Aplicações** - Um relatório que documenta os resultados gerais e a análise de suporte produzida pelo verificador para uma aplicação específica. -- **Autenticação** – A verificação da identidade reivindicada de um utilizador da aplicação. -- **Verificação Automatizada** – O uso de ferramentas automatizadas (ferramentas de análise dinâmica, ferramentas de análise estática ou ambas) que usam assinaturas de vulnerabilidade para encontrar problemas. -- **Black Box Testing** – É um método de teste de software que examina a funcionalidade de uma aplicação sem examinar suas estruturas ou trabalhos internos. -- **Componente** – Uma unidade de código independente, com interfaces de disco e rede associadas que comunicam com outros componentes. -- **Cross-Site Scripting (XSS)** – Uma vulnerabilidade de segurança normalmente encontrada em aplicações Web, permitindo a injeção de scripts do lado do cliente no conteúdo. -- **Modulo Criptográfico** – Hardware, software, e/ou firmware que implementa algoritmos critpográficos e/ou gera chaves criptográficas. -- **CWE** – O CWE é uma lista de fraquezas comuns de segurança de software desenvolvida pela comunidade. Serve como uma linguagem comum, uma vara de medição para ferramentas de segurança de software e como um ponto de partida para os esforços de identificação, mitigação e prevenção de fraquezas. -- **Dynamic Application Security Testing (DAST)** – As tecnologias DAST foram projetadas para detetar condições indicativas de uma vulnerabilidade de segurança numa aplicação durante o seu estado de execução. -- **Design Verification** – A avaliação técnica da arquitetura de segurança de uma aplicação. -- **Verificação Dinâmica** – O uso de ferramentas automáticas que usam assinaturas de vulnerabilidade para encontrar problemas durante a execução de uma aplicação. -- **Globally Unique Identifier (GUID)** – Um número de referência único usado como um identificador no software. -- **Hyper Text Transfer Protocol (HTTP)** – Um protocolo de aplicação para sistemas de informação hipermédia distribuídos, colaborativos. É a base da comunicação de dados para a World Wide Web. -- **Chaves Escritas em Código Imutável** – Chaves criptográficas que são armazenadas no próprio dispositivo. -- **IPC** – Comunicações entre processos, no IPC os processos comunicam entre eles e com o kernel para coordenar suas atividades. -- **Validação de Input** – A canonicalização e validação de entrada não confiável do utilizador. -- **Bytecode Java** – Bytecode Java é o conjunto de instruções da máquina virtual de Java (JVM). Cada bytecode é composto por um ou, em alguns casos, dois bytes que representam a instrução (código de operação), juntamente com zero ou mais bytes para a passagem de parâmetros. -- **Codigo Malicioso** – Código introduzido numa aplicação durante seu desenvolvimento sem o conhecimento do proprietário da mesma, que contorna a política de segurança pretendida da aplicação. Não é o mesmo que malware tal como vírus ou worm! -- **Malware** – Código executável que é introduzido numa aplicação durante o tempo de execução sem o conhecimento do utilizador ou administrador da aplicação. -- **Open Web Application Security Project (OWASP)** – O Projeto Aberto de Segurança de Aplicações Web (OWASP) é uma comunidade aberta e gratuita em todo o mundo, focada em melhorar a segurança de aplicações. A nossa missão é tornar a segurança de aplicações "visível", para que pessoas e organizações possam tomar decisões informadas sobre os riscos da segurança de aplicações. Veja: -- **Informação de Identificação Pessoal (PII)** – PII é informação que pode ser usada por si só ou com outra informação para identificar,contactar ou localizar uma única pessoa ou para identificar uma pessoa no contexto. -- **Position-Independent Executable (PIE)** – Um PIE é o fragmento de código de máquina que, sendo colocado nalgum lugar na memória primária, é executado corretamente, independentemente de seu endereço absoluto. -- **Infraetrutura de Chave Pública (PKI)** – Uma PKI é um arranjo que vincula chaves públicas às respectivas identidades de entidades. A ligação é estabelecida por meio de um processo de registo e emissão de certificados na e por uma autoridade de certificação (CA). -- **Static Application Security Testing (SAST)** – SAST é um conjunto de tecnologias projetadas para analisar o código-fonte de aplicações, byte code e binários para codificar e projetar condições indicativas de vulnerabilidades de segurança. As soluções SAST analisam uma aplicação de “dentro para fora” num estado de não execução. -- **SDLC** – Ciclo de vida de desenvolvimento de software. -- **Arquitectura de Segurança** – Uma abstração do design de aplicações que identifica e descreve onde e como os controlos de segurança são usados, além de identificar e descrever o local e a sensibilidade dos dados do utilizador e da aplicação. -- **Configuração de Segurança** – A configuração em tempo de execução de uma aplicação que afeta como os controlos de segurança são usados. -- **Controlo de Segurança** – Uma função ou componente que executa uma verificação de segurança (por exemplo, uma verificação de controlo de acesso) ou quando chamada resulta num efeito de segurança (por exemplo, gerar um registro de auditoria). -- **SQL Injection (SQLi)** – Uma técnica de injeção de código usada para atacar aplicações orientadas a dados, nos quais instruções SQL maliciosas são inseridas num ponto de entrada. -- **Autenticação SSO** – Single Sign On (SSO) ocorre quando um utilizador efetua login num cliente e é automaticamente conectado noutros clientes, independentemente da plataforma, tecnologia ou domínio que o utilizador está a usar. Por exemplo, ao fazer login no google, você faz login automaticamente no youtube, documentos e serviço de email. -- **Modelação de Ameaças** – Uma técnica que consiste em desenvolver arquiteturas de segurança cada vez mais refinadas para identificar agentes de ameaças, zonas de segurança, controlos de segurança, ativos técnicos e de negócio importantes. -- **Transport Layer Security** – Protocolos criptográficos que fornecem segurança de comunicação pela Internet. -- **URI and URL** – Um identificador uniforme de recursos é uma sequência de caracteres usada para identificar um nome ou um recurso da web. Um localizador uniforme de recursos é frequentemente usado como referência a um recurso. -- **User Acceptance Testing (UAT)** – Tradicionalmente, um ambiente de teste que se comporta como o ambiente de produção, onde todos os testes de software são realizados antes de serem lançados. -- **Verificador** – A pessoa ou equipa que está a rever uma aplicação em relação aos requisitos do OWASP MASVS. -- **Lista Branca** – Uma lista de dados ou operações permitidas, por exemplo, uma lista de caracteres com permissão para executar a validação de entrada. -- **Certificado X.509** – Um certificado X.509 é um certificado digital que usa o padrão de chave pública (PKI) X.509, internacionalmente aceite para verificar que uma chave pública pertence a um utilizador, computador ou serviço contido no certificado. diff --git a/Document-ptpt/0x91-Appendix-B_References.md b/Document-ptpt/0x91-Appendix-B_References.md deleted file mode 100644 index 7da8696e6..000000000 --- a/Document-ptpt/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Apêndice B: Referências - -Os projetos OWASP seguintes são muito provavelmente úteis aos utilizadores/adotantes deste padrão: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -De forma idêntica, os seguintes sites web são muito provavelmente úteis aos utilizadores/adotantes deste padrão: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-ptpt/CHANGELOG.md b/Document-ptpt/CHANGELOG.md deleted file mode 100644 index e33d062eb..000000000 --- a/Document-ptpt/CHANGELOG.md +++ /dev/null @@ -1,95 +0,0 @@ -# Registo 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 7 de Março de 2020 - Lançamento da versão Internacional - -As seguintes alterações fazem parte do lançamento da versão 1.2: - -- Tradução do MASVS disponível em Chinês simplificado. -- Alteração do título na capa do livro MASVS. -- Removidos do MSTG, o Mobile Top 10 e CWE, e incorporados nas referências já existentes em MASVS. - -## V1.2-RC - 5 de Outubro de 2019 - Pré-Lançamento de versão (apenas em Inglês) - -As seguintes alterações fazem parte do pré lançamento da versão 1.2: - -- Promovido a posição líder. -- Requisito alterado: MSTG-STORAGE-1 "need to be used". -- Requisitos MSTG-STORAGE-13, MSTG-STORAGE-14, e MSTG-STORAGE-15 foram adicionados, com foco na proteção de dados. -- Requisito MSTG-AUTH-11 foi atualizado para preservar a informação contextual. -- Requisito MSTG-CODE-4 foi atualizado para suportar mais do que somente depuração. -- Requisito MSTG-PLATFORM-10 adicionado para mais segurança no uso de vistas web. -- Requisito MSTG-AUTH-12 adicionado para relembrar os programadores de reforçar a implementação de autorizações, especialmente em casos de aplicações multi-utilizador. -- Adicionada mais alguma descrição em como o MASVS deve ser usado dada uma avaliação de risco. -- Adicionada mais alguma descrição sobre conteúdo pago. -- Requisito MSTG-ARCH-11 adicionado para incluir a política de Divulgação Responsável para aplicações L2. -- Requisito MSTG-ARCH-12 adicionado para demonstrar aos desenvolvedores de aplicações, que leis internacionais de privacidade importantes devem ser cumpridas. -- Criado um estilo consistente para todas as referências em versão Inglesa. -- Requisito MSTG-PLATFORM-11 adicionado para combater a espionagem através de teclados de terceiros. -- Requisito MSTG-MSTG-RESILIENCE-13 adicionado para impedir a espionagem de uma aplicação. - -## V1.1.4 - 4 de Julho de 2019 - Edição da Cimeira - -As seguintes alterações fazem parte do lançamento da versão 1.1.4: - -- Corrigidos todos os problemas de markdown. -- Atualizações em traduções para Francês e Espanhol. -- Registo de alterações traduzido para Chinês (ZHTW) e Japonês. -- Verificação automática da sintaxe da margem e acessibilidade de URLs. -- Adicionados códigos de identificação aos requisitos, que serão incluídos numa versão futura de MSTG, no sentido de encontrar recomendações e casos de teste de forma mais fácil. -- Reduzido o tamanho do repositório e adicionado "Generated" ao .gitignore. -- Adicionadas orientações de Código de Conduta e Contribuição. -- Adicionado um template de Pull-Request. -- Atualizado o sincronismo com o repositório em uso, para alojar o website do Gitbook. -- Atualizados os scripts de geração de XML/JSON/CSV para todas as traduções. -- Traduzido o prefácio para Chinês (ZHTW). - -## V1.1.3 - 9 de Janeiro de 2019 - Pequenas correções - -- Correção de falhas de tradução relativas ao requisito 7.1 na versão Espanhola -- Nova definição de tradutores em agradecimentos - -## V1.1.2 - 3 de Janeiro de 2019 - Patrocínio e internacionalização - -As seguintes alterações fazem parte do lançamento da versão 1.1.2: - -- Adicionados agradecimentos aos compradores do e-book. -- Adiciondos links de autenticação e links atualizados de falhas de autenticação, em falta na V4. -- Retificada a troca de 4.7 e 4.8 em Inglês. -- Primeiro lançamento de versão internacional! - - Correções em traduções de Espanhol. A tradução encontra-se agora em sincronia com a de Inglês (1.1.2). - - Correções na tradução para Russo. A tradução encontra-se agora em sincronia com a de Inglês (1.1.2). - - Adicionado o primeiro lançamento de versão em Cinês (ZHTW), Francês, Alemão e Japonês! -- Documento simplificado para facilitar a tradução. -- Adicionadas instruções para lançamento de versões automatizado. - -## V1.1.0 - 14 de Julho de 2018 - -As seguintes alterações fazem parte do lançamento da versão 1.1: - -- O requisito 2.6 "A área de transferência é desativada em campos de texto que contêm informação sensível." foi remvido. -- O requisito 2.2 "Informação sensível não deve ser guardada fora do repositório da aplicação ou do sistema de armazenamento de credenciais implementado" foi adicionado. -- O requisito 2.1 foi reformulado para "O sistema de armazenamento de credenciais implementado é usado de forma apropriada para guardar informação sensível, como informações de identificação pessoal (PII), credenciais de utilizador ou chaves de encriptação.". - -## V1.0 12 - Janeiro de 2018 - -As seguintes alterações fazem parte do lançamento da versão 1.0: - -- Removidos 8.9, bem como 8.12 -- 4.6 foi tornado mais genérico -- Pequenas correções (erros ortográficos, etc.) diff --git a/Document-ptpt/GLOSSARY.md b/Document-ptpt/GLOSSARY.md deleted file mode 100644 index 03e0883be..000000000 --- a/Document-ptpt/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Appendix A: Glossary - -## Address Space Layout Randomization (ASLR) - -A technique to make exploiting memory corruption bugs more difficult. - -## Application Security - -Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. - -## Application Security Verification - -The technical assessment of an application against the OWASP MASVS. - -## Application Security Verification Report - -A report that documents the overall results and supporting analysis produced by the verifier for a particular application. - -## Authentication - -The verification of the claimed identity of an application user. - -## Automated Verification - -The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems. - -## Black box testing - -It is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. - -## Component - -a self-contained unit of code, with associated disk and network interfaces that communicates with other components. - -## Cross-Site Scripting (XSS) - -A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. - -## Cryptographic module - -Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. - -## CWE - -CWE is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. - -## DAST - -Dynamic application security testing (DAST) technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. - -## Design Verification - -The technical assessment of the security architecture of an application. - -## Dynamic Verification - -The use of automated tools that use vulnerability signatures to find problems during the execution of an application. - -## Globally Unique Identifier(GUID) - -a unique reference number used as an identifier in software. - -## Hyper Text Transfer Protocol(HTTP) - -An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. - -## Hardcoded keys - -Cryptographic keys which are stored in the device itself. - -## IPC - -Inter Process Communications,In IPC Processes communicate with each other and with the kernel to coordinate their activities. - -## Input Validation - -The canonicalization and validation of untrusted user input. - -## JAVA Bytecode - -Java bytecode is the instruction set of the Java virtual machine(JVM). Each bytecode is composed of one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters. - -## Malicious Code - -Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! - -## Malware - -Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. - -## Open Web Application Security Project (OWASP) - -The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: - -## Personally Identifiable Information (PII) - -PII is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. - -## PIE - -Position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. - -## PKI - -A PKI is an arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). - -## SAST - -Static application security testing (SAST) is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. - -## SDLC - -Software development lifecycle. - -## Security Architecture - -An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. - -## Security Configuration - -The runtime configuration of an application that affects how security controls are used. - -## Security Control - -A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record). - -## SQL Injection (SQLi) - -A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. - -## SSO Authentication - -Single Sign On(SSO) occurs when a user logs in to one Client and is then signed in to other Clients automatically, regardless of the platform, technology, or domain the user is using. For example when you log in in google you automatically login in the youtube , docs and mail service. - -## Threat Modeling - -A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. - -## Transport Layer Security - -Cryptographic protocols that provide communication security over the Internet - -## URI and URL - -A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource. - -## User acceptance testing (UAT) - -Traditionally a test environment that behaves like the production environment where all software testing is performed before going live. - -## Verifier - -The person or team that is reviewing an application against the OWASP MASVS requirements. - -## Whitelist - -A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. - -## X.509 Certificate - -An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. diff --git a/Document-ptpt/SUMMARY.md b/Document-ptpt/SUMMARY.md deleted file mode 100644 index 3947347a5..000000000 --- a/Document-ptpt/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Table of Contents - -- [Registo de Alterações](CHANGELOG.md) -- [Prefácio](0x01-Foreword.md) -- [Sobre as Normas](0x02-Frontispiece.md) -- [Usando o MASVS](0x03-Using_the_MASVS.md) -- [Avaliação e Certificação](0x04-Assessment_and_Certification.md) - -## Requisitos de Segurança - -- [V1: Requisitos de Arquitetura, Desenho e Modelação de Ameaças](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Requisitos de Armazenamento de Dados e de Privacidade](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Requisitos de Criptografia](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Requisitos de Autenticação e Gestão da Sessão](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Requisitos de comunicação em Rede](0x10-V5-Network_communication_requirements.md) -- [V6: Requisitos de Interacção com a plataforma](0x11-V6-Interaction_with_the_environment.md) -- [V7: Requisitos de Qualidade de Codigo e Configuração de Distribuição](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Requisitos de Resiliência](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendix - -- [Appendix A - Glossário](GLOSSARY.md) -- [Appendix B - Referências](0x91-Appendix-B_References.md) diff --git a/Document-ptpt/book.json b/Document-ptpt/book.json deleted file mode 100644 index 97bb719e4..000000000 --- a/Document-ptpt/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "ptpt" -} diff --git a/Document-ptpt/images/CC-license.png b/Document-ptpt/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-ptpt/images/CC-license.png and /dev/null differ diff --git a/Document-ptpt/images/MASVS-levels.png b/Document-ptpt/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-ptpt/images/MASVS-levels.png and /dev/null differ diff --git a/Document-ptpt/images/OWASP_logo.png b/Document-ptpt/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-ptpt/images/OWASP_logo.png and /dev/null differ diff --git a/Document-ptpt/images/license.png b/Document-ptpt/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-ptpt/images/license.png and /dev/null differ diff --git a/Document-ptpt/images/masvs-levels-new.jpg b/Document-ptpt/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-ptpt/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-ptpt/images/masvs-mini-cover.jpg b/Document-ptpt/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-ptpt/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-ptpt/images/masvs-mini-cover.png b/Document-ptpt/images/masvs-mini-cover.png deleted file mode 100644 index f90283553..000000000 Binary files a/Document-ptpt/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-ptpt/metadata.md b/Document-ptpt/metadata.md deleted file mode 100644 index caec393e6..000000000 --- a/Document-ptpt/metadata.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'pt' -languagetext: '(Portuguese Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: "Índice" - ---- diff --git a/Document-ru/0x01-Foreword.md b/Document-ru/0x01-Foreword.md deleted file mode 100644 index 3f173021a..000000000 --- a/Document-ru/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Вступительное - -Технологические революции могут происходить молниеносно: менее десятилетия назад смартфоны были громоздкими устройствами с клавиатурой, и являлись дорогими игрушками для некоторых компаний. Сегодня же смартфоны прочно вошли в нашу жизнь. Мы доверяем им информацию, навигацию, коммуникацию, они являются неотъемлемой составляющей как бизнеса, так и жизни в целом. - -Каждая новая технология приносит новые риски безопасности, и попытка поспеть за этими изменениями и есть один из основных вызовов, которые стоят перед индустрией безопасности. Сторона защиты всегда на несколько шагов позади. Например, обычной реакцией многих была бы попытка применить старый подход: смартфоны - это маленькие компьютеры и мобильные приложения - обычное ПО, значит требования безопасности абсолютно такие же? Но так это не работает. Операционные системы смартфонов отличаются от ОС компьютеров и мобильные приложения отличаются от веб приложений. Например, классический метод поиска вирусов на основе сигнатурного анализа не имеет смысл в современных мобильных операционных системах: не только потому, что это не совместимо с моделью распространения мобильных приложений, но еще и потому, что это технически невозможно из-за ограничений среды выполнения приложений (sandbox). Кроме того, некоторые типы уязвимостей, такие как переполнение буфера и XSS, менее релевантны к мобильным приложениям, нежели к десктопным и веб-приложениям (есть исключения). - -Cо временем наша индустрия получила больше опыта в борьбе с мобильными угрозами. Как оказалось, мобильная безопасность в основном затрагивает хранение данных: приложения хранят нашу личную информацию, изображения, записи голоса и видео, заметки, учетные данные, информацию о бизнесе, местоположения и многое другое. Приложения играют роль клиентов, подключающих нас к сервисам, которыми мы используем ежедневно, и коммуникационных центров, обрабатывающих каждое сообщение, которым мы обмениваемся. Скомпрометировав телефон человека, вы получите неограниченный доступ к его личной жизни. Если учесть, что мобильные устройства легко теряются и похищаются, а мобильные вирусы сейчас активно развиваются, необходимость защиты данных становится ещё более очевидной. - -Стандарты безопасности мобильных приложений должны сконцентрироваться на том, как они обрабатывают, хранят и защищают чувствительную информацию. Несмотря на то, что современные мобильные операционные системы, такие как iOS и Android, предоставляют API для безопасного хранения данных и сетевого взаимодействия, чтобы быть эффективным, оно должно быть корректно использовано. Хранение данных, межпроцессное взаимодействие, правильное использование криптографического API и безопасное сетевое взаимодействие - это только некоторые из аспектов, которые требуют внимательного рассмотрения. - -Важный вопрос для нашей индустрии, в котором необходимо достичь соглашения: как далеко должны заходить специалисты в вопросах защиты конфиденциальности и целостности данных. Например, многие из нас согласятся, что мобильное приложение должно проверять сертификат сервера во время соединения TLS. Но что насчёт SSL pinning? Невыполнение этого требования ведёт к уязвимости? Должно ли это быть требованием, если приложение обрабатывает чувствительную информацию или это может быть контрпродуктивно? Нужно ли шифровывать данные, хранящиеся в SQlite, несмотря на то, что ОС выполняет приложение в песочнице (sandboxing)? То, что подходит одному приложению, может не подходить для другого. MASVS - это попытка стандартизации требований на основании уровней проверок, подходящих для разных моделей угроз. - -Появление вредоносных программ и инструментов удаленного управления заставляют осознать тот факт, что мобильные ОС имеют недостатки, которыми могут воспользоваться злоумышленники. Для дополнительной защиты чувствительных данных и предотвращения фальсификаций на стороне клиента всё шире используются стратегии контейнеризации. Это место, где всё усложняется. Аппаратные и программные решения, такие как Android for Work и Samsung Knox, существуют, но они доступны не на всех устройствах. В качестве решения можно реализовать дополнительные программные механизмы защиты, но, к сожалению, не существует стандартов или руководств по тестированию для верификации таких методов. - -В результате при тестировании информационной безопасности мобильных приложений постоянно возникают разногласия. Например, некоторые тестировщики приложений Android считают, что недостаточная обфускация или отсутствие детектирования root-доступа серьезными уязвимостями. Другие считают, что такие меры, как шифрование строк, обнаружение отладчика или обфускация не являются обязательными. Однако, этот двоякий взгляд не имеет смысла, так как меры защиты зависят от конкретной модели угроз для клиентского приложения. Защита на программном уровне не является бесполезной, но в конечном итоге её всегда можно обойти, так что она не должна быть использована как замена основным требованиям безопасности. - -Цель MASVS - предложить общий фундамент для безопасности мобильных приложений (MASVS-L1), усиленные меры защиты (MASVS-L2) и меры защиты против угроз на стороне клиента (MASVS-R). MASVS предназначен для достижения следующих целей: - -- Обеспечить требования для архитекторов и разработчиков ПО, стремящихся создавать безопасные мобильные приложения. -- Предложить промышленный стандарт, по которому можно проводить аудит безопасности мобильных приложений. -- Прояснить роль механизмов защиты ПО в мобильной безопасности и предоставить требования для проверки их эффективности. -- Предоставить конкретные рекомендации, для разных уровней безопасности, которые зависят от конкретного варианта использования. - -Мы пониманием что 100% согласия в отрасли невозможно достичь. Однако, мы надеемся, что MASVS будет полезен в качестве руководства на всех этапах разработки и тестирования мобильных приложений. MASVS, как открытый стандарт, будет развиваться со временем, и мы рады любым предложениям и вкладу в развитие проекта. - -Cлово от Bernhard Mueller diff --git a/Document-ru/0x02-Frontispiece.md b/Document-ru/0x02-Frontispiece.md deleted file mode 100644 index d17aec709..000000000 --- a/Document-ru/0x02-Frontispiece.md +++ /dev/null @@ -1,56 +0,0 @@ -# О стандарте - -![OWASP Logo](images/OWASP_logo.png) - -Добро пожаловать в стандарт проверки безопасности мобильных приложений (MASVS). MASVS - это результат совместных усилий в создании перечня требований информационной безопасности, необходимых для проектирования, разработки и тестирования мобильных приложений на iOS и Android. - -MASVS - итог усилий сообщества и обратной связи от представителей индустрии. Мы надеемся на развитие стандарта в будущем и приветствуем обратную связь от сообщества. Лучший способ связаться с нами - через канал OWASP Mobile Project в Slack-e: - -[https://owasp.slack.com/messages/project-mobile_omtg/details/](https://owasp.slack.com/messages/project-mobile_omtg/details/). - -Аккаунты можно создать по этому адресу: - -[https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Авторское право и лицензия - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Данный документ выпущен под лицензией Creative Commons Attribution ShareAlike 4.0 International . Для использования или распространения необходимо разъяснить всем сторонам правила лицензии этой работы. - - - -## Подтверждения - -| Руководитель проекта | Главные авторы | Авторы и рецензенты | -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Язык | Переводчики и рецензенты | -| --------------- | ------------------------------------------------------------ | -| традиционный китайский | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| упрощенный китайский | Bob Peng, Harold Zang, Jack S | -| Французский | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| Немецкий | Rocco Gränitz, Sven Schleier (Review) | -| хинди | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| Испанский | Martin Marsicano, Carlos Holguera | -| Японский | Koki Takeyama, Riotaro Okada (Review) | -| Корейский | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| Русский | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Персидский | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| португальский | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| бразильский португальский | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| турецкий | Anıl Baş, Haktan Emik | -| греческий | Panagiotis Yialouris | - -Работа над документом была начата как ответвление OWASP Application Security Verification Standard, написанного Jim Manico. - -## Спонсоры - -Хотя MASVS и MASTG создаются и поддерживаются сообществом на добровольной основе, иногда требуется небольшая помощь извне. Поэтому мы благодарим наших спонсоров за предоставление средств для возможности нанять технических редакторов. Обратите внимание, что их спонсорство никоим образом не влияет на содержание MASVS или MASTG. Спонсорские пакеты описаны на [OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -Наконец, мы хотели бы поблагодарить всех, кто купил книгу у [Leanpub](https://leanpub.com/mobile-security-testing-guide) и спонсировал нас таким образом. diff --git a/Document-ru/0x03-Using_the_MASVS.md b/Document-ru/0x03-Using_the_MASVS.md deleted file mode 100644 index 2d061ccb9..000000000 --- a/Document-ru/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,83 +0,0 @@ -# The Mobile Application Security Verification Standard - -MASVS может быть использован для подтверждения определенного уровня уверенности в безопасности мобильных приложений. Данные требования были сформированы, ориентируясь на следующие цели: - -- Использование в качестве метрики: для предоставления стандарта безопасности, по которому разработчики и владельцы мобильных приложений могут проверить свои продукты; -- Использование в качестве руководства: для предоставления рекомендаций во время всех этапов разработки и тестирования; -*- Использование во время закупок: как основание для проверки безопасности мобильного приложения. - -## Модель безопасности мобильных приложений - -MASVS определяет два уровня проверки безопасности (MASVS-L1 и MASVS-L2), а также набор гибких требований для обеспечения защиты от реверс инжиниринга (MASVS-R). MASVS-L1 содержит общие требования безопасности, которые рекомендованы для всех мобильных приложений, MASVS-L2 должен быть использован для приложений, оперирующих наиболее уязвимыми конфиденциальными данными. MASVS-R охватывает дополнительные меры защиты, которые могут применяться в случае, если предотвращение атак на стороне клиента заложено в дизайн приложения. - -Приложение, разработанное в соответствии с требованиями MASVS-L1, защищено лучшими практиками безопасности и не содержит часто встречающиеся уязвимости. MASVS-L2 предусматривает усиленные меры защиты, такие, как SSL pinning, защищающие приложение от более ухищренных атак, при условии, что безопасность операционной системы не скомпрометирована, а конечный пользователь не рассматривается как потенциальный злоумышленник. Реализация всех или хотя бы некоторых защитных техник из MASVS-R затрудняет атаки на стороне клиента, когда конечный пользователь является злоумышленником и/или ОС мобильного устройства скомпрометирована. - -**I: Хотя мы рекомендуем использование MASVS-L1 мер защиты в каждом приложении, применение или отказ от конкретной меры в конечном счете должно быть основанным на оценке риска решением, которое принято/доведено до сведения с владельцами бизнеса.** - -**II: Обратите внимание, что программные меры защиты, перечисленные в MASVS-R и OWASP Mobile Application Security Testing Guide, можно обойти, и они не должны использоваться в качестве замены основным требованиям безопасности. Вместо этого они должны быть реализованы как специализированное дополнение, направленное на локализацию конкретных угроз, в мобильном приложении, соответствующее требованиям MASVS-L1 или MASVS-L2.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### Структура документа - -Первая часть MASVS содержит описание модели безопасности и доступных уровней проверки, рекомендации о том, как использовать стандарт на практике. Подробные требования безопасности и их соответствие с уровнями проверки перечислены во второй части. Требования сгруппированы в восемь категорий (V1 - V8) по принадлежности к технической задаче/области. В MASVS и MASTG используется следующая номенклатура: - -- *Категория требований:* MASVS-Vx, например, MASVS-V2: хранение данных и конфиденциальность -- *Требование:* MASVS-Vx.y, например, MASVS-V2.2: «Чувствительные данные не попадают в логи приложения». - -### Подробное описание уровней верификации - -#### MASVS-L1: Стандартная безопасность - -Приложение, удовлетворяющее MASVS-L1, соответствует лучшим практикам обеспечения безопасности мобильных приложений. Данный уровень проверки предоставляет основные требования с точки зрения качества кода, обработки чувствительных данных и взаимодействия с мобильной средой. Для подтверждения соответствия приложения данному уровню безопасности необходимо проведение тестирования. Этот уровень подходит для всех мобильных приложений. - -#### MASVS-L2: Усиленная защита - -MASVS-L2 предлагает расширенные средства проверки безопасности, выходящие за рамки стандартных. Для соответствия MASVS-L2, необходима сформированная модель угроз, и безопасность должна быть неотъемлемой частью архитектуры и дизайна приложения. Конкретные MASVS-L2 требования должны быть выбраны и успешно применены базируясь на модели угроз. Этот уровень подходит для приложений, работающих с чувствительными данными, таких, как мобильный банк. - -#### MASVS-R: Устойчивость к реверс инжинирингу и фальсификациям - -Приложение имеет встроенные механизмы обеспечения безопасности, устойчиво к конкретным атакам на стороне клиента, таким, как фальсификация, модификация или реверс инжиниринг, направленным на извлечение чувствительных участков кода или данных. Такое приложение либо использует аппаратные средства безопасности, либо достаточно надёжные программные механизмы защиты. MASVS-R применим к приложениям, которые обрабатывают высокочувствительные данные и могут служить средством защиты интеллектуальной собственности. - -### Рекомендованное использование - -Приложения могут быть проверены на соответствие MASVS L1 или L2, основываясь на предварительной оценке рисков и общем понимании требуемого уровня безопасности. L1 применим ко всем мобильным приложениям, в то время как L2 обычно рекомендуется для приложений, которые обрабатывают более чувствительные данные и/или функциональность. MASVS-R (или его части) может быть применен для проверки устойчивости к конкретным угрозам, таким, как переупаковка (repackaging) или извлечение конфиденциальных данных, *в дополнение* к основным проверкам безопасности. - -Таким образом, доступны следующие типы проверки: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Различные комбинации отражают различные уровни безопасности и устойчивости к атакам. Цель состоит в том, чтобы обеспечить гибкость: например, игра для смартфона может не гарантировать соответствие таким мерам защиты MASVS-L2, как двухфакторная аутентификация, из-за неудобства использования, но имеет потребность в предотвращении фальсификаций. - -#### Какой тип проверки выбрать - -Соответствие требованиям MASVS L2 повышает безопасность, но в то же время увеличивает стоимость разработки и потенциально ухудшает опыт конечного пользователя (классический компромисс между удобством и безопасностью). В общем случае, L2 следует использовать для приложений, рассматриваемых с точки зрения риска и издержек (т.е. когда потенциальная потеря, вызванная нарушением конфиденциальности или целостности, выше, чем затраты, связанные с реализацией дополнительных проверок безопасности). Оценка рисков должна быть первым шагом перед применением MASVS. - -##### Примеры - -###### MASVS-L1 - -- Все мобильные приложения. В MASVS-L1 перечислены рекомендации по безопасности, которые могут быть выполнены с разумным воздействием на стоимость разработки и пользовательский опыт. Применяйте требования MASVS-L1 для любого приложения, которое не подходит ни под один из более высоких уровней. - -###### MASVS-L2 - -- Индустрия здравоохранения: мобильные приложения, которые хранят персональные данные, которые могут использоваться для кражи личности, мошеннических платежей или других схем мошенничества. Для сектора здравоохранения США пункты проверок включают в себя Закон об охране и ответственности за информацию, полученную в результате медицинского страхования (HIPAA). - -- Финансовая индустрия: приложения, которые обеспечивают доступ к высокочувствительной информации, такой, как номера кредитных карт, персональным данным, или позволяют управлять финансовыми средствами. Эти приложения требуют дополнительных проверок безопасности для предотвращения мошенничества. Финансовым приложениям необходимо обеспечить соблюдение стандартов безопасности данных, таких, как Payment Card Industry Data Security Standard (PCI DSS), Gramm Leech Bliley Act и Sarbanes-Oxley Act (SOX). - -###### MASVS L1+R - -- Мобильные приложения, где защита IP является целью бизнеса. Меры защиты, перечисленные в MASVS-R, могут использоваться для увеличения усилий, необходимых для получения исходного кода, и для препятствия попыткам фальсификации или взлома приложения. - -- Игровая индустрия: игры, для которых важное значение имеет предотвращение возможности модификации и использования читов, например, многопользовательские онлайн-игры. Читинг является важной проблемой в онлайн-играх, так как большое количество читеров вызывает недовольство у основной массы игроков и в конечном итоге может привести к краху данного игрового продукта. MASVS-R содержит меры защиты, направленные на усложнение задачи читерам. - -###### MASVS L2+R - -- Финансовая индустрия: приложения для онлайн банкинга, которые позволяют пользователю управлять финансовыми средствами, для которых инъекции кода и использование специализированного инструментария для взлома на устройствах с jailbreak-ом/root-ом представляют риск. В этом случае, верификация MASVS-R может быть использована, чтобы препятствовать фальсификации, усложнить задачу авторам вредоносных программ. - -- Все мобильные приложения хранят чувствительные данные на мобильном устройстве, и в то же время должны поддерживать широкий спектр устройств и версий операционной системы. В этом случае проверка устойчивости к фальсификациям может использоваться в качестве углублённой защиты, для максимального затруднения извлечения конфиденциальных данных злоумышленником. - -- Приложения с платным контентом в идеале должны использовать серверные и MASVS-L2 элементы управления для защиты платного контента. Однако могут быть случаи, когда нет возможности использовать защиту на стороне сервера. В этих случаях, для увеличения усилия по обращению реверсирования и/или вмешательства следует дополнительно применять средства управления MASVS-R. diff --git a/Document-ru/0x04-Assessment_and_Certification.md b/Document-ru/0x04-Assessment_and_Certification.md deleted file mode 100644 index 6a8fddbef..000000000 --- a/Document-ru/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# Оценка и сертификация - -## Позиция OWASP в отношении сертификатов MASVS - -OWASP является некоммерческой организацией и не сертифицирует вендоров, аудиторов, или программное обеспечение. - -OWASP не выдаёт официальные оценки, знаки доверия, или сертификаты, поэтому к организации, утверждающей, что она имеет сертификацию OWASP, следует относиться с осторожностью. - -В то же время, отсутствие официальной сертификации OWASP не запрещает организациям предлагать услуги аудита по данному стандарту. - -## Руководство по сертификации мобильных приложений - -Рекомендуемым способом проверки соответствия мобильного приложения стандарту MASVS является аудит методом «открытой книги», означающий, что проверяющие получают полный доступ к ключевым ресурсам, таким как: архитекторы и разработчики приложения, проектная документация, исходный код и авторизованный доступ к бэкенду (как минимум по одной учетной записи для каждой роли). - -Важно отметить, что MASVS охватывает только безопасность мобильных приложений (на стороне клиента) и сетевое взаимодействие между приложением и его удалёнными сервисами, а также несколько базовых и общих требований, связанных с аутентификацией пользователя и управлением сессиями. Данный документ не содержит специфичных требований к удаленным сервисам (например, веб-сервисам), связанным с приложением, ограничиваясь набором базовых требований к безопасности аутентификации и управления сессиями. Однако MASVS V1 подчёркивает, что удалённые сервисы должны быть учтены в общей модели угроз и проверены по соответствующим стандартам, таким, как OWASP ASVS. - -Проверяющая организация должна включать в отчёт область охвата проверки, резюме о результатах проверки, включая пройденные и непройденные тесты, с ясными указаниями о том, как исправить недостатки. Сохранение подробных документов, скриншотов или видео, сценариев для воспроизведения и эксплуатирования багов, электронных записей, таких как логи перехватывающего запросы прокси-сервера и прочих заметок являются стандартной практикой индустрии. Недостаточно просто запустить инструмент и сообщить об ошибках, это не дает достаточных доказательств того, что проверяющим были проведены все проверки должным образом. В случае возникновения спора должны быть достаточные доказательства для демонстрации того, что соответствие каждому требованию было проверено. - -### Использование OWASP Mobile Application Security Testing Guide (MASTG) - -OWASP MASTG - это руководство по тестированию безопасности мобильных приложений. В нём описываются технические процессы для проверки требований, перечисленных в MASVS. MASTG включает список тест-кейсов, выстроенных в соответствии с требованиями в MASVS. Хотя требования MASVS являются высокоуровневыми и универсальными, MASTG предоставляет подробные рекомендации и процедуры тестирования для каждой целевой мобильной ОС. - -### Роль автоматических инструментов тестирования безопасности - -Для повышения эффективности рекомендуется использовать статические анализаторы исходного кода и инструменты для blackbox тестирования. Однако невозможно выполнить проверку MASVS, используя только автоматизированные инструменты: каждое мобильное приложение уникально, и понимание общей архитектуры, бизнес-логики и технических проблем конкретных технологий и фреймворков является обязательным требованием для верификации безопасности приложения. - -## Другие применения - -### Как подробное руководство по архитектуре безопасности - -Одно из наиболее распространенных применений MASVS - в качестве пособия для архитекторов безопасности. В двух основных методологиях по выстраиванию безопасной архитектуры SABSA и TOGAF отсутствует информация, необходимая для ревью безопасности архитектуры мобильных приложений. MASVS можно использовать для заполнения этих пробелов, позволяя архитекторам безопасности выбирать лучшие требования безопасности, адаптированные для мобильных приложений. - -### В качестве замены готовых чек-листов написания безопасного кода - -Многие организации могут извлечь выгоду из соответствия MASVS, выбрав один из двух уровней проверки, или кастомизировав MASVS для собственных требований, предварительно оценив уровни риска для собственных приложений, беря во внимание область их применения. Мы приветствуем такие ответвления до тех пор, пока сохраняется преемственность, т.е. соответствие приложения требованию 4.1 оригинального стандарта должно означать то же самое в его кастомизированной копии. - -### В качестве основы для методологий тестирования безопасности - -Хорошая методология тестирования безопасности мобильных приложений должна покрывать все требования, перечисленные в MASVS. В гайде OWASP по тестированию мобильных приложений (MASTG) описываются black-box и white-box тест-кейсы для каждого из требований данного стандарта. - -### Как руководство для автоматического модульного и интеграционного тестирований - -MASVS, за исключением некоторых архитектурных требований, может быть использован как руководство для тестирования. Автоматические модульное, интеграционное и приёмочное тестирование на основе требований MASVS могут быть интегрированы в непрерывный жизненный цикл разработки. Это не только повысит уровень осведомлённости разработчиков в области безопасности, но также улучшит общее качество приложений и уменьшит количество находимых уязвимостей на этапе предрелиза. - -### Для курсов по обучению безопасной разработке - -MASVS также может использоваться для определения характеристик безопасных мобильных приложений. Многие курсы «безопасного программирования» - это курсы этичного хакинга с лёгким намеком на подсказки по написанию кода, что, безусловно, не помогает разработчикам. Вместо этого курсы безопасной разработки могут использовать MASVS, уделяя особое внимание проактивным средствам контроля, задокументированным в MASVS, а не, например, списку наиболее часто встречающихся уязвимостей в мобильных приложениях (OWASP Mobile Top 10). diff --git a/Document-ru/0x06-V1-Architecture_design_and_threat_modelling_requirements.md b/Document-ru/0x06-V1-Architecture_design_and_threat_modelling_requirements.md deleted file mode 100644 index 53513a3f7..000000000 --- a/Document-ru/0x06-V1-Architecture_design_and_threat_modelling_requirements.md +++ /dev/null @@ -1,38 +0,0 @@ -# V1: Требования к архитектуре, дизайну и модели угроз - -## Цель верификации - -В идеальном мире безопасность должна приниматься во внимание на всех этапах разработки. Однако на самом деле безопасность часто рассматривается только на поздней стадии SDLC. Помимо технических средств управления, MASVS требует наличия процессов, которые гарантируют, что безопасность была явно учтена при разработке архитектуры мобильного приложения и что функциональные и защитные роли всех компонентов известны. Поскольку большинство мобильных приложений выступают в качестве клиентов у веб-сервисов, необходимо обеспечить применение соответствующих стандартов безопасности: только тестирования изолированного мобильного приложения недостаточно. - -В категории «V1» перечислены требования, касающиеся архитектуры и дизайна приложения. Таким образом, это единственная категория, которая не соответствует техническим тестам в OWASP MSTG. Чтобы охватить такие темы, как моделирование угроз, безопасный SDLC, управление ключами, пользователи MASVS должны проконсультироваться с соответствующими проектами OWASP и/или другими стандартами, такими как те, которые приведены ниже. - -## Требования безопасности - -Ниже приведены требования к MASVS-L1 и MASVS-L2. - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Все компоненты приложения идентифицированы и используются. | x | x | -| **1.2** | MSTG-ARCH-2 | Проверки безопасности реализованы не только на клиенте, но и на бэкенде. | x | x | -| **1.3** | MSTG-ARCH-3 | Архитектура мобильного приложения учитывает все удалённые сервисы. Безопасность заложена в архитектуре.| x | x | -| **1.4** | MSTG-ARCH-4 | Определены данные, которые являются чувствительными в контексте мобильного приложения. | x | x | -| **1.5** | MSTG-ARCH-5 | Все компоненты приложения определены с точки зрения бизнес логики и/или безопасности. | | x | -| **1.6** | MSTG-ARCH-6 | Сформирована модель угроз для мобильного приложения и связанных с ним удаленных сервисов, которая идентифицирует потенциальные угрозы и необходимые контрмеры. | | x | -| **1.7** | MSTG-ARCH-7 | Все проверки безопасности имеют централизованную реализацию. | | x | -| **1.8** | MSTG-ARCH-8 | Существует явная политика управления криптографическими ключами (если они есть) и их жизненным циклом. В идеале политика соответствует стандарту управления ключами, например, NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | Существует механизм принудительных обновлений мобильного приложения. | | x | -| **1.10** | MSTG-ARCH-10 | Безопасность заложена во все этапы жизненного цикла разработки программного обеспечения. | | x | -| **1.11** | MSTG-ARCH-11 | Существует и эффективно применяется ответственная политика раскрытия информации. | | x | -| **1.12** | MSTG-ARCH-12 | Приложение должно соответствовать законам о защите персональных данных. | x | x | - -## Ссылки - -Для дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 (Recommendation for Key Management) - -- security.txt - diff --git a/Document-ru/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-ru/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 05a1a641b..000000000 --- a/Document-ru/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Требования к конфиденциальности и хранению данных - -## Цель проверки - -Защита чувствительных данных, таких, как данные пользователя для авторизации (логин + пароль) и персональные данные, является ключевым аспектом в безопасности мобильных приложений. Во-первых, чувствительные данные могут быть непреднамеренно раскрыты другим приложениям, работающим на том же устройстве, если механизмы операционной системы, такие как межпроцессное взаимодействие (IPC), используются ненадлежащим образом. Данные также могут непреднамеренно попасть в облачное хранилище, резервную копию или кеш клавиатуры. Кроме того, мобильные устройства могут быть потеряны или украдены легче чем другие типы устройств, поэтому злоумышленник, получивший физический доступ к устройству, является наиболее вероятным сценарием. В этом случае могут быть реализованы дополнительные меры защиты для затруднения извлечения чувствительных данных с устройства. - -Следует обратить внимание, что MASVS ориентирован на приложения, и потому не охватывает политики безопасности на уровне устройства (MDM - Mobile Device Managment). Мы поощряем использование таких политик в контексте предприятия для повышения безопасности данных. - -### Определение чувствительных данных - -К чувствительным данным в контексте MASVS относятся как данные пользователя для авторизации, так и любые другие данные, которые считаются чувствительными в конкретном контексте, например: - -- Персональные данные, которые могут быть использованы для кражи личности: номера социального страхования, кредитных карт, банковских счетов, информация о здоровье. -- Конфиденциальная информация, которая может привести к репутационному ущербу и/или финансовым потерям, если она скомпрометирована: информация о договорах, информация, охватываемая соглашениями о неразглашении, управленческая информация; -- Любые данные, которые должны быть защищены по закону или внутренним требованиям компании. - -## Требования безопасности - -Подавляющее большинство проблем с раскрытием информации можно предотвратить, следуя простым правилам. Большинство требований, перечисленных в этой главе, являются обязательными для всех уровней проверки. - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Хранилище учетных данных системы должно использоваться надлежащим образом для хранения чувствительных данных, таких как персональные данные, данные пользователя для авторизации и криптографические ключи. | x | x | -| **2.2** | MSTG-STORAGE-2 | Чувствительные данные хранятся только во внутреннем хранилище приложения, либо в системном хранилище авторизационных данных. | x | x | -| **2.3** | MSTG-STORAGE-3 | Чувствительные данные не попадают в логи приложения. | x | x | -| **2.4** | MSTG-STORAGE-4 | Никакие чувствительные данные не передаются третьей стороне, если это не является необходимой частью архитектуры. | x | x | -| **2.5** | MSTG-STORAGE-5 | Кэш клавиатуры выключен для полей ввода чувствительных данных. | x | x | -| **2.6** | MSTG-STORAGE-6 | Чувствительные данные недоступны для механизмов межпроцессного взаимодействия (IPC). | x | x | -| **2.7** | MSTG-STORAGE-7 | Никакие чувствительные данные, такие как пароли или пин-коды, не видны через пользовательский интерфейс. | x | x | -| **2.8** | MSTG-STORAGE-8 | Никакие чувствительные данные не попадают в бэкапы, создаваемые операционной системой. | | x | -| **2.9** | MSTG-STORAGE-9 | Приложение скрывает чувствительные данные с экрана, когда находится в фоновом режиме. | | x | -| **2.10** | MSTG-STORAGE-10 | Приложение не хранит чувствительные данные в памяти дольше, чем необходимо, и полностью удаляет их из памяти после работы с ними. | | x | -| **2.11** | MSTG-STORAGE-11 | Приложение требует от пользователя минимальную настройку доступа к устройству, такую, как установку пин-кода на устройство. | | x | -| **2.12** | MSTG-STORAGE-12 | Приложение информирует пользователя о персональных данных, которые оно обрабатывает, а также о лучших практиках безопасности, которым должен следовать пользователь при использовании приложения. | x | x | -| **2.13** | MSTG-STORAGE-13 | Конфиденциальные данные локально не должны храниться на мобильном устройстве. Вместо этого необходимые данные должны получаться с сервера и храниться только в памяти. | | x | -| **2.14** | MSTG-STORAGE-14 | Если конфиденциальные данные все же требуется хранить локально, они должны быть зашифрованы с помощью ключа, полученного из аппаратного хранилища, которое требует проверки подлинности. | | x | -| **2.15** | MSTG-STORAGE-15 | Локальное хранилище приложения должно быть стерто после превышения допустимого количества неудачных попыток. | | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации требований, перечисленных в этом разделе. - -- Android: Тестирование хранения данных - -- iOS: Тестирование хранения данных - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-ru/0x08-V3-Cryptography_Verification_Requirements.md b/Document-ru/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 7cd477d6f..000000000 --- a/Document-ru/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Требования к криптографии - -## Цель верификации - -Криптография является неотъемлемым компонентом защиты данных, хранящихся на мобильном устройстве. Но кроме того, это область, в которой все может пойти не так, особенно когда стандартные правила не соблюдаются. Цель верификационных требований в этой главе состоит в том, чтобы убедиться, что проверяемое приложение использует криптографию в соответствии с лучшими практиками индустрии, такими, как: - -- Использование проверенных криптографических библиотек; -- Правильный выбор и настройка криптографических алгоритмов; -- Подходящий генератор случайных чисел там, где это необходимо. - -## Требования безопасности - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | Приложение не использует симметричное шифрование с захардкоженными ключами в качестве единственного метода шифрования.| x | x | -| **3.2** | MSTG-CRYPTO-2 | Приложение использует проверенные реализации криптографических алгоритмов. | x | x | -| **3.3** | MSTG-CRYPTO-3 | Приложение использует подходящие криптографические алгоритмы для каждого конкретного случая, с параметрами, которые соответствуют лучшим практикам индустрии. | x | x | -| **3.4** | MSTG-CRYPTO-4 | Приложение не использует устаревшие и слабые криптографические протоколы и алгоритмы. | x | x | -| **3.5** | MSTG-CRYPTO-5 | Приложение не использует один и тот же ключ несколько раз. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Все случайные значения генерируются с использованием безопасного генератора случайных чисел. | x | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации требований, перечисленных в этом разделе. - -- Android: Тестирование криптографии - -- iOS: Тестирование криптографии - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-ru/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-ru/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 4c712d4a9..000000000 --- a/Document-ru/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Требования к аутентификации и управлению сессиями - -## Цель верификации - -В большинстве случаев авторизация в удаленных сервисах являются неотъемлемой частью общей архитектуры мобильного приложения. Несмотря на то, что большая часть логики происходит на бэкенде, MASVS определяет некоторые основные требования, касающиеся управления учетными записями пользователей и сессиями. - -## Требования безопасности - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Если приложение предоставляет пользователям доступ к удалённым сервисам, на бэкенде должна быть реализована аутентификация, например, по логину и паролю. | x | x | -| **4.2** | MSTG-AUTH-2 | Если используются сессии, бэкенд случайно генерирует идентификаторы сессии для аутентификации клиентских запросов без отправки данных учётной записи. | x | x | -| **4.3** | MSTG-AUTH-3 | Если используется аутентификация на основе токена, сервер предоставляет токен, подписанный с использованием безопасного криптоалгоритма. | x | x | -| **4.4** | MSTG-AUTH-4 | Бэкенд удаляет существующую сессию, когда пользователь выходит из системы. | x | x | -| **4.5** | MSTG-AUTH-5 | На сервере реализована парольная политика. | x | x | -| **4.6** | MSTG-AUTH-6 | На сервере реализован механизм защиты от перебора авторизационных данных. | x | x | -| **4.7** | MSTG-AUTH-7 | Биометрическая аутентификация не является event-bound (т.е. использует только API, которое возвращает «true» или «false»). Вместо этого она основана на разблокировке keychain/keystore. | | x | -| **4.8** | MSTG-AUTH-8 | Сессии становятся невалидными на бэкенде после определенного периода бездействия, срок действия токена истекает. | x | x | -| **4.9** | MSTG-AUTH-9 | Реализована и поддерживается двухфакторная аутентификация. | | x | -| **4.10** | MSTG-AUTH-10 | Для выполнения чувствительных транзакций требуется дополнительная или повторная аутентификацию. | | x | -| **4.11** | MSTG-AUTH-11 | Приложение информирует пользователя о всех важных действиях с их учетной записью. Пользователи могут просматривать список устройств, просматривать контекстную информацию (IP-адрес, местоположение и т.д.), и блокировать конкретные устройства. | | x | -| **4.12** | MSTG-AUTH-12 | Модели авторизации должны быть определены и проверены на сервере. | x | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации требований, перечисленных в этом разделе. - -- Общее: Аутентификация и управление сессиями - -- Android: Тестирование локальной аутентификации - -- iOS: Тестирование локальной аутентификации - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-ru/0x10-V5-Network_communication_requirements.md b/Document-ru/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 1a12a90c5..000000000 --- a/Document-ru/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Требования к сетевому взаимодействию - -## Цель верификации - -Целью требований, перечисленных в этом разделе, является обеспечение конфиденциальности и целостности информации, передаваемой между мобильным приложением и сервером. Как минимум в мобильном приложении должен быть настроен безопасный шифрованный канал передачи данных с использованием протокола TLS с соответствующими настройками. L2 содержит меры усиленной защиты, такие, как SSL pinning. - -## Требования безопасности - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Данные, передаваемые по сети, шифруются с использованием TLS. Безопасный канал используется для всех сервисов приложения. | x | x | -| **5.2** | MSTG-NETWORK-2 | Настройки TLS соответствуют современным лучшим практикам, или максимально приближены к ним, если операционная система не поддерживает рекомендуемые стандарты. | x | x | -| **5.3** | MSTG-NETWORK-3 | Приложение верифицирует X.509 сертификаты сервера во время установления защищённого канала. Принимаются только сертификаты, подписанные доверенным удостоверяющим центром (CA). | x | x | -| **5.4** | MSTG-NETWORK-4 | В приложении реализован SSL pinning и соединение с серверами, которые предлагают другой сертификат или ключ, даже если они подписаны доверенным центром сертификации (CA) не устанавливается. | | x | -| **5.5** | MSTG-NETWORK-5 | Приложение не полагается на единственный небезопасный канал связи (e-mail или SMS) для таких критических операций, как регистрация и восстановление аккаунта. | | x | -| **5.6** | MSTG-NETWORK-6 | Приложение использует только актуальные версии библиотек для подключения к сети и обеспечения безопасного соединения. | | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации требований, перечисленных в этом разделе. - -- Общее: Тестирование сетевого взаимодействия - -- Android: Тестирование сетевого взаимодействия - -- iOS: Тестирование сетевого взаимодействия - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-ru/0x11-V6-Interaction_with_the_environment.md b/Document-ru/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 424decae6..000000000 --- a/Document-ru/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Требования к взаимодействию с операционной системой - -## Цель верификации - -Следование требованиям этого раздела обеспечивают безопасное использование API операционной системы. Дополнительно содержатся требования к межпроцессному взаимодействию (IPC). - -## Требования безопасности - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | Приложение запрашивает минимально необходимый набор разрешений. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Все данные, поступающие из внешних источников и от пользователя, валидируются и санитизируются. Сюда входят данные, полученные через пользовательский интерфейс, механизмы IPC (такие как intent-ы, кастомные URL-схемы) и из сети.| x | x | -| **6.3** | MSTG-PLATFORM-3 | Приложение не экспортирует чувствительные данные через кастомные URL-схемы, если эти механизмы не защищены должным образом. | x | x | -| **6.4** | MSTG-PLATFORM-4 | Приложение не экспортирует чувствительные данные через IPC механизмы без должной защиты. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript отключен в компонентах WebView, если в нём нет необходимости. | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebView сконфигурирован с поддержкой минимального набора протоколов (в идеале только https). Поддержка потенциально опасных URL-схем (таких как: file, tel и app-id) отключена. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Если нативные методы приложения используются WebView, верифицировать, что исполняются только Javascript объекты данного приложения. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Десериализация объектов, если она есть, реализована с использованием безопасного API. | x | x | -| **6.9** | MSTG-PLATFORM-9 | Приложение защищает себя от атак наложения экрана. (Только для Андроид) | | x | -| **6.10** | MSTG-PLATFORM-10 | Кэш WebView, хранилище и загруженные ресурсы (JavaScript и т. д.) должны быть очищены до того, как WebView будет уничтожен. | | x | -| **6.11** | MSTG-PLATFORM-11 | Убедитесь, что приложение предотвращает использование пользовательских клавиатур сторонних производителей при вводе конфиденциальных данных. (Только для iOS) | | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации требований, перечисленных в этом разделе. - -- Android: Тестирование взаимодействия с платформой - [https://github.com/OWASP/owasp-mastg/blob/master/Document/0x05h-Testing-Platform-Interaction.md](https://github.com/OWASP/owasp-mastg/blob/master/Document/0x05h-Testing-Platform-Interaction.md) -- iOS: Тестирование взаимодействия с платформой - [https://github.com/OWASP/owasp-mastg/blob/master/Document/0x06h-Testing-Platform-Interaction.md](https://github.com/OWASP/owasp-mastg/blob/master/Document/0x06h-Testing-Platform-Interaction.md) - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-ru/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-ru/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 3d8384287..000000000 --- a/Document-ru/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Требования к качеству кода и настройкам сборки - -## Цель контроля - -Следование требованиям данного раздела обеспечивает использование базовых практик безопасного написания кода при разработке приложения, а также стандартных средств безопасности, встроенных в компилятор. - -## Требования безопасности - -| # | MSTG-ID | Описание | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | Приложение подписано валидным сертификатом. | x | x | -| **7.2** | MSTG-CODE-2 | Приложение было собрано в release режиме с настройками, подходящими для релизной сборки (например, без атрибута debuggable). | x | x | -| **7.3** | MSTG-CODE-3 | Отладочные символы удалены из нативных бинарных файлов. | x | x | -| **7.4** | MSTG-CODE-4 | Kод отладки и вспомогательный для разработки код (например, тестовый код, бэкдоры, скрытые настройки) были удалены. Приложение не логирует подробные ошибки и отладочные сообщения. | x | x | -| **7.5** | MSTG-CODE-5 | Все сторонние компоненты, используемые мобильным приложением (библиотеки и фреймворки), идентифицированы и проверены на наличие известных уязвимостей. | x | x | -| **7.6** | MSTG-CODE-6 | Приложение обрабатывает возможные исключения.| x | x | -| **7.7** | MSTG-CODE-7 | В логике обработки связанных с безопасностью ошибок по умолчанию запрещается доступ. | x | x | -| **7.8** | MSTG-CODE-8 | В неконтролируемом коде память выделяется, освобождается и используется безопасно. | x | x | -| **7.9** | MSTG-CODE-9 | Активированы все стандартные функции безопасности, предусмотренные инструментами разработчика (такие как минификация байт-кода, защита стека, поддержка PIE и ARC). | x | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по проверке требований, перечисленных в этом разделе. - -- Android: Тестирование качества кода и настроек сборки - -- iOS: Тестирование качества кода и настроек сборки - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-ru/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-ru/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 7254a6b19..000000000 --- a/Document-ru/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,66 +0,0 @@ -# V8: Требования к устойчивости к атакам на стороне клиента - -## Цель проверки - -В этом разделе рассматриваются меры усиленной защиты, рекомендуемые для приложений, которые обрабатывают или предоставляют доступ к чувствительным данным или функциональности. Отсутствие каких-либо из этих элементов защиты не означает наличие уязвимости - напротив, они призваны повысить устойчивость приложения к реверс инжинирингу и конкретным атакам на стороне клиента. - -Требования в этом разделе должны применяться по мере необходимости, основываясь на оценке рисков, вызванных несанкционированным вмешательством в приложение и/или восстановлением исходного кода. Мы предлагаем обратиться к документу OWASP «Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention» (см. ссылки ниже) для составления списка бизнес рисков и связанных с ними технических угроз. - -**Обратите внимание, что программные меры защиты из данного раздела не должны использоваться в качестве замены основным требованиям безопасности. Вместо этого они должны быть реализованы как специализированное дополнение, направленное на локализацию конкретных угроз, в мобильном приложении, соответствующем требования MASVS.** - -Следует рассмотреть следующие соображения: - -1. Должна быть определена модель угроз, в которой прописаны конкретные атаки на стороне клиента, от которых необходимо защититься. Кроме того, должна быть указана степень защиты, которую следует обеспечить. Например, цель внедрения защитных мер может заключаться в том, чтобы заставить авторов вредоносного ПО, нацеленного на данное приложение, приложить значительные усилия для реверс инжиниринга. - -2. Модель угроз должна отвечать здравому смыслу. Например, сокрытие криптографического ключа в whitebox реализации не имеет смысла, если злоумышленник может применить технику «code lifting». - -3. Эффективность защиты всегда должна проверяться экспертом, имеющим опыт тестирования методов обфускации и защиты от фальсификации (см. также главы «Реверс инжиниринг» и «Оценка защиты ПО» в OWASP MSTG. - -### Противодействие динамическому анализу и фальсификациям - -| # | MSTG-ID | Описание | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | Приложение обнаруживает и реагирует на наличие root или jailbreak, либо уведомляя пользователя, либо прекращая работу. | x | -| **8.2** | MSTG-RESILIENCE-2 | Приложение не позволяет использовать отладчики и/или обнаруживает и реагирует на использование отладчика. Все доступные протоколы отладки должны быть учтены. | x | -| **8.3** | MSTG-RESILIENCE-3 | Приложение обнаруживает и реагирует на внесения изменений в исполняемые файлы и критичные данные в своей песочнице. | x | -| **8.4** | MSTG-RESILIENCE-4 | Приложение обнаруживает и реагирует на наличие на устройстве широко используемых инструментов и фреймворков для реверс инжиниринга.| x | -| **8.5** | MSTG-RESILIENCE-5 | Приложение обнаруживает и реагирует на запуск на эмуляторе. | x | -| **8.6** | MSTG-RESILIENCE-6 | Приложение обнаруживает и реагирует на изменение своего кода и данных в оперативной памяти. | x | -| **8.7** | MSTG-RESILIENCE-7 | Приложение реализует несколько механизмов для каждой категории защиты (с 8.1 по 8.6). Обратите внимание, что на устойчивость к атакам влияет количество, разнообразие и оригинальность используемых механизмов. | x | -| **8.8** | MSTG-RESILIENCE-8 | Механизмы обнаружения инициируют ответные меры разных типов, включая отложенные и скрытые. | x | -| **8.9** | MSTG-RESILIENCE-9 | Обфускация применена в том числе и к тем программным механизмам, которые препятствуют деобфускации методами динамического анализа. | x | - - - -### Привязка к устройству - -| # | MSTG-ID | Описание | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | Приложение реализует функциональность привязки экземпляра приложения к устройству, формируя его отпечаток из нескольких свойств, уникальных для устройства. | x | - -### Противодействие восстановлению логики работы приложения - -| # | MSTG-ID | Описание | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Все исполняемые файлы и библиотеки, принадлежащие приложению, зашифрованы на файловом уровне, либо важные участки кода и данных зашифрованы внутри исполняемых файлов. Простой статический анализ не позволяет обнаружить важный код или данные. | x | -| **8.12** | MSTG-RESILIENCE-12 | Если задачей обфускации является защита конфиденциальных данных, то используется схема обфускации, которая подходит не только для этой задачи, но и защищает от ручной тестирования и автоматизированных деобфускаторов и учитывает последние исследования по данной теме. Эффективность схемы обфускации должна быть проверена с помощью ручного тестирования. Обратите внимание, что использование аппаратных средств защиты (если они поддерживаются устройством) предпочтительнее обфускации. | x | - -### Противодействие Перехвату Сообщений - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | В качестве глубокой защиты, наряду с существенным усилением защиты взаимодействия, шифрование обмениваемых приложением сообщений может шифроваться для дальнейшего предотвращения перехвата. | x | - -## Ссылки - -OWASP MSTG содержит подробные инструкции по верификации соответствия требованиям, перечисленным в этом разделе. - -- Android: Тестирование устойчивости к обратной разработке - -- iOS: Тестирование устойчивости к обратной разработке - - -Для получения дополнительной информации смотрите также: - -- OWASP Mobile Top 10: M8 (Фальсификация кода) - -- OWASP Mobile Top 10: M9 (Обратная разработка) - -- ОWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-ru/0x90-Appendix-A_Glossary.md b/Document-ru/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 75010c4c0..000000000 --- a/Document-ru/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Приложение A: Список терминов - -- **Address Space Layout Randomization (ASLR)** – Метод, затрудняющий использование ошибок повреждения памяти. -- **Application Security** – Безопасность на уровне приложений, сфокусированная на анализе компонентов, которые составляют прикладной уровень модели OSI (Open Systems Interconnection Reference), без рассмотрения безопасности, например, операционной системы или подключенных сетей. -- **Application Security Verification** – Оценка соответствия требованиям OWASP MASVS. -- **Application Security Verification Report** – Отчёт, включающий общие результаты проверки и анализа конкретного приложения, проведённые специалистом по безопасности. -- **Authentication** – Верификация соответствия пользователя приложения заявленной им личности. -- **Automated Verification** – Использование автоматических инструментов (для динамического и статического анализа), использующих сигнатуры уязвимостей для поиска проблемных участков приложения. -- **Black box testing** – Метод тестирования ПО, который анализирует функциональность приложения без знания о его внутреннем устройстве и принципах работы. -- **Component** – автономный блок кода, с соответствующими дисковыми и сетевыми интерфейсами, который взаимодействует с другими компонентами. -- **Cross-Site Scripting (XSS)** – Уязвимость, обычно обнаруживаемая в веб-приложениях, позволяющая внедрить в контент веб-страницы вредоносный код, исполняемый на стороне клиента. -- **Cryptographic module** – Аппаратное, программное, или программно-аппаратное обеспечение, реализующее криптографические алгоритмы и/или генерирует криптографические ключи. -- **CWE** – Общедоступный список часто встречающихся недостатков безопасности программного обеспечения. -- **DAST** – Динамический анализ безопасности (Dynamic application security testing) - поиск уязвимостей приложения во время его выполнения. -- **Design Verification** – Техническая оценка безопасности архитектуры приложения. -- **Dynamic Verification** – Использование автоматических инструментов для поиска уязвимостей во время выполнения приложения. -- **Globally Unique Identifier (GUID)** – уникальный номер, используемый в качестве идентификатора в программном обеспечении. -- **Hyper Text Transfer Protocol (HTTP)** – Протокол прикладного уровня для распределенных, совместных, гипермедийных информационных систем. Это основа передачи данных для Всемирной паутины. -- **Hardcoded keys** – захардкоженные ключи (хранятся непосредственно в коде приложения). -- **IPC** – межпроцессное взаимодействие (Inter Process Communications), в IPC процессы взаимодействуют друг с другом и ядром, чтобы координировать свою деятельность. -- **Input Validation** – Канонизация и проверка недоверенных данных, вводимых пользователем. -- **JAVA Bytecode** – Java байт-код - набор команд виртуальной машины Java (JVM). Каждый байт-код состоит из одного или, в некоторых случаях, двух байтов, которые представляют команду (код операции), а также ноль или более байтов для передачи параметров. -- **Malicious Code** – вредоносный код, добавленный в приложение во время его разработки без ведома владельца приложения, который обходит заложенную политику безопасности. Не то же самое, что вредоносное ПО, такое как вирус или червь! -- **Malware** – Исполняемый код, который вводится в приложение во время выполнения без ведома пользователя или администратора приложения. -- **Open Web Application Security Project (OWASP)** – Проект Open Web Application Security (OWASP) является всемирным бесплатным и открытым сообществом, направленным на повышение безопасности прикладного программного обеспечения. Наша миссия заключается в том, чтобы сделать безопасность приложений «видимой», чтобы люди и организации могли принимать обоснованные решения о рисках безопасности приложений. -- **Personally Identifiable Information (PII)** – Информация, которая может использоваться сама по себе или совместно с другой информацией для идентификации, получения контактов или поиска местонахождения человека. -- **PIE** – Независимый от положения исполняемый файл (PIE) представляет собой тело машинного кода, которое, будучи помещённым где-то в первичной памяти, выполняется должным образом независимо от его абсолютного адреса. -- **PKI** – PKI - это соглашение, которое связывает открытые ключи с соответствующими идентификаторами объектов. Связь устанавливается посредством процесса регистрации и выдачи сертификатов в удостоверяющем центре (CA). -- **SAST** – Статический анализ безопасности (SAST) представляет собой набор техник, предназначенных для анализа исходного кода приложения, байт-кода и бинарных файлов для обнаружения ошибок при написании кода и проектировании, которые приводят к уязвимостям. Решения SAST анализируют приложение «изнутри» в неработающем состоянии. -- **SDLC** – Жизненный цикл разработки программного обеспечения. -- **Security Architecture** – Абстракция проектирования приложения, которая идентифицирует и описывает, где и как используются требования безопасности, а также идентифицирует и описывает местоположение и чувствительность данных пользователя и приложения. -- **Security Configuration** – Конфигурация исполнения приложения, влияющая на то, как используются требования безопасности. -- **Security Control** – Функция или компонент, который выполняет проверку безопасности (например, проверку контроля доступа) или при вызове, влияет на безопасность (например, генерирует запись аудита). -- **SQL Injection (SQLi)** – Техника внедрения SQL кода в запрос к БД, используемая для атаки на мобильные и веб-приложения. -- **SSO Authentication** – Single Sign On (SSO) возникает, когда пользователь входит в аккаунт на одном клиенте, и происходит автоматический вход на других клиентах, независимо от платформы, технологии или домена, которые использует пользователь. Например, когда вы авторизуетесь в Google, вы автоматически авторизуетесь на YouTube, Google Docs и Gmail. -- **Threat Modeling** – Метод, состоящий в разработке все более совершенных архитектур безопасности для идентификации угроз, зон безопасности, средств контроля безопасности и важных технических и бизнес-активов. -- **Transport Layer Security** – Криптографические протоколы, обеспечивающие безопасность соединения по Интернету. -- **URI/URL/URL fragments** – Единый идентификатор ресурса - это строка символов, используемых для идентификации имени или веб-ресурса. URL часто используется в качестве ссылки на ресурс. -- **User acceptance testing (UAT)** – Тестовая среда, которая ведет себя как производственная среда, где все тестирование программного обеспечения выполняется до перехода в лайв. -- **Verifier** – Лицо или команда, которая проверяет приложение на соответствие требованиям ASVS OWASP. -- **Whitelist** – Список разрешённых данных или операций, например список символов, которые могут быть поданы на вход. -- **X.509 Certificate** – Сертификат X.509 это цифровой сертификат, использующий международную инфраструктуру открытых ключей (PKI) для проверки того, что открытый ключ принадлежит пользователю, компьютеру или сервису, указанному в сертификате. diff --git a/Document-ru/0x91-Appendix-B_References.md b/Document-ru/0x91-Appendix-B_References.md deleted file mode 100644 index d0430ab77..000000000 --- a/Document-ru/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Приложение B: Ссылки - -Следующие проекты OWASP будут полезны для пользователей/последователей этого стандарта: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -Следующие веб-сайты также будут полезны для пользователей/последователей этого стандарта: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-ru/CHANGELOG.md b/Document-ru/CHANGELOG.md deleted file mode 100644 index bda609686..000000000 --- a/Document-ru/CHANGELOG.md +++ /dev/null @@ -1,98 +0,0 @@ -# Список изменений - -## V1.3 - 13 May 2021 - -Мы с гордостью сообщаем о введении нового конвейера сборки документов, который является важной вехой для нашего проекта. Конвейер сборки основан на проектах [Pandocker](https://github.com/dalibo/pandocker) и [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -Нововведение значительно сокращает время, затрачиваемое на создание новых сборок, а также станет основой для OWASP MSTG и будет доступно для проекта OWASP ASVS. - -### Изменения - -- Добавлено 4 новых перевода: Хинди, Персидский, Португальский и Бразильский вариант Португальского. -- Добавлено требование MSTG-PLATFORM-11 - -### Специальная благодарность - -- Jeroen Willemsen за запуск инициативы в прошлом году! -- Damien Clochard и Dalibo за поддержку и профессионализацию конвейера сборки. -- Всем нашим иностранным переводчикам за прекрасно проделанную работу. - -## V1.2 - 7 марта 2020 - Международный релиз - -Следующие изменения представлены в релизе 1.2: - -- MASVS доступен на упрощенном китайском. -- Изменено название в обложке книги MASVS. -- Удалены Mobile Top 10 и CWE из MSTG и объединены с существующими ссылками в MASVS. - -## V1.2-RC - 5 октября 2019 - Предварительный релиз - -Изменения в релизе 1.2: - -- Повышен до статуса флагмана. -- Изменено требование: MSTG-STORAGE-1 "нужно использовать". -- Добавлены требования MSTG-STORAGE-13, MSTG-STORAGE-14, и MSTG-STORAGE-15 с акцентом на защиту данных. -- Изменено требование MSTG-AUTH-11 для сохранения контекстной информации. -- Изменено требование MSTG-CODE-4 чтобы охватить больше чем просто отладка. -- Добавлено требование MSTG-PLATFORM-10 для более безопасного использования WebView. -- Добавлено требование MSTG-AUTH-12 чтобы напомнить разработчикам о внедренных разрешениях пользователей, особенно в случае многопользовательских приложений. -- Добавлено немного больше описания того, как следует использовать MASVS с учетом оценки риска. -- Добавлено еще немного описания платного контента. -- Добавлено требование MSTG-ARCH-11, чтобы включить политику раскрытия информации для приложений L2. -- Добавлено требование MSTG-ARCH-12, чтобы показать разработчикам, что соответствующие международные законы о конфиденциальности должны соблюдаться. -- Создан согласованный стиль для всех ссылок в английской версии. -- Добавлено требование MSTG-PLATFORM-11 для противодействия шпионажу с помощью сторонних клавиатур. -- Добавлено требование MSTG-MSTG-RESILIENCE-13 для предотвращения перехвата данных в приложении. - -## V1.1.4 - 4 Июля 2019 - Саммит версия - -Изменения в релизе 1.1.4: - -- Исправлены все ошибки markdown. -- Обновления во французском и испанском переводах. -- Список изменений переведен на китайский и японский языки. -- Автоматизирована проверка markdown синтаксиса и доступность ссылок в документах. -- Для облегчения поиска рекомендаций и тест-кейсов добавлены идентификационные номера требований, которые будут включены в следующих версиях MSTG. -- Уменьшен размер репозитория и папка Generated добавлена в .gitignore. -- Добавлен Кодекс Поведения и Рекомендации по внесению изменений. -- Добавлен шаблон для пул-реквестов. -- Обновлена синхронизация с актуальным репозиторием для хостинга Gitbook сайта. -- Обновлены скрипты для генерации XML/JSON/CSV для всех переводов. -- Вступление переведено на китайский язык. - -## V1.1.3 - 9 Января 2019 - Мелкие Изменения - -Изменения в релизе 1.1.3: - -- Исправлена ошибка перевода требования 7.1 на испанский язык. -- Новый раздел переводчиков в списке благодарностей. -- Мелкие изменения в японском переводе. - -## V1.1.2 - 3 Января 2019 - Спонсорство и интернационализация - -Изменения в релизе 1.1.2: - -- Добавлены благодарности купившим электронную версию книгу. -- Добавлена отсутствующая ссылка для аутентификации и обновлена поломанная ссылка для аутентификации в V4. -- Исправлены поменянные местами требования 4.7 и 4.8 в английской версии. -- Первый интернациональный релиз! - - Исправления в переводе на испанский язык. Перевод синхронизирован с английской версией (1.1.2). - - Исправления в переводе на русский язык. Перевод синхронизирован с английской версией (1.1.2). - - Добавлены первые версии переводов на китайский, французский, немецкий и японский языки! -- Для облегчения переводов документ был упрощен. -- Добавлены инструкции для автоматического релиза. - -## V1.1.0 - 14 Июля 2018 - -Изменения в релизе 1.1: - -- Удалено требование 2.6 "Буфер обмена выключен для текстовых полей, которые могут содержать конфиденциальные данные." -- Добавлено требование 2.2 "Конфиденциальные данные хранятся только во внутреннем хранилище приложения, либо в системном хранилище авторизационных данных." -- Требование 2.1 перефразировано в "Хранилище учетных данных системы используется надлежащим образом для хранения конфиденциальных данных, таких как персональные данные, данные пользователя для авторизации и криптографические ключи." - -## V1.0 - 12 Января 2018 - -Изменения в релизе 1.0: - -- Удалена глава 8.9 как идентичная главе 8.12 -- Обобщена глава 4.6 -- Мелкие изменения (опечатки и др.) diff --git a/Document-ru/GLOSSARY.md b/Document-ru/GLOSSARY.md deleted file mode 100644 index bcfc2aeda..000000000 --- a/Document-ru/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Приложение A: Список терминов - -## Address Space Layout Randomization (ASLR) - -Метод, затрудняющий использование ошибок повреждения памяти. - -## Application Security - -Безопасность на уровне приложений, сфокусированная на анализе компонентов, которые составляют прикладной уровень модели OSI (Open Systems Interconnection Reference), без рассмотрения безопасности, например, операционной системы или подключенных сетей. - -## Application Security Verification - -Оценка соответствия требованиям OWASP MASVS. - -## Application Security Verification Report - -Отчёт, включающий общие результаты проверки и анализа конкретного приложения, проведённые специалистом по безопасности. - -## Authentication - -Верификация соответствия пользователя приложения заявленной им личности. - -## Automated Verification - -Использование автоматических инструментов (для динамического и статического анализа), использующих сигнатуры уязвимостей для поиска проблемных участков приложения. - -## Black box testing - -Метод тестирования ПО, который анализирует функциональность приложения без знания о его внутреннем устройстве и принципах работы. - -## Component - -автономный блок кода, с соответствующими дисковыми и сетевыми интерфейсами, который взаимодействует с другими компонентами. - -## Cross-Site Scripting (XSS) - -Уязвимость, обычно обнаруживаемая в веб-приложениях, позволяющая внедрить в контент веб-страницы вредоносный код, исполняемый на стороне клиента. - -## Cryptographic module - -Аппаратное, программное, или программно-аппаратное обеспечение, реализующее криптографические алгоритмы и/или генерирует криптографические ключи. - -## CWE - -Общедоступный список часто встречающихся недостатков безопасности программного обеспечения. - -## DAST - -Динамический анализ безопасности (Dynamic application security testing) - поиск уязвимостей приложения во время его выполнения. - -## Design Verification - -Техническая оценка безопасности архитектуры приложения. - -## Dynamic Verification - -Использование автоматических инструментов для поиска уязвимостей во время выполнения приложения. - -## Globally Unique Identifier (GUID) - -уникальный номер, используемый в качестве идентификатора в программном обеспечении. - -## Hyper Text Transfer Protocol (HTTP) - -Протокол прикладного уровня для распределенных, совместных, гипермедийных информационных систем. Это основа передачи данных для Всемирной паутины. - -## Hardcoded keys - -захардкоженные ключи (хранятся непосредственно в коде приложения). - -## IPC - -межпроцессное взаимодействие (Inter Process Communications), в IPC процессы взаимодействуют друг с другом и ядром, чтобы координировать свою деятельность. - -## Input Validation - -Канонизация и проверка недоверенных данных, вводимых пользователем. - -## JAVA Bytecode - -Java байт-код - набор команд виртуальной машины Java (JVM). Каждый байт-код состоит из одного или, в некоторых случаях, двух байтов, которые представляют команду (код операции), а также ноль или более байтов для передачи параметров. - -## Malicious Code - -вредоносный код, добавленный в приложение во время его разработки без ведома владельца приложения, который обходит заложенную политику безопасности. Не то же самое, что вредоносное ПО, такое как вирус или червь! - -## Malware - -Исполняемый код, который вводится в приложение во время выполнения без ведома пользователя или администратора приложения. - -## Open Web Application Security Project (OWASP) - -Проект Open Web Application Security (OWASP) является всемирным бесплатным и открытым сообществом, направленным на повышение безопасности прикладного программного обеспечения. Наша миссия заключается в том, чтобы сделать безопасность приложений «видимой», чтобы люди и организации могли принимать обоснованные решения о рисках безопасности приложений. - -## Personally Identifiable Information (PII) - -Информация, которая может использоваться сама по себе или совместно с другой информацией для идентификации, получения контактов или поиска местонахождения человека. - -## PIE - -Независимый от положения исполняемый файл (PIE) представляет собой тело машинного кода, которое, будучи помещённым где-то в первичной памяти, выполняется должным образом независимо от его абсолютного адреса. - -## PKI - -PKI - это соглашение, которое связывает открытые ключи с соответствующими идентификаторами объектов. Связь устанавливается посредством процесса регистрации и выдачи сертификатов в удостоверяющем центре (CA). - -## SAST - -Статический анализ безопасности (SAST) представляет собой набор техник, предназначенных для анализа исходного кода приложения, байт-кода и бинарных файлов для обнаружения ошибок при написании кода и проектировании, которые приводят к уязвимостям. Решения SAST анализируют приложение «изнутри» в неработающем состоянии. - -## SDLC - -Жизненный цикл разработки программного обеспечения. - -## Security Architecture - -Абстракция проектирования приложения, которая идентифицирует и описывает, где и как используются требования безопасности, а также идентифицирует и описывает местоположение и чувствительность данных пользователя и приложения. - -## Security Configuration - -Конфигурация исполнения приложения, влияющая на то, как используются требования безопасности. - -## Security Control - -Функция или компонент, который выполняет проверку безопасности (например, проверку контроля доступа) или при вызове, влияет на безопасность (например, генерирует запись аудита). - -## SQL Injection (SQLi) - -Техника внедрения SQL кода в запрос к БД, используемая для атаки на мобильные и веб-приложения. - -## SSO Authentication - -Single Sign On (SSO) возникает, когда пользователь входит в аккаунт на одном клиенте, и происходит автоматический вход на других клиентах, независимо от платформы, технологии или домена, которые использует пользователь. Например, когда вы авторизуетесь в Google, вы автоматически авторизуетесь на YouTube, Google Docs и Gmail. - -## Threat Modeling - -Метод, состоящий в разработке все более совершенных архитектур безопасности для идентификации угроз, зон безопасности, средств контроля безопасности и важных технических и бизнес-активов. - -## Transport Layer Security - -Криптографические протоколы, обеспечивающие безопасность соединения по Интернету. - -## URI/URL/URL fragments - -Единый идентификатор ресурса - это строка символов, используемых для идентификации имени или веб-ресурса. URL часто используется в качестве ссылки на ресурс. - -## User acceptance testing (UAT) - -Тестовая среда, которая ведет себя как производственная среда, где все тестирование программного обеспечения выполняется до перехода в лайв. - -## Verifier - -Лицо или команда, которая проверяет приложение на соответствие требованиям ASVS OWASP. - -## Whitelist - -Список разрешённых данных или операций, например список символов, которые могут быть поданы на вход. - -## X.509 Certificate - -Сертификат X.509 это цифровой сертификат, использующий международную инфраструктуру открытых ключей (PKI) для проверки того, что открытый ключ принадлежит пользователю, компьютеру или сервису, указанному в сертификате. diff --git a/Document-ru/SUMMARY.md b/Document-ru/SUMMARY.md deleted file mode 100644 index 7ec9e69f7..000000000 --- a/Document-ru/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Резюме - -- [Вступительное](0x01-Foreword.md) -- [Changelog](CHANGELOG.md) -- [фронтиспис](0x02-Frontispiece.md) -- [Использование MASVS](0x03-Using_the_MASVS.md) -- [Оценка и Сертификация](0x04-Assessment_and_Certification.md) - -## Требования безопасности - -- [V1: Требования к архитектуре, проектированию и моделированию угроз](0x06-V1-Architecture_design_and_threat_modelling_requirements.md) -- [V2: Хранение данных и требования конфиденциальности](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Требования к криптографии](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Аутентификация и требования к управлению сессиями](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Требования к сетевой связи](0x10-V5-Network_communication_requirements.md) -- [V6: Требования к взаимодействию платформ](0x11-V6-Interaction_with_the_environment.md) -- [V7: Требования к качеству кода и настройке сборки](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Требования к устойчивости](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendix - -- [Appendix A - Glossary](GLOSSARY.md) -- [Appendix B - References](0x91-Appendix-B_References.md) diff --git a/Document-ru/book.json b/Document-ru/book.json deleted file mode 100644 index 26e8d1836..000000000 --- a/Document-ru/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "ru" -} diff --git a/Document-ru/images/CC-license.png b/Document-ru/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-ru/images/CC-license.png and /dev/null differ diff --git a/Document-ru/images/MASVS-levels.png b/Document-ru/images/MASVS-levels.png deleted file mode 100755 index 62a601769..000000000 Binary files a/Document-ru/images/MASVS-levels.png and /dev/null differ diff --git a/Document-ru/images/OWASP_logo.png b/Document-ru/images/OWASP_logo.png deleted file mode 100755 index ca9268c9b..000000000 Binary files a/Document-ru/images/OWASP_logo.png and /dev/null differ diff --git a/Document-ru/images/cover.jpg b/Document-ru/images/cover.jpg deleted file mode 100644 index 374f4072e..000000000 Binary files a/Document-ru/images/cover.jpg and /dev/null differ diff --git a/Document-ru/images/license.png b/Document-ru/images/license.png deleted file mode 100755 index 124d3ba4d..000000000 Binary files a/Document-ru/images/license.png and /dev/null differ diff --git a/Document-ru/images/masvs-levels-new.jpg b/Document-ru/images/masvs-levels-new.jpg deleted file mode 100755 index 60e423a4e..000000000 Binary files a/Document-ru/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-ru/images/masvs-mini-cover.jpg b/Document-ru/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-ru/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-ru/images/masvs-mini-cover.png b/Document-ru/images/masvs-mini-cover.png deleted file mode 100644 index 1e3d72f72..000000000 Binary files a/Document-ru/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-ru/metadata.md b/Document-ru/metadata.md deleted file mode 100644 index c0117b635..000000000 --- a/Document-ru/metadata.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'ru' -languagetext: '(Russian Translation)' - -mainfont: 'Noto Sans' -sansfont: 'Noto Sans' -monofont: 'Noto Sans Mono' - -# toc-title is translated when `lang` is correctly defined -toc-title: 'Резюме' - ---- diff --git a/Document-tr/0x01-Foreword.md b/Document-tr/0x01-Foreword.md deleted file mode 100644 index 93f22572a..000000000 --- a/Document-tr/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# Önsöz - -Teknolojik devrimler hızlı bir şekilde gerçekleşebilir. On yıldan daha kısa bir süre önce, akıllı telefonlar küçük klavyeleri olan hantal cihazlardı - teknoloji meraklısı iş insanları için pahalı oyuncaklardı. Günümüzde ise akıllı telefonlar hayatımızın önemli bir parçası. Bilgi, navigasyon ve iletişim için onlara güvenmeye başladık ve hem iş hayatımızda hem de sosyal hayatımızda her yerde bulunuyorlar. - -Her yeni teknoloji, yeni güvenlik riskleri ortaya çıkarır ve bu değişikliklere ayak uydurmak, güvenlik endüstrisinin karşı karşıya kaldığı ana zorluklardan biridir. Savunma tarafı her zaman birkaç adım geride kalıyor. Örneğin, birçoğu için varsayılan refleks, işleri yapmanın eski yöntemlerini uygulamaktı: "Akıllı telefonlar küçük bilgisayarlar gibi ve mobil uygulamalar da tıpkı klasik yazılımlar gibidir - dolayısıyla aynı güvenlik gereksinimleri geçerlidir." Fakat bu böyle işlemiyor. Akıllı telefon işletim sistemleri masaüstü işletim sistemlerinden farklıdır ve mobil uygulamalar da web uygulamalarından farklıdır. Örneğin, klasik imza tabanlı virüs taraması yöntemi, modern mobil işletim sistemi ortamlarında bir anlam ifade etmez: Yalnızca mobil uygulama dağıtım modeliyle uyumsuz olmakla kalmaz, aynı zamanda korumalı alan kısıtlamaları nedeniyle teknik olarak imkansızdır. Ayrıca, arabellek taşmaları ve XSS gibi bazı güvenlik zafiyetleri istisnaları olsa da masaüstü ve web uygulamalarından ziyade mobil uygulamalar bağlamında daha az görülür. - -Zamanla, sektörümüz mobil tehdit ortamını daha iyi kavradı. Görününen o ki mobil güvenliği tamamen veri korumayla ilgilidir: Uygulamalar kişisel bilgilerimizi, resimlerimizi, kayıtlarımızı, notlarımızı, hesap verilerimizi, iş bilgilerimizi, konumumuzu ve daha fazlasını depolar. Bizi günlük kullandığımız hizmetlere bağlayan istemciler ve başkalarıyla paylaştığımız her mesajı işleyen iletişim merkezleri olarak davranırlar. Bir kişinin akıllı telefonunu ele geçirirseniz, o kişinin hayatına kısıtlama olmaksızın erişim sağlarsınız. Mobil cihazların daha kolay kaybolduğunu veya çalındığını düşündüğümüzde ve mobil kötü amaçlı yazılımların artışıyla birlikte veri koruma ihtiyacı daha da belirgin hale geliyor. - -Bu nedenle, mobil uygulamalar için bir güvenlik standardı, mobil uygulamaların hassas bilgileri nasıl işlediğine, depoladığına ve koruduğuna odaklanmalıdır. iOS ve Android gibi modern mobil işletim sistemleri, güvenli veri depolama ve iletişim için iyi API'ler sunsa da, bunların etkili olabilmeleri için doğru şekilde uygulanması ve kullanılması gerekir. Veri depolama, uygulamalar arası iletişim, kriptografik API'lerin uygun kullanımı ve güvenli ağ haberleşmesi, dikkatlice düşünülmesi gereken durumlardan yalnızca bazılarıdır. - -Sektörde fikir birliğine ihtiyaç duyan önemli bir soru, verilerin gizliliğini ve bütünlüğünü korumak için tam olarak ne kadar ileri gidilmesi gerektiğidir. Örneğin, çoğumuz bir mobil uygulamanın TLS değişiminde sunucu sertifikasını doğrulaması gerektiğini kabul ederiz. Peki ya SSL sertifikası sabitleme? Bunu yapmamak bir güvenlik açığıyla sonuçlanmaz mı? Eğer bir uygulama hassas verileri işliyorsa bu bir gereklilik olmalı mı, yoksa ters etki yaratabilir mi? İşletim sistemi uygulamayı korumalı alana alsa bile SQLite veritabanlarında depolanan verileri şifrelememiz gerekiyor mu? Bir uygulama için uygun olan şey bir başkası için gerçekçi olmayabilir. MASVS, farklı tehdit senaryolarına uyan doğrulama seviyelerini kullanarak bu gereksinimleri standartlaştırma girişimidir. - -Dahası, kök (root) zararlı yazılımlarının ve uzaktan yönetim araçlarının ortaya çıkması, mobil işletim sistemlerinin kendilerinin istismar edilebilir kusurları olduğu gerçeğine dair farkındalık yaratmıştır, bu nedenle, hassas verilere ek koruma sağlamak ve istemci tarafındaki müdahaleyi önlemek için konteynerleştirme stratejileri giderek daha fazla kullanılmaktadır. İşlerin karmaşıklaştığı yer de burasıdır. "Android for Work" ve "Samsung Knox" gibi donanım destekli güvenlik özellikleri ve işletim sistemi düzeyinde konteynerleştirme çözümleri mevcuttur, ancak bunlar farklı cihazlarda tutarlı bir şekilde kullanılamaz. Bir yara bandı olarak, yazılım tabanlı koruma önlemleri uygulamak mümkündür - ancak ne yazık ki, bu tür korumaları doğrulamak için standartlar veya test süreçleri yoktur. - -Sonuç olarak, mobil uygulama güvenlik testi raporları her yerde: Örneğin, bazı test uzmanları bir Android uygulamasında kod karmaşıklaştırma veya root algılama eksikliğini "güvenlik açığı" olarak bildiriyor. Öte yandan, dizgi şifreleme, hata ayıklayıcı tespiti veya kontrol akışının gizlenmesi gibi önlemler zorunlu olarak düşünülmez. Bununla birlikte, bu iki taraflı bakış açısı mantıklı değildir çünkü "dayanıklık" iki taraftan da bir öneri değildir: Savunmayı amaçladığı belirli istemci taraflı tehditlere bağlıdır. Yazılım korumaları işe yaramaz değildir, ancak eninde sonunda atlanabilirler, bu nedenle asla güvenlik kontrollerinin yerine kullanılmamalıdır. - -MASVS genel olarak, mobil uygulama güvenliği için bir temel sunmak (MASVS-L1), aynı zamanda derinlemesine savunma önlemlerinin (MASVS-L2) ve istemci taraflı tehditlere (MASVS-R) karşı korumaların dahil edilmesini hedefler. MASVS, aşağıdakileri gerçekleştirmeyi amaçlar: - -- Güvenli mobil uygulamalar geliştirmek isteyen geliştiriciler ve yazılım mimarları için gereksinimleri sağlamak; -- Mobil uygulama güvenlik incelemelerinde test edilebilecek bir endüstri standardı sunmak; -- Yazılım koruma mekanizmalarının mobil güvenlikteki rolünü netleştirmek ve etkinliklerini doğrulamak için gereksinimleri sağlamak; -- Farklı kullanım durumları için hangi güvenlik seviyesinin tavsiye edildiğine dair spesifik öneriler sunmak. - -%100 endüstri mutabakatına ulaşmanın imkansız olduğunun farkındayız. Yine de, MASVS'nin mobil uygulama geliştirme ve testlerinin tüm aşamalarında rehberlik sağlamada yararlı olacağını umuyoruz. Açık kaynak standardı olarak MASVS zamanla gelişecek ve her türlü katkı ve öneriyi memnuniyetle karşılıyoruz. - -Bernhard Mueller tarafından diff --git a/Document-tr/0x02-Frontispiece.md b/Document-tr/0x02-Frontispiece.md deleted file mode 100644 index 72c0a0c87..000000000 --- a/Document-tr/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# Standart Hakkında - -![OWASP Logo](images/OWASP_logo.png) - -Mobile Application Security Verification Standard (MASVS)'ye hoşgeldiniz. MASVS, iOS ve Android'de güvenli mobil uygulamaları tasarlamak, geliştirmek ve test etmek için gereken güvenlik gereksinimleri çerçevesini oluşturmaya yönelik bir topluluk çabasıdır. - -MASVS, topluluk çabalarının ve endüstri geri bildirimlerinin bir sonucudur. Bu standardın zaman içinde gelişmesini bekliyoruz ve topluluktan gelen geri bildirimleri memnuniyetle karşılıyoruz. - -Bizimle iletişime geçmenin en iyi yolu OWASP Mobile Project Slack kanalı: . - -Hesaplar aşağıdaki URL'de oluşturulabilir: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Telif Hakkı ve Lisans - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. Bu çalışma [Creative Commons Attribution-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-sa/4.0/) ile lisanslanmıştır. Herhangi bir yeniden kullanım veya dağıtım için, bu çalışmanın lisans koşullarını başkalarına açıklamalısınız. - - - -## Teşekkürler - -| Proje Lideri | Baş Yazar | Katkıda Bulunanlar ve İnceleyenler -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Dil | Çevirmenler ve İnceleyenler | -| --------------- | ------------------------------------------------------------ | -| Brazilian Portuguese | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Chinese (Traditonal) | Peter Chi, 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) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Kunwar Atul Singh, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 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, Milad Khoshdel | -| Portuguese | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Russian | Gall Maxim, Eugen Martynov, Chelnokov Vladislav (Review), Oprya Egor (Review), Tereshin Dmitry (Review) | -| Spanish | Martin Marsicano, Carlos Holguera | -| Türkçe | Anıl Baş, Haktan Emik | -| Yunan | Panagiotis Yialouris | - -Bu doküman, Jim Manico tarafından yazılan OWASP Uygulama Güvenliği Doğrulama Standardının bir kolu olarak başladı. - -## Sponsorlar - -Hem MASVS hem de MSTG gönüllü olarak topluluk tarafından oluşturulup sürdürülürken, bazı zamanlarda biraz dışarıdan yardım gerekir. Bu nedenle sponsorlarımıza teknik editörleri işe alabilmeleri için fon sağladıkları için teşekkür ederiz. Sponsorluklarının MASVS veya MSTG içeriğini hiçbir şekilde etkilemediği unutulmamalıdır. Sponsorluk paketleri şu sayfada açıklanmıştır: [OWASP Project Wiki](https://owasp.org/www-project-mobile-security-testing-guide/#div-sponsorship "OWASP Mobile Security Testing Guide Sponsorship Packages"). - - - -Ardından, sponsorlukları için OWASP Körfez Bölgesi Bölümüne teşekkür ederiz. Son olarak, kitabı [Leanpub'dan](https://leanpub.com/mobile-security-testing-guide) alan ve bize sponsor olan herkese teşekkür ederiz. diff --git a/Document-tr/0x03-Using_the_MASVS.md b/Document-tr/0x03-Using_the_MASVS.md deleted file mode 100644 index e47f48331..000000000 --- a/Document-tr/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,85 +0,0 @@ -# Mobil Uygulama Güvenlik Gereksinim Standardı - -MASVS, mobil uygulamaların güvenliğine yönelik bir güven düzeyi oluşturmak için kullanılabilir. Gereksinimler, aşağıdaki hedefler göz önünde bulundurularak geliştirilmiştir: - -- Metrik olarak kullanım - Mevcut mobil uygulamaların geliştiriciler ve uygulama sahipleri tarafından karşılaştırılabileceği bir güvenlik standardı sağlamak için; -- Kılavuz olarak kullanım - mobil uygulama geliştirme ve test sürecinin tüm fazlarında rehberlik sağlamak için; -- Tedarik sırasında kullanım - Mobil uygulama güvenlik doğrulaması için bir ana hat sağlamak için. - -## Mobil AppSec Modeli - -MASVS, iki güvenlik doğrulama düzeyini (MASVS-L1 ve MASVS-L2) ve bir dizi tersine mühendislik dayanıklılık gereksinimini (MASVS-R) tanımlar. MASVS-L1, tüm mobil uygulamalar için önerilen genel güvenlik gereksinimlerini içerirken, MASVS-L2 son derece hassas verileri işleyen uygulamalar için uygulanmalıdır. MASVS-R, istemci tarafındaki tehditleri önlemek bir tasarım hedefi ise uygulanabilecek ek koruyucu kontrolleri kapsar. - -MASVS-L1'deki gereksinimleri karşılamak, en iyi güvenlik uygulamalarını izleyen ve yaygın güvenlik açıklarından etkilenmeyen güvenli bir uygulama ile sonuçlanır. MASVS-L2, mobil işletim sisteminin güvenlik kontrollerinin sağlam olduğunu ve son kullanıcının potansiyel bir düşman olarak görülmediğini varsayarak, daha karmaşık saldırılara karşı dirençli bir uygulama ile sonuçlanan SSL sabitleme gibi ek derinlemesine savunma kontrolleri ekler. MASVS-R'deki yazılım koruma gereksinimlerinin tamamını veya alt kümelerini karşılamak, son kullanıcının kötü niyetli olduğu ve/veya mobil işletim sisteminin tehlikeye düştüğü durumlarda belirli istemci tarafı tehditlerinin engellenmesine yardımcı olur. - -**I: Her uygulamada MASVS-L1 kontrollerinin uygulanmasını önermemize rağmen, bir kontrolün uygulanması veya uygulanmaması, sonuçta iş sahipleriyle alınan/iletilen risk temelli bir karar olmalıdır.** - -**II: MASVS-R'de listelenen ve OWASP Mobil Güvenlik Test Kılavuzunda açıklanan yazılım koruma kontrollerinin nihayetinde atlanabileceğini ve asla güvenlik kontrollerinin yerine kullanılmaması gerektiğini unutmayın. Bunun yerine, MASVS-L1 veya MASVS-L2'deki MASVS gereksinimlerini de karşılayan uygulamalara ek olarak belirli tehditlere yönelik, koruyucu denetimler eklemeyi amaçlamaktadır.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### Doküman Yapısı - -MASVS'nin ilk bölümü, güvenlik modelinin ve mevcut doğrulama seviyelerinin açıklamasını ve ardından standardın pratikte nasıl kullanılacağına dair tavsiyeleri içerir. Ayrıntılı güvenlik gereksinimleri, doğrulama seviyelerinin eşleştirilmesiyle birlikte ikinci bölümde listelenmiştir. Gereksinimler, teknik hedef/kapsama göre sekiz kategoriye (V1'den V8'e) gruplandırılmıştır. Aşağıdaki isimlendirme MASVS ve MSTG'de kullanılmaktadır: - -- *Gereksinim kategorisi:* MASVS-Vx, ör. MASVS-V2: Veri Depolama ve Gizlilik -- *Gereksinim:* MASVS-Vx.y, ör. MASVS-V2.2: "Uygulama günlüklerine hassas veri yazılmaz." - -### Doğrulama Düzeylerinin Detayları - -#### MASVS-L1: Standard Güvenlik - -MASVS-L1'e ulaşan bir mobil uygulama, mobil uygulama güvenliği için en iyi güvenlik pratiklerine bağlıdır. Kod kalitesi, hassas verilerin işlenmesi ve mobil ortamla etkileşim açısından temel gereksinimleri karşılar. Güvenlik kontrollerini doğrulamak için bir test süreci yürürlükte olmalıdır. Bu seviye tüm mobil uygulamalar için uygundur. - -#### MASVS-L2: Derinlemesine Savunma - -MASVS-L2, standart gereksinimlerin ötesinde gelişmiş güvenlik kontrolleri sunar. MASVS-L2'yi gerçekleştirmek için bir tehdit modeli mevcut olmalı ve güvenlik, uygulamanın mimarisinin ve tasarımının ayrılmaz bir parçası olmalıdır. Tehdit modeline göre, doğru MASVS-L2 kontrolleri seçilmeli ve başarıyla uygulanmalıdır. Bu seviye, mobil bankacılık uygulamaları gibi oldukça hassas verileri işleyen uygulamalar için uygundur. - -#### MASVS-R: Tersine Mühendislik ve Kurcalamaya Karşı Dayanıklılık - -Bu gereksinimlerde uygulama son teknoloji güvenliğe sahiptir ve ayrıca hassas kod veya verileri çıkarmak için kurcalama, modlama veya tersine mühendislik gibi belirli, açıkça tanımlanmış istemci tarafı saldırılarına karşı dayanıklıdır. Böyle bir uygulama ya donanım güvenlik özelliklerinden ya da yeterince güçlü ve doğrulanabilir yazılım koruma tekniklerinden yararlanır. MASVS-R, son derece hassas verileri işleyen ve fikri mülkiyeti korumayı veya kurcalamaya karşı koruma gerektiren uygulamalar için uygundur. - -### Önerilen Kullanım - -Uygulamalar, önceki risk değerlendirmesine ve gerekli genel güvenlik düzeyine dayalı olarak MASVS L1 veya L2'ye göre doğrulanabilir. L1, tüm mobil uygulamalar için geçerliyken, L2 genellikle daha hassas verileri ve / veya işlevselliği işleyen uygulamalar için önerilir. MASVS-R (veya bir kısmı), uygun güvenlik doğrulamasına *ek olarak* hassas verilerin yeniden paketlenmesi veya çıkarılması gibi belirli tehditlere karşı dayanıklılığı doğrulamak için uygulanabilir. - -Özet olarak, aşağıdaki doğrulama türleri kullanılabilir: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -Farklı kombinasyonlar, farklı güvenlik ve esneklik derecelerini yansıtır. Amaç esnekliğe izin vermektir: Örneğin, bir mobil oyun, kullanılabilirlik nedenleriyle 2 faktörlü kimlik doğrulama gibi MASVS-L2 güvenlik kontrolleri eklemeye ihtiyaç duymayabilir, ancak istemci tarafında kurcalamayı önleme konusunda güçlü bir iş gereksinimine sahip olabilir. - -#### Hangi Doğrulama Türü Seçilmeli - -MASVS L2 gereksinimlerinin uygulanması güvenliği artırırken aynı zamanda geliştirme maliyetini artırır ve son kullanıcı deneyimini potansiyel olarak kötüleştirir. Genel olarak L2, risk ve maliyet açısından anlamlı olduğunda (yani, gizlilik veya bütünlükten ödün vermenin neden olduğu potansiyel kayıp, ek güvenlik kontrollerinin neden olduğu maliyetten daha yüksek olduğunda) uygulamalar için kullanılmalıdır. MASVS'yi uygulamadan önce ilk adım bir risk değerlendirmesi olmalıdır. - -##### Örnekler - -###### MASVS-L1 - -- Tüm mobil uygulamalarda uygulanabilir. MASVS-L1, geliştirme maliyeti ve kullanıcı deneyimi üzerinde makul bir etkiyle izlenebilecek en iyi güvenlik uygulamalarını listeler. Daha yüksek seviyelerden birine uygun olmayan herhangi bir uygulama için MASVS-L1'deki gereksinimleri uygulayın. - - - -###### MASVS-L2 - -- Sağlık Endüstrisi: Kimlik hırsızlığı, dolandırıcılık ödemeleri veya çeşitli dolandırıcılık planları için kullanılabilen kişisel olarak tanımlanabilir bilgileri depolayan mobil uygulamaların uygulaması önerilir. ABD sağlık hizmetleri sektörü için uyumluluk konuları arasında Sağlık Sigortası Taşınabilirlik ve Sorumluluk Yasası (HIPAA) Gizlilik, Güvenlik, İhlal Bildirim Kuralları ve Hasta Güvenliği Kuralı bulunmaktadır. - -- Finansal Endüstri: Kredi kartı numaraları, kişisel bilgiler gibi son derece hassas bilgilere erişim sağlayan veya kullanıcının para aktarmasına izin veren uygulamaların uygulaması önerilir. Bu uygulamalar, sahtekarlığı önlemek için ek güvenlik kontrollerini garanti eder. Finansal uygulamaların Payment Card Industry Data Security Standard (PCI DSS), Gramm Leech Bliley Yasası ve Sarbanes-Oxley Yasası (SOX) ile uyumluluğu sağlaması gerekir. - -###### MASVS L1+R - -- Fikri Mülkiyet (IP) korumasının bir iş hedefi olduğu mobil uygulamaların uygulaması önerilir. MASVS-R'de listelenen dayanıklılık kontrolleri, orijinal kaynak kodunu elde etmek ve kurcalama/kırılmayı engellemek için gereken çabayı artırmak için kullanılabilir. - -- Oyun Endüstrisi: Rekabetçi çevrimiçi oyunlar gibi modlama ve hile yapmayı engelleme ihtiyacı olan oyunların uygulaması önerilir. Hile, çevrimiçi oyunlarda önemli bir sorundur, çünkü çok sayıda hileci hoşnutsuz bir oyuncu tabanına yol açar ve sonuçta bir oyunun başarısız olmasına neden olabilir. MASVS-R, dolandırıcıların çabasını artırmak için temel kurcalamaya karşı önleyici kontroller sağlar. - -###### MASVS L2+R - -- Finansal Endüstri: Ele geçirilen cihazlarda kod enjeksiyonu ve enstrümantasyon gibi tekniklerin risk oluşturduğu, para transferleri yapılabilen çevrimiçi bankacılık uygulamalarının uygulaması önerilir. Bu durumda, MASVS-R kontrolleri, kurcalanmayı engellemek için kullanılabilir ve kötü amaçlı yazılım sahipleri için çıtayı yükseltir. - -- Tasarım gereği hassas verileri mobil cihazda depolaması gereken ve aynı zamanda çok çeşitli cihazları ve işletim sistemi sürümlerini desteklemesi gereken tüm mobil uygulamalarının uygulaması önerilir. Bu durumda dayanıklılık kontrolleri, hassas verileri çıkarmayı amaçlayan saldırganların çabalarını artırmak için kapsamlı bir savunma önlemi olarak kullanılabilir. - -- Uygulama içi satın alımları olan uygulamalar, ücretli içeriği korumak için ideal olarak sunucu tarafı ve MASVS-L2 kontrollerini kullanmalıdır. Ancak, sunucu tarafı korumasını kullanma olanağının olmadığı durumlar olabilir. Bu durumlarda, tersine mühendislik ve/veya kurcalama çabasını artırmak için MASVS-R kontrolleri ek olarak uygulanmalıdır. diff --git a/Document-tr/0x04-Assessment_and_Certification.md b/Document-tr/0x04-Assessment_and_Certification.md deleted file mode 100644 index 3740ff785..000000000 --- a/Document-tr/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,49 +0,0 @@ -# Değerlendirme ve Sertifikasyon - -## OWASP'ın MASVS Sertifikaları ve Güven Markaları Konusundaki Duruşu - -OWASP, satıcıdan bağımsız, kar amacı gütmeyen bir kuruluş olarak, herhangi bir satıcıyı, sağlayıcı veya yazılımı onaylamaz. - -Tüm bu tür güvence onayları, güven markaları veya sertifikaları OWASP tarafından resmi olarak incelenmemiş, tescil edilmemiş veya onaylanmamıştır, bu nedenle böyle bir görüşe dayanan bir kuruluşun (M)ASVS sertifikasyonu iddiasında bulunan herhangi bir üçüncü şahsa veya güven markasına duyulan güven konusunda dikkatli olması gerekir. - -Bu, resmi OWASP sertifikası talep etmedikleri sürece, kuruluşların bu tür güvence hizmetleri sunmasını engellememelidir. - -## Mobil Uygulamaları Onaylama Rehberi - -Bir mobil uygulamanın MASVS ile uyumluluğunu doğrulamanın önerilen yolu bir "açık kitap" incelemesi yapmaktır, yani test uzmanlarına uygulamanın mimarları ve geliştiricileri, proje dokümantasyonu, kaynak kodu ve her rol için en az bir kullanıcı hesabına erişim dahil olmak üzere uç noktalara kimlik doğrulaması ile erişim gibi temel kaynaklara erişim izni verilmelidir. - -MASVS'nin yalnızca (istemci tarafı) mobil uygulamanın güvenliğini ve uygulama ile uzak uç noktaları arasındaki ağ iletişimini, ayrıca kullanıcı kimlik doğrulaması ve oturum yönetimi ile ilgili birkaç temel ve genel gereksinimi kapsadığına dikkat etmek önemlidir. Yetkilendirme, kimlik doğrulama, kontrol doğrulama ve oturum yönetimi ile ilgili konularda sınırlı genel gereksinimler kümesi dışında, uygulama ile ilişkili uzak servisler (ör. Web servisler) için özel gereksinimler içermez. Ancak MASVS V1, uzak servislerin genel tehdit modeli tarafından kapsanması ve OWASP ASVS gibi uygun standartlara göre doğrulanması gerektiğini belirtir. - -Sertifikalandırma kuruluşu, herhangi bir rapora doğrulama kapsamını (özellikle bir anahtar bileşen kapsam dışındaysa), başarılı ve başarısız testler dahil olmak üzere doğrulama bulgularının bir özetini, başarısız testlerin nasıl çözüleceğine dair net göstergeler dahil etmelidir. Detaylı çalışma kağıtları, ekran görüntüleri ya da ekran videoları, bulguyu güvenilir ve tekrarlanabilir biçinde sömürebilecek betikler, vekil sunucu (proxy) kayıtları ve temizleme prosedürüne yönelik notlar gibi elektronik kayıtlar standart endüstri uygulaması olarak kabul edilir. Sadece bir aracı çalıştırmak ve bulguları raporlamak yeterli değildir; bu, sertifikalandırma düzeyindeki tüm konuların kapsamlı ve uygun bir şekilde test edildiğine dair yeterli kanıt sağlamaz. Anlaşmazlık durumunda, doğrulanan her gereksinimin gerçekten test edildiğini gösteren yeterli destekleyici kanıt olmalıdır. - - - -### OWASP Mobile Security Testing Guide (MSTG) Kullanma - -OWASP MSTG, mobil uygulamaların güvenliğini test etmeye yönelik bir kılavuzdur. MASVS'de listelenen gereksinimleri doğrulamak için teknik süreçleri açıklar. MSTG, her biri MASVS'deki bir gereksinimle eşleşen test senaryolarının bir listesini içerir. MASVS gereksinimleri üstten ve genel olmakla birlikte, MSTG, mobil işletim sistemine göre derinlemesine öneriler ve test prosedürleri sağlar. - -### Otomatize Güvenlik Test Araçlarının Rolü - -Mümkün olduğunda verimliliği artırmak için kaynak kod tarayıcılarının ve kara kutu (black-box) test araçlarının kullanılması teşvik edilmektedir. Bununla birlikte, MASVS doğrulamasını yalnızca otomatik araçları kullanarak tamamlamak mümkün değildir: Her mobil uygulama farklıdır ve uygulamada kullanılan belirli teknolojilerin ve çerçevelerin genel mimarisini, iş mantığını ve kullanılan spesifik teknolojilerin teknik tuzaklarını anlamak, uygulama güvenliğini doğrulamak için zorunlu bir gerekliliktir. - -## Diğer Kullanımlar - -### Ayrıntılı Güvenlik Mimarisi Rehberi olarak - -MASVS'nin en yaygın kullanımlarından biri, güvenlik mimarları için bir kaynak olarak kullanımıdır. İki ana güvenlik mimarisi çerçevesi, SABSA veya TOGAF, mobil uygulama güvenlik mimarisi incelemelerini tamamlamak için gerekli olan çok fazla bilgiden yoksundur. MASVS, güvenlik mimarlarının mobil uygulamalarda ortak olan sorunlar için daha iyi kontroller seçmesine izin vererek bu boşlukları doldurmak için kullanılabilir. - -### Kullanıma Hazır Güvenli Kodlama Kontrol Listelerinin Değiştirilmesi Olarak - -Birçok kuruluş, MASVS'nin iki düzeyinden birini seçerek veya MASVS'yi klonlayarak ve her uygulamanın risk düzeyi için gerekenleri etki alanına özgü bir şekilde değiştirerek fayda sağlayabilir. İzlenebilirlik korunduğu sürece bu tür klonlamaları teşvik ederiz, böylece bir uygulama 4.1 gereksinimini geçerse, bu, standart geliştikçe klonlanan kopyalar için de aynı anlama gelir. - -### Güvenlik Testi Metodolojilerinin Temeli Olarak - -İyi bir mobil uygulama güvenlik testi metodolojisi, MASVS'de listelenen tüm gereksinimleri kapsamalıdır. OWASP Mobile Security Testing Guide (MSTG) her doğrulama gereksinimi için kara kutu (black-box) ve beyaz kutu (white-box) test durumlarını açıklar. - -### Otomatik Birim ve Entegrasyon Testleri için Kılavuz Olarak - -MASVS, mimari gereksinimler dışında, yüksek düzeyde test edilebilir olacak şekilde tasarlanmıştır. MASVS gereksinimlerine dayalı otomatik birim, entegrasyon ve kabul testi, sürekli geliştirme yaşam döngüsüne entegre edilebilir. Bu yalnızca geliştirici güvenlik farkındalığını artırmakla kalmaz, aynı zamanda ortaya çıkan uygulamaların genel kalitesini iyileştirir ve devreye alım öncesi aşamada güvenlik testi sırasında bulguların miktarını azaltır. - -### Güvenli Geliştirme Eğitimi İçin - -MASVS, güvenli mobil uygulamaların özelliklerini tanımlamak için de kullanılabilir. Çoğu "güvenli kodlama" kursu, üstünkörü bir şekilde kodlama ipuçlarına değinerek basitçe etik bilgisayar korsanlığı kurslarıdır. Bu, geliştiricilere yardımcı olmaz. Bunun yerine, güvenli geliştirme kursları örneğin en sık karşılaşılan 10 kod güvenlik bulgusuna odaklanmak yerine MASVS'de belgelenen proaktif kontrollere güçlü bir odaklanma ile MASVS'yi kullanabilir. diff --git a/Document-tr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-tr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 4b1486a20..000000000 --- a/Document-tr/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: Mimari, Tasarım ve Tehdit Modelleme Gereksinimleri - -## Kontrol Hedefi - -Kusursuz bir dünyada, güvenlik, geliştirmenin tüm aşamalarında dikkate alınmalıdır. Gerçekte ise, güvenlik genellikle sadece SDLC'nin son aşamasında ele alınan bir konudur. MASVS, teknik kontrollerin yanı sıra, mobil uygulamanın mimarisini planlarken güvenliğin açıkça ele alınmasını, tüm bileşenlerin işlevsel ve güvenlik rollerinin bilinmesini sağlayan süreçlerin yürürlükte olmasını gerektirir. Çoğu mobil uygulama, uzak servislerin istemcisi olarak hareket ettiğinden, bu servislerin de uygun güvenlik standartlarının uygulandığından emin olunmalıdır - mobil uygulamayı tek başına test etmek yeterli değildir. - -"V1" kategorisi, uygulamanın mimarisi ve tasarımıyla ilgili gereksinimleri listeler. Bu nedenle, OWASP Mobile Testing Guide içerisindeki teknik test durumlarıyla eşleşmeyen tek kategori budur. Tehdit modellemesi, güvenli SDLC veya anahtar yönetimi gibi konuları kapsamak için MASVS kullanıcıları, ilgili OWASP projelerine ve/veya aşağıda bağlantılı olanlar gibi diğer standartlara başvurmalıdır. - -## Güvenlik Doğrulama Gereksinimleri - -MASVS-L1 ve MASVS-L2 gereksinimleri aşağıda listelenmiştir. - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | Tüm uygulama bileşenleri tanımlanır ve ihtiyaç duyulduğu bilinir. | x | x | -| **1.2** | MSTG-ARCH-2 | Güvenlik denetimleri yalnızca istemci tarafında değil, ilgili uzak uç noktalarda da zorlanır. | x | x | -| **1.3** | MSTG-ARCH-3 | Mobil uygulama ve tüm bağlı uzak hizmetler için yüksek seviyeli bir mimari tanımlanır ve bu mimaride güvenlik ele alınır. | x | x | -| **1.4** | MSTG-ARCH-4 | Mobil uygulama bağlamında hassas olduğu düşünülen veriler açıkça tanımlanır. | x | x | -| **1.5** | MSTG-ARCH-5 | Tüm uygulama bileşenleri, sağladıkları iş işlevleri ve/veya güvenlik işlevleri açısından tanımlanır. | | x | -| **1.6** | MSTG-ARCH-6 | Potansiyel tehditleri ve karşı önlemleri belirleyen mobil uygulama ve ilişkili uzak servisler için bir tehdit modeli oluşturuldu. | | x | -| **1.7** | MSTG-ARCH-7 | Tüm güvenlik kontrolleri merkezi bir entegrasyona sahiptir. | | x | -| **1.8** | MSTG-ARCH-8 | Şifreleme anahtarlarının (eğer varsa) nasıl yönetildiğine ve şifreleme anahtarlarının yaşam döngüsünün zorunlu kılınmasına ilişkin açık bir politika vardır. İdeal olarak, NIST SP 800-57 gibi bir temel yönetim standardını izleyin. | | x | -| **1.9** | MSTG-ARCH-9 | Mobil uygulamanın güncellemelerini zorunlu kılmak için bir mekanizma mevcuttur. | | x | -| **1.10** | MSTG-ARCH-10 | Güvenlik, yazılım geliştirme yaşam döngüsünün tüm bölümlerinde ele alınmaktadır. | | x | -| **1.11** | MSTG-ARCH-11 | Sorumlu bir bilgilendirme politikası mevcuttur ve etkin bir şekilde uygulanmaktadır. | | x | -| **1.12** | MSTG-ARCH-12 | Uygulama, gizlilik yasalarına ve düzenlemelerine uymalıdır. | x | x | - -## Referanslar - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-tr/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-tr/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index d835b3249..000000000 --- a/Document-tr/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: Veri Depolama ve Gizlilik Gereksinimleri - -## Kontrol Hedefi - -Kullanıcı kimlik bilgileri ve özel bilgiler gibi hassas verilerin korunması, mobil güvenliğin temel odak noktasıdır. İlk olarak, hassas veriler, IPC gibi işletim sistemi mekanizmaları tarafından uygunsuz bir şekilde kullanılırsa, aynı cihazda çalışan diğer uygulamalara istenmeden ifşa edilebilir. Ayrıca veriler istemeden bulut depolamaya, yedeklemelere veya klavye önbelleğine sızabilir. Ek olarak, mobil cihazlar diğer cihaz türlerine kıyasla daha kolay kaybolabilir veya çalınabilir, bu nedenle fiziksel erişim elde eden bir düşman daha olası bir senaryodur. Bu durumda, hassas verilerin alınmasını daha zor hale getirmek için ek korumalar uygulanabilir. - -MASVS uygulama merkezli olduğundan, MDM çözümleri tarafından zorunlu kılınan cihaz düzeyinde politikaları kapsamamaktadır. Veri güvenliğini daha da artırmak için bu tür politikaların kurumsal bağlamda kullanılmasını destekliyoruz. - -### Hassas Verilerin Tanımı - -MASVS bağlamındaki hassas veriler, hem kullanıcı kimlik bilgileriyle hem de belirli bağlamda hassas olduğu düşünülen diğer verilerle ilgilidir, örneğin: - -- Kimlik hırsızlığı için kötüye kullanılabilecek kişisel tanımlanabilir bilgiler (PII): Sosyal güvenlik numaraları, kredi kartı numaraları, banka hesap numaraları, sağlık bilgileri; -- Açığa çıkması durumunda itibarın zarar görmesine ve/veya finansal maliyetlere yol açabilecek son derece hassas veriler: Sözleşme bilgileri, gizlilik anlaşmalarının kapsadığı bilgiler, yönetim bilgileri; -- Yasa tarafından veya uygunluk nedenleriyle korunması gereken herhangi bir veri. - -## Güvenlik Doğrulama Gereksinimleri - -Veri ifşa sorunlarının büyük çoğunluğu basit kurallara uyarak önlenebilir. Bu bölümde listelenen kontrollerin çoğu tüm doğrulama seviyeleri için zorunludur. - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | Kişisel tanımlanabilir bilgiler (PII), kullanıcı kimlik bilgileri veya kriptografik anahtarlar gibi hassas verileri depolamak için sistem kimlik bilgileri depolama tesislerinin kullanılması gerekir. | x | x | -| **2.2** | MSTG-STORAGE-2 | Hassas veriler, uygulama alanı veya sistem kimlik depolama alanları dışındaki alanlarda saklanmamalıdır. | x | x | -| **2.3** | MSTG-STORAGE-3 | Uygulama günlüklerine hassas veriler yazılmaz. | x | x | -| **2.4** | MSTG-STORAGE-4 | Mimarinin gerekli bir parçası olmadığı sürece hiçbir hassas veri üçüncü taraflarla paylaşılmaz. | x | x | -| **2.5** | MSTG-STORAGE-5 | Hassas verileri işleyen metin girişlerinde klavye önbellek özelliği devre dışı bırakılır. | x | x | -| **2.6** | MSTG-STORAGE-6 | IPC mekanizmaları aracılığıyla hiçbir hassas veri açığa çıkarılmaz. | x | x | -| **2.7** | MSTG-STORAGE-7 | Parola veya pin gibi hassas veriler, kullanıcı arabirimi aracılığıyla açığa çıkarılmaz. | x | x | -| **2.8** | MSTG-STORAGE-8 | Mobil işletim sistemi tarafından oluşturulan yedeklemelere hiçbir hassas veri dahil edilmez. | | x | -| **2.9** | MSTG-STORAGE-9 | Uygulama, arka plana taşındığında hassas verileri görünümlerden kaldırır. | | x | -| **2.10** | MSTG-STORAGE-10 | Uygulama hassas verileri hafızada gerekenden daha uzun süre tutmaz ve kullanımdan sonra hafıza açıkça temizlenir. | | x | -| **2.11** | MSTG-STORAGE-11 | Uygulama, kullanıcının bir cihaz parolası belirlemesini istemek gibi minimum bir cihaz erişim güvenliği politikası uygular. | | x | -| **2.12** | MSTG-STORAGE-12 | Uygulama, kullanıcıyı, işlenen kişisel olarak tanımlanabilir bilgi türleri ve ayrıca kullanıcının uygulamayı kullanırken izlemesi gereken en iyi güvenlik uygulamaları hakkında eğitir. | | x | -| **2.13** | MSTG-STORAGE-13 | Mobil cihazda yerel olarak hiçbir hassas veri saklanmamalıdır. Bunun yerine, veriler gerektiğinde uzak bir uç noktadan alınmalı ve yalnızca bellekte tutulmalıdır. | | x | -| **2.14** | MSTG-STORAGE-14 | Hassas verilerin hala yerel olarak depolanması gerekiyorsa, donanım destekli depolamadan türetilen ve kimlik doğrulama gerektiren bir anahtar kullanılarak şifrelenmelidir. | | x | -| **2.15** | MSTG-STORAGE-15 | Uygulamanın yerel depolaması, aşırı sayıda başarısız kimlik doğrulama girişiminden sonra silinmelidir. | | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-tr/0x08-V3-Cryptography_Verification_Requirements.md b/Document-tr/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index f865d95fd..000000000 --- a/Document-tr/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Kriptografi Gereksinimleri - -## Kontrol Hedefi - -Kriptografi, bir mobil cihazda depolanan verilerin korunması söz konusu olduğunda önemli bir bileşendir. Aynı zamanda, özellikle standart kurallara uyulmadığında, işlerin korkunç şekilde ters gidebileceği bir kategoridir. Bu bölümdeki kontrollerin amacı, doğrulanmış uygulamanın, aşağıdakiler de dahil olmak üzere sektördeki en iyi uygulamalara göre kriptografi kullanmasını sağlamaktır: - -- Kanıtlanmış kriptografik kütüphanelerin kullanımı; -- Kriptografik temellerin doğru seçimi ve konfigürasyonu; -- Rasgeleliğin gerekli olduğu her yerde uygun bir rasgele sayı üreteci. - -## Güvenlik Doğrulama Gereksinimleri - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | Uygulama, tek şifreleme yöntemi olarak sabit kodlanmış anahtarlarla simetrik şifrelemeye dayanmaz. | x | x | -| **3.2** | MSTG-CRYPTO-2 | Uygulama, kriptografik temellerin, kanıtlanmış uygulamalarını kullanır. | x | x | -| **3.3** | MSTG-CRYPTO-3 | Uygulama, sektördeki en iyi uygulamalara uyan parametrelerle yapılandırılmış, belirli kullanım durumuna uygun kriptografik temel öğeleri kullanır. | x | x | -| **3.4** | MSTG-CRYPTO-4 | Uygulama, güvenlik nedeniyle yaygın olarak kullanımdan kaldırılan kriptografik protokolleri veya algoritmaları kullanmaz. | x | x | -| **3.5** | MSTG-CRYPTO-5 | Uygulama, aynı şifreleme anahtarını birden çok amaç için yeniden kullanmaz. | x | x | -| **3.6** | MSTG-CRYPTO-6 | Tüm rasgele değerler, yeterince güvenli bir rasgele sayı üreteci kullanılarak üretilir. | x | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-tr/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-tr/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index a5410a4e7..000000000 --- a/Document-tr/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Kimlik Doğrulama ve Oturum Yönetimi Gereksinimleri - -## Kontrol Hedefi - -Çoğu durumda, bir uzak serviste oturum açan kullanıcılar, genel mobil uygulama mimarisinin ayrılmaz bir parçasıdır. Mantığın çoğu uç noktada gerçekleşse de MASVS, kullanıcı hesaplarının ve oturumlarının nasıl yönetileceğine ilişkin bazı temel gereksinimleri tanımlar. - -## Güvenlik Doğrulama Gereksinimleri - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | Uygulama, kullanıcılara uzak bir servise erişim sağlıyorsa, uzak uç noktada kullanıcı adı/parola kimlik doğrulaması gibi bir tür kimlik doğrulama gerçekleştirilir. | x | x | -| **4.2** | MSTG-AUTH-2 | Durum bilgisi olan (stateful) oturum yönetimi kullanılıyorsa, uzak uç nokta, kullanıcının kimlik bilgilerini göndermeden istemci isteklerinin kimliğini doğrulamak için rastgele oluşturulmuş oturum tanımlayıcılarını kullanır. | x | x | -| **4.3** | MSTG-AUTH-3 | Durum bilgisi olmayan (stateless) token tabanlı kimlik doğrulama kullanılıyorsa, sunucu güvenli bir algoritma kullanılarak imzalanmış bir token sağlar. | x | x | -| **4.4** | MSTG-AUTH-4 | Uzak uç nokta, kullanıcı oturumu kapattığında mevcut oturumu sonlandırır. | x | x | -| **4.5** | MSTG-AUTH-5 | Uzak uç noktada bir parola politikası vardır ve uzak uç noktada uygulanır. | x | x | -| **4.6** | MSTG-AUTH-6 | Uzak uç nokta, kimlik bilgilerinin aşırı sayıda gönderilmesine karşı koruma sağlayan bir mekanizma uygular. | x | x | -| **4.7** | MSTG-AUTH-7 | Oturumlar, önceden tanımlanmış bir hareketsiz kalma süresi ve erişim tokenı süresi dolduktan sonra uzak uç noktada geçersiz kılınır. | x | x | -| **4.8** | MSTG-AUTH-8 | Eğer biyometrik kimlik doğrulama varsa, olaya bağlı değildir (yani, yalnızca "true" veya "false" döndüren bir API). Bunun yerine, keychain/keystore kilidini açmaya dayanır. | | x | -| **4.9** | MSTG-AUTH-9 | Uzak uç noktada ikinci bir kimlik doğrulama faktörü vardır ve 2FA gereksinimi tutarlı bir şekilde uygulanır. | | x | -| **4.10** | MSTG-AUTH-10 | Hassas işlemler, aşamalı kimlik doğrulaması gerektirir. | | x | -| **4.11** | MSTG-AUTH-11 | Uygulama, kullanıcıyı hesabıyla ilgili tüm hassas etkinlikler konusunda bilgilendirir. Kullanıcılar, cihazların listesini görüntüleyebilir, bağlamsal bilgileri (IP adresi, konum vb.) görüntüleyebilir ve belirli cihazları engelleyebilir. | | x | -| **4.12** | MSTG-AUTH-12 | Yetkilendirme modelleri uzak uç noktada tanımlanır ve uygulanır. | x | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-tr/0x10-V5-Network_communication_requirements.md b/Document-tr/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 05ff64b5c..000000000 --- a/Document-tr/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Ağ İletişim Gereksinimleri - -## Kontrol Hedefi - -Bu bölümde listelenen kontrollerin amacı, mobil uygulama ile uzak servis uç noktaları arasında aktarılan bilgilerin gizliliğini ve bütünlüğünü sağlamaktır. En azından bir mobil uygulama, uygun ayarlarla TLS protokolünü kullanarak ağ iletişimi için güvenli, şifreli bir kanal kurmalıdır. Seviye 2, SSL sabitleme gibi ek derinlemesine savunma önlemlerini listeler. - -## Güvenlik Doğrulama Gereksinimleri - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Veriler ağda TLS kullanılarak şifrelenir. Güvenli kanal, uygulama boyunca tutarlı bir şekilde kullanılır. | x | x | -| **5.2** | MSTG-NETWORK-2 | TLS ayarları, mevcut en iyi uygulamalarla uyumludur veya mobil işletim sistemi önerilen standartları desteklemiyorsa mümkün olduğunca yakındır. | x | x | -| **5.3** | MSTG-NETWORK-3 | Uygulama, güvenli kanal kurulduğunda uzak uç noktanın X.509 sertifikasını doğrular. Yalnızca güvenilir bir CA tarafından imzalanmış sertifikalar kabul edilir. | x | x | -| **5.4** | MSTG-NETWORK-4 | Uygulama ya kendi sertifika deposunu kullanır ya da uç nokta sertifikasını veya genel anahtarı sabitler ve ardından güvenilir bir CA tarafından imzalanmış olsa bile farklı bir sertifika veya anahtar sunan uç noktalarla bağlantı kurmaz. | | x | -| **5.5** | MSTG-NETWORK-5 | Uygulama, kayıtlar ve hesap kurtarma gibi kritik işlemler için tek bir güvenli olmayan iletişim kanalına (e-posta veya SMS) güvenmez. | | x | -| **5.6** | MSTG-NETWORK-6 | Uygulama yalnızca güncel bağlantı ve güvenlik kütüphanelerine bağlıdır. | | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-tr/0x11-V6-Interaction_with_the_environment.md b/Document-tr/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 4e6044a31..000000000 --- a/Document-tr/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Platform Etkileşim Gereksinimleri - -## Kontrol Hedefi - -Bu gruptaki kontroller, uygulamanın platform API'lerini ve standart bileşenleri güvenli bir şekilde kullanmasını sağlar. Ek olarak, kontroller uygulamalar arasındaki iletişimi (IPC) kapsar. - -## Güvenlik Doğrulama Gereksinimleri - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | Uygulama, yalnızca gerekli olan minimum izin grubunu ister. | x | x | -| **6.2** | MSTG-PLATFORM-2 | Harici kaynaklardan ve kullanıcıdan gelen tüm girdiler doğrulanır ve gerekirse sterilize edilir. Bu, kullanıcı arayüzü aracılığıyla alınan verileri, amaçlar, özel URL'ler ve ağ kaynakları gibi IPC mekanizmalarını içerir. | x | x | -| **6.3** | MSTG-PLATFORM-3 | Bu mekanizmalar uygun şekilde korunmadıkça, uygulama özel URL şemaları aracılığıyla hassas işlevleri dışa aktarmaz. | x | x | -| **6.4** | MSTG-PLATFORM-4 | Uygulama, bu mekanizmalar uygun şekilde korunmadıkça, IPC aracılığıyla hassas işlevleri dışa aktarmaz. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript, açıkça gerekmedikçe webview yapılarında devre dışı bırakılır. | x | x | -| **6.6** | MSTG-PLATFORM-6 | Webview yapıları, yalnızca gereken minimum protokol işleyici kümesine izin verecek şekilde yapılandırılır (ideal olarak yalnızca https desteklenir). File, tel ve app-id gibi potansiyel olarak tehlikeli işleyiciler devre dışı bırakılır. | x | x | -| **6.7** | MSTG-PLATFORM-7 | Uygulamanın native metodları bir webview yapısına maruz bırakılırsa, webview yapısının yalnızca uygulama paketinde bulunan JavaScript'i oluşturduğunu doğrulayın. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Nesne seriden çıkarma işlemi varsa güvenli serileştirme API'leri uygulanır. | x | x | -| **6.9** | MSTG-PLATFORM-9 | Uygulama, screen overlay saldırılarına karşı kendini korur. (Yalnızca Android) | | x | -| **6.10** | MSTG-PLATFORM-10 | WebView yok edilmeden önce WebView önbelleği, deposu ve yüklenen kaynaklar (JavaScript, vb.) temizlenir. | | x | -| **6.11** | MSTG-PLATFORM-11 | Hassas veriler girildiğinde uygulamanın özel üçüncü taraf klavyelerin kullanımını engellediğini doğrulayın (yalnızca iOS). | | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-tr/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-tr/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index a2074ec8e..000000000 --- a/Document-tr/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Kod Kalitesi ve Derleme Ayar Gereksinimleri - -## Kontrol Hedefi - -Bu kontrolün amacı, uygulamanın geliştirilmesinde temel güvenlik kodlama uygulamalarının takip edilmesini ve derleyici tarafından sunulan "ücretsiz" güvenlik özelliklerinin etkinleştirilmesini sağlamaktır. - -## Güvenlik Doğrulama Gereksinimleri - -| # | MSTG-ID | Açıklama | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | Uygulama, özel anahtarın uygun şekilde korunduğu geçerli bir sertifika ile imzalanır ve sağlanır. | x | x | -| **7.2** | MSTG-CODE-2 | Uygulama, yayına uygun ayarlarla (ör. hata ayıklanamaz) yayın modunda oluşturulmuştur. | x | x | -| **7.3** | MSTG-CODE-3 | Hata ayıklama sembolleri native binary dosyalardan kaldırıldı. | x | x | -| **7.4** | MSTG-CODE-4 | Hata ayıklama kodu ve geliştirici yardım kodu (ör. test kodu, arka kapılar, gizli ayarlar) kaldırıldı. Uygulama, ayrıntılı hataları veya hata ayıklama mesajlarını günlüğe kaydetmez. | x | x | -| **7.5** | MSTG-CODE-5 | Kitaplıklar ve çerçeveler gibi mobil uygulama tarafından kullanılan tüm üçüncü taraf bileşenleri tanımlanır ve bilinen güvenlik açıkları açısından kontrol edilir. | x | x | -| **7.6** | MSTG-CODE-6 | Uygulama, olası hataları yakalar ve işler. | x | x | -| **7.7** | MSTG-CODE-7 | Güvenlik kontrollerinde hata işleme mantığı, varsayılan olarak erişimi reddeder. | x | x | -| **7.8** | MSTG-CODE-8 | Yönetilmeyen kodda bellek tahsis edilir, serbest bırakılır ve güvenli bir şekilde kullanılır. | x | x | -| **7.9** | MSTG-CODE-9 | Bayt kodu küçültme, yığın koruması, PIE desteği ve otomatik referans sayımı gibi araç zinciri tarafından sunulan ücretsiz güvenlik özellikleri etkinleştirilir. | x | x | - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-tr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-tr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 6b5405c37..000000000 --- a/Document-tr/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,72 +0,0 @@ -# V8: Dayanıklılık Gereksinimleri - -## Kontrol Hedefi - -Bu bölüm, hassas verileri veya işlevleri işleyen veya bunlara erişim sağlayan uygulamalar için önerilen kapsamlı savunma önlemlerini kapsar. Bu denetimlerin herhangi birinin olmaması bir güvenlik açığına neden olmaz - bunun yerine, uygulamanın tersine mühendislik ve belirli istemci tarafı saldırılarına karşı direncini artırmayı amaçlar. - -Bu bölümdeki kontroller, uygulamada yetkisiz kurcalamanın ve/veya kodun tersine mühendisliğinin neden olduğu risklerin değerlendirilmesine dayalı olarak gerektiği gibi uygulanmalıdır. İş risklerinin yanı sıra ilgili teknik tehditlerin bir listesi için "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" (aşağıdaki referanslara bakın) OWASP belgesine başvurmanızı öneririz. - -Aşağıdaki listedeki kontrollerden herhangi birinin etkili olması için, uygulamanın en azından MASVS-L1'in tamamını (yani, sağlam güvenlik kontrolleri mevcut olmalıdır) ve V8'deki tüm düşük numaralı gereksinimleri karşılaması gerekir. Örneğin, "anlamayı engelleme" altında listelenen gizleme kontrolleri "dinamik analiz ve kurcalamayı engelleme" ve "cihaz bağlama" ile birleştirilmelidir. - -**Yazılım korumalarının asla güvenlik kontrollerinin yerine kullanılmaması gerektiğini unutmayın. MASVR-R'de listelenen kontroller, MASVS güvenlik gereksinimlerini de karşılayan uygulamalara tehdide özgü, ek koruyucu kontroller eklemeyi amaçlamaktadır.** - -Aşağıdaki hususlar geçerlidir: - -1. Savunulması gereken istemci tarafı tehditlerini açıkça ortaya koyan bir tehdit modeli tanımlanmalıdır. Ek olarak, planın sağlaması amaçlanan koruma derecesi belirtilmelidir. Örneğin, belirtilen bir hedef, uygulamayı önemli ölçüde manuel tersine mühendislik çabasına yatırım yapmaya zorlamak isteyen hedeflenen kötü amaçlı yazılım yazarlarını zorlamak olabilir. - -2. Tehdit modeli güvenilir ve ilgili olmalıdır. Örneğin, bir beyaz kutu uygulamasında bir şifreleme anahtarının gizlenmesi, bir saldırgan beyaz kutuyu bir bütün olarak basitçe kodla kaldırabiliyorsa gereksiz olabilir. - -3. Korumanın etkinliği her zaman, kullanılan belirli kurcalamaya karşı koruma ve gizleme türlerini test etme konusunda deneyimli bir insan uzman tarafından doğrulanmalıdır (Mobile Security Testing Guide içerisindeki "tersine mühendislik" ve "yazılım korumalarını değerlendirme" bölümlerine de bakın). - - - -### Dinamik Analizi ve Kurcalamayı Engelleme - -| # | MSTG-ID | Açıklama | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | Uygulama, kullanıcıyı uyararak veya uygulamayı sonlandırarak root veya jailbreak yapılmış bir cihazın varlığını algılar ve yanıt verir. | x | -| **8.2** | MSTG-RESILIENCE-2 | Uygulama, hata ayıklamayı önler ve/veya eklenen bir hata ayıklayıcıyı algılar ve yanıt verir. Mevcut tüm hata ayıklama protokolleri kapsanmalıdır. | x | -| **8.3** | MSTG-RESILIENCE-3 | Uygulama, kendi sanal alanı içindeki yürütülebilir dosyalar ve kritik verilerle kurcalamayı algılar ve bunlara yanıt verir. | x | -| **8.4** | MSTG-RESILIENCE-4 | Uygulama, cihazda yaygın olarak kullanılan tersine mühendislik araçlarının ve çerçevelerinin varlığını algılar ve yanıt verir. | x | -| **8.5** | MSTG-RESILIENCE-5 | Uygulama, bir emülatörde çalıştırılmakta olduğunu algılar ve yanıt verir. | x | -| **8.6** | MSTG-RESILIENCE-6 | Uygulama, kodu ve verileri kendi bellek alanında kurcalamayı algılar ve yanıt verir. | x | -| **8.7** | MSTG-RESILIENCE-7 | Uygulama, her savunma kategorisinde (8.1 ila 8.6) birden fazla mekanizma uygular. Dayanıklılığın, kullanılan mekanizmaların özgünlüğünün miktarı ve çeşitliliği ile ölçeklendiğini unutmayın. | x | -| **8.8** | MSTG-RESILIENCE-8 | Algılama mekanizmaları, gecikmeli ve gizli yanıtlar dahil olmak üzere farklı türdeki yanıtları tetikler. | x | -| **8.9** | MSTG-RESILIENCE-9 | Gizleme (obfuscation), programatik savunmalara uygulanır ve bu da dinamik analiz yoluyla gizliliğin kaldırılmasını engeller. | x | - -### Cihaz Bağlama (Device Binding) - -| # | MSTG-ID | Açıklama | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | Uygulama, cihaza özgü birden çok özellikten türetilen bir cihaz parmak izi kullanarak bir 'cihaz bağlama' işlevi uygular. | x | - - - -### Anlamayı Engelleme - -| # | MSTG-ID | Açıklama | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | Uygulamaya ait tüm yürütülebilir dosyalar ve kitaplıklar ya dosya düzeyinde şifrelenir ve/veya yürütülebilir dosyaların içindeki önemli kod ve veri bölümleri şifrelenir veya paketlenir. Statik analiz, önemli kodu veya verileri ortaya çıkarmamalıdır. | x | -| **8.12** | MSTG-RESILIENCE-12 | Gizlemenin amacı hassas hesaplamaları korumaksa, şu anda yayınlanmış araştırmalar dikkate alınarak hem belirli görev için uygun hem de manuel ve otomatik gizleme yöntemlerine karşı dayanıklı olan bir gizleme şeması kullanılır. Gizleme planının etkinliği manuel test yoluyla doğrulanmalıdır. Donanım tabanlı yalıtım özelliklerinin, mümkün olduğunda gizleme yerine tercih edildiğini unutmayın. | x | - -### Dinlemeyi Engelleme - -| # | MSTG-ID | Açıklama | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | Derinlemesine bir savunma olarak, iletişim kuran tarafların sağlam bir şekilde sağlamlaştırılmasının yanı sıra, gizli dinlemeyi daha fazla engellemek için uygulama düzeyinde veri yükü şifrelemesi uygulanabilir. | x | - - - -## Referanslar - -OWASP Mobile Security Testing Guide, bu bölümde listelenen gereksinimleri doğrulamak için ayrıntılı talimatlar sağlar. - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -Daha fazla bilgi için ayrıca bakınız: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-tr/0x90-Appendix-A_Glossary.md b/Document-tr/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 2f42293c8..000000000 --- a/Document-tr/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Ek A: Sözlük - -- **Address Space Layout Randomization (ASLR)** – Bellek bozulması hatalarını sömürmeyi daha zor hale getiren bir teknik. -- **Application Security** – Uygulama düzeyinde güvenlik, örneğin temeldeki işletim sistemine veya bağlı ağlara odaklanmak yerine Open Systems Interconnection Reference Model (OSI Modeli) uygulama katmanını oluşturan bileşenlerin analizine odaklanır. -- **Application Security Verification** – Bir uygulamanın OWASP MASVS'ye karşı teknik değerlendirmesi. -- **Application Security Verification Report** – Belirli bir uygulama için doğrulayıcı tarafından üretilen genel sonuçları ve destekleyici analizi belgeleyen bir rapor. -- **Authentication** – Bir uygulama kullanıcısının iddia edilen kimliğinin doğrulanması. -- **Automated Verification** – Sorunları bulmak için güvenlik açığı imzalarını kullanan otomatik araçların (dinamik analiz araçları, statik analiz araçları veya her ikisi de) kullanımı. -- **Black Box Testing** – Bir uygulamanın işlevselliğini, iç yapılarına veya çalışmalarına bakmadan inceleyen bir yazılım testi yöntemidir. -- **Component** – Diğer bileşenlerle iletişim kuran ilişkili disk ve ağ arabirimlerine sahip bağımsız bir kod birimi. -- **Cross-Site Scripting (XSS)** – İstemci tarafı komut dosyalarının içeriğe eklenmesine izin veren, genellikle web uygulamalarında bulunan bir güvenlik açığı. -- **Cryptographic Module** – Kriptografik algoritmaları uygulayan ve/veya kriptografik anahtarlar üreten donanım, yazılım ve/veya ürün yazılımı. -- **CWE** – CWE, topluluk tarafından geliştirilmiş, yaygın yazılım güvenliği zayıflıklarının bir listesidir. Ortak bir dil, yazılım güvenlik araçları için bir ölçü ve zayıflık tespiti, zafiyet etkilerini hafifletme ve önleme çabaları için bir temel olarak hizmet eder. -- **Dynamic Application Security Testing (DAST)** – DAST teknolojileri, çalışma durumundaki bir uygulamadaki güvenlik açığının göstergesi olan koşulları tespit etmek için tasarlanmıştır. -- **Design Verification** – Bir uygulamanın güvenlik mimarisinin teknik değerlendirmesi. -- **Dynamic Verification** – Bir uygulamanın yürütülmesi sırasında sorunları bulmak için güvenlik açığı imzaları kullanan otomatik araçların kullanılması. -- **Globally Unique Identifier (GUID)** – Yazılımda tanımlayıcı olarak kullanılan benzersiz bir referans numarası. -- **Hyper Text Transfer Protocol (HTTP)** – Dağıtılmış, işbirliğine dayalı, hiper ortam bilgi sistemleri için bir uygulama protokolü. World Wide Web için veri iletişiminin temelidir. -- **Hardcoded Keys** – Cihazın kendisinde saklanan şifreleme anahtarları. -- **IPC** – Süreçler Arası İletişim, IPC prosesleri faaliyetlerini koordine etmek için birbirleriyle ve çekirdekle iletişim kurar. -- **Input Validation** – Güvenilmeyen kullanıcı girdilerinin standartlaştırılması ve doğrulanması. -- **Java Bytecode** – Java bayt kodu, Java sanal makinesinin (JVM) talimat kümesidir. Her bir bayt kodu, parametreleri geçirmek için sıfır veya daha fazla bayt ile birlikte talimatı (işlem kodu) temsil eden bir veya bazı durumlarda iki bayttan oluşur. -- **Malicious Code** – Uygulama sahibinin haberi olmadan geliştirmesi sırasında uygulamaya eklenen ve uygulamanın amaçlanan güvenlik politikasını atlatan kod. Virüs veya solucan gibi kötü amaçlı yazılımlarla aynı şey değildir! -- **Malware** – Uygulama kullanıcısı veya yöneticisinin bilgisi olmadan çalışma süresi sırasında bir uygulamaya eklenen yürütülebilir kod. -- **Open Web Application Security Project (OWASP)** – Açık Web Uygulama Güvenliği Projesi (OWASP), uygulama yazılımının güvenliğini artırmaya odaklanmış dünya çapında ücretsiz ve açık bir topluluktur. Misyonumuz, kişilerin ve kuruluşların uygulama güvenlik riskleri hakkında bilinçli kararlar alabilmesi için uygulama güvenliğini "görünür" hale getirmektir. Bakınız: -- **Personally Identifiable Information (PII)** – PII, tek bir kişiyi tanımlamak, temasa geçmek veya yerini belirlemek ya da bağlam içinde bir kişiyi tanımlamak için tek başına veya diğer bilgilerle birlikte kullanılabilen bilgilerdir. -- **Position-Independent Executable (PIE)** – PIE, birincil bellekte herhangi bir yere yerleştirilen ve mutlak adresine bakılmaksızın düzgün şekilde çalışan bir makine kodu gövdesidir. -- **Public Key Infrastructure (PKI)** – PKI, genel anahtarları ilgili varlık kimlikleriyle bağlayan bir düzenlemedir. Bağlama, bir sertifika yetkilisi (CA) tarafından ve sertifika yetkilisi tarafından tescil ve sertifikaların verilmesi süreci aracılığıyla oluşturulur. -- **Static Application Security Testing (SAST)** – SAST, güvenlik açıklarının göstergesi olan kodlama ve tasarım koşulları için uygulama kaynak kodunu, bayt kodunu ve ikili dosyaları analiz etmek için tasarlanmış bir dizi teknolojidir. SAST çözümleri, bir uygulamayı çalışmayan bir durumda "içten dışa" analiz eder. -- **SDLC** – Yazılım geliştirme yaşam döngüsü. -- **Security Architecture** – Güvenlik kontrollerinin nerede ve nasıl kullanıldığını tanımlayan ve açıklayan ve ayrıca hem kullanıcı hem de uygulama verilerinin konumunu ve hassasiyetini tanımlayan ve açıklayan bir uygulamanın tasarımının bir özetidir. -- **Security Configuration** – Güvenlik kontrollerinin nasıl kullanıldığını etkileyen bir uygulamanın yapılandırması. -- **Security Control** – Bir güvenlik kontrolü (örneğin, bir erişim kontrol kontrolü) gerçekleştiren veya çağrıldığında bir güvenlik etkisine neden olan (örneğin bir denetim kaydı oluşturma) bir işlev veya bileşen. -- **SQL Injection (SQLi)** – Kötü amaçlı SQL ifadelerinin bir giriş noktasına eklendiği, veri odaklı uygulamalara saldırmak için kullanılan bir kod enjeksiyon tekniğidir. -- **SSO Authentication** – Tek Oturum Açma (SSO), kullanıcının kullandığı platform, teknoloji veya etki alanına bakılmaksızın, bir kullanıcı bir istemcide oturum açtığında ve ardından diğer istemcilerde otomatik olarak oturum açtığında gerçekleşir. Örneğin, google'da oturum açtığınızda otomatik olarak youtube, docs ve mail hizmetine giriş yaparsınız. -- **Threat Modeling** – Tehdit ajanlarını, güvenlik bölgelerini, güvenlik kontrollerini ve önemli teknik ve ticari varlıkları belirlemek için giderek artan şekilde iyileştirilmiş güvenlik mimarileri geliştirmekten oluşan bir teknik. -- **Transport Layer Security** – İnternet üzerinden iletişim güvenliği sağlayan kriptografik protokoller. -- **URI ve URL** – Bir URI, bir adı veya web kaynağını tanımlamak için kullanılan bir karakter dizisidir. URL genellikle bir kaynağa referans olarak kullanılır. -- **User Acceptance Testing (UAT)** – Geleneksel olarak, tüm yazılım testlerinin yayınlanmadan önce gerçekleştirildiği üretim ortamı gibi davranan bir test ortamı. -- **Verifier** – OWASP MASVS gereksinimlerine göre bir başvuruyu inceleyen kişi veya ekip. -- **Whitelist** – İzin verilen veri veya işlemlerin listesi, örneğin giriş doğrulaması gerçekleştirmesine izin verilen karakterlerin listesi. -- **X.509 Certificate** – X.509 sertifikası, genel anahtarın sertifikada bulunan kullanıcıya, bilgisayara veya hizmet kimliğine ait olduğunu doğrulamak için yaygın olarak kabul edilen uluslararası X.509 genel anahtar altyapısı (PKI) standardını kullanan dijital bir sertifikadır. diff --git a/Document-tr/0x91-Appendix-B_References.md b/Document-tr/0x91-Appendix-B_References.md deleted file mode 100644 index 09801bedd..000000000 --- a/Document-tr/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Ek B: Referanslar - -Aşağıdaki OWASP projeleri, bu standardın kullanıcıları/benimseyenler için büyük olasılıkla yararlı olacaktır: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Security Testing Guide - [https://owasp.org/www-project-mobile-security-testing-guide/](https://owasp.org/www-project-mobile-security-testing-guide/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -Benzer şekilde, aşağıdaki web siteleri bu standardın kullanıcıları/benimseyenler için büyük olasılıkla yararlıdır: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-tr/CHANGELOG.md b/Document-tr/CHANGELOG.md deleted file mode 100644 index 40fcd7f45..000000000 --- a/Document-tr/CHANGELOG.md +++ /dev/null @@ -1,94 +0,0 @@ -# Değişiklik günlüğü - -## V1.3 - 13 Mayıs 2021 - -Projemiz için önemli bir kilometre taşı olan yeni bir belge oluşturma hattının tanıtıldığını duyurmaktan gurur duyuyoruz. Derleme işlem hattı, Pandocker ve Github Eylemlerine dayanmaktadır. Bu, yeni sürümlerin oluşturulması için harcanan zamanı önemli ölçüde azaltır ve ayrıca OWASP MSTG'nin temeli olacak ve OWASP ASVS projesi için kullanıma sunulacaktır. - -### Değişiklikler - -- Hintçe, Farsça, Portekizce ve Brezilya Portekizcesi olmak üzere 4 çeviri eklendi -- Gereksinim eklemesi: MSTG-PLATFORM-11 - -### Özel teşekkür - -- Jeroen Willemsen, geçen yıl bu girişimi başlattığı için! -- Damien Clochard ve Dalibo, pipeline desteklemek ve profesyonelleştirmek için. -- Mükemmel çeviri çalışmaları için tüm Hintçe, Farsça, Portekizce ve Brezilya Portekizcesi ortak çalışanlarımız. - -## V1.2 - 7 Mart 2020 - Uluslararası Sürüm - -Aşağıdaki değişiklikler 1.2 sürümünün parçasıdır: - -- Mevcut MASVS'nin basitleştirilmiş Çince çevirisi. -- MASVS kitap kapağında başlık değişikliği. -- Mobile Top 10 ve CWE, MSTG'den kaldırıldı ve MASVS'deki mevcut referanslarla birleştirildi. - -## V1.2-RC - 5 Ekim 2019 - Ön sürüm (yalnızca İngilizce) - -Aşağıdaki değişiklikler ön sürüm 1.2'nin parçasıdır: - -- "Flagship" statüsüne yükseltildi. -- Gereksinim değişti: MSTG-STORAGE-1 "kullanılması gerekiyor". -- Veri korumaya odaklanılarak MSTG-STORAGE-13, MSTG-STORAGE-14 ve MSTG-STORAGE-15 gereksinimleri eklendi. -- Gereksinim MSTG-AUTH-11, bağlamsal bilgileri korumak için güncellenmiştir. -- Gereksinim MSTG-CODE-4, hata ayıklamadan daha fazlasını kapsayacak şekilde güncellenmiştir. -- WebView yapılarının daha güvenli kullanımı için gereksinim MSTG-PLATFORM-10 eklendi. -- Gereksinim MSTG-AUTH-12, geliştiricilere, özellikle çok kullanıcılı uygulamalar durumunda, yetkilendirmelerin uygulandığını hatırlatmak için eklendi. -- Bir risk değerlendirmesi verildiğinde MASVS'nin nasıl kullanılması gerektiğine dair biraz daha açıklama eklendi. -- Ücretli içerik hakkında biraz daha açıklama eklendi. -- Gereksinim MSTG-ARCH-11, L2 uygulamaları için sorumlu ifşa politikasını içerecek şekilde eklendi. -- Gereksinim MSTG-ARCH-12, uygulama geliştiricilerine ilgili uluslararası gizlilik yasalarına uyulması gerektiğini göstermek için eklendi. -- İngilizce sürümdeki tüm referanslar için tutarlı bir stil oluşturdu. -- Gereksinim MSTG-PLATFORM-11, üçüncü taraf klavyeler aracılığıyla casusluğa karşı koymak için eklendi. -- Gereksinim MSTG-MSTG-RESILIENCE-13, bir uygulamada gizli dinlemeyi engellemek için eklendi. - -## V1.1.4 - 4 Temmuz 2019 - Zirve sürümü - -Aşağıdaki değişiklikler 1.1.4 sürümünün bir parçasıdır: - -- Tüm markdown sorunları düzeltildi. -- Fransızca ve İspanyolca çevirilerinde güncellemeler. -- Değişiklik günlüğü Çince (ZHTW) ve Japoncaya çevrildi. -- Markdown söz diziminin ve URL'lerin erişilebilirliğinin otomatik olarak doğrulanması. -- Önerileri ve test durumlarını kolayca bulmak için MSTG'nin gelecekteki sürümüne dahil edilecek olan gereksinimlere kimlik kodları eklendi. -- Depo boyutu küçültüldü ve .gitignore eklendi. -- Davranış Kuralları ve Katkıda Bulunma kuralları eklendi. -- Pull-Request şablonu eklendi. -- Gitbook web sitesini barındırmak için kullanılan depo ile senkronizasyon güncellendi. -- Tüm çeviriler için XML / JSON / CSV oluşturmak için komut dosyaları güncellendi. -- Önsöz Çince'ye (ZHTW) çevrildi. - -## V1.1.3 - 9 Ocak 2019 - Küçük düzeltmeler - -- İspanyolca sürümde gereksinim 7.1'in çeviri sorunu düzeltildi. -- Teşekkürler bölümünde yeni çevirmen düzeni - -## V1.1.2 - 3 Ocak 2019 - Sponsorluk ve uluslararasılaştırma - -Aşağıdaki değişiklikler 1.1.2 sürümünün bir parçasıdır: - -- E-kitabın alıcıları için teşekkür notu eklendi. -- V4'te eksik kimlik doğrulama bağlantısı eklendi ve bozuk kimlik doğrulama bağlantısı güncellendi. -- İngilizce 4.7 ve 4.8'in değiştirilmesi düzeltildi. -- İlk uluslararası sürüm! - - İspanyolca çeviride düzeltmeler. Çeviri artık İngilizce (1.1.2) ile uyumludur. - - Rusça çeviride düzeltmeler. Çeviri artık İngilizce (1.1.2) ile uyumludur. - - Çince (ZHTW) Fransızca, Almanca ve Japonca'nın ilk sürümü eklendi! -- Çeviri kolaylığı için basitleştirilmiş belge. -- Otomatik sürümler için talimatlar eklendi. - -## V1.1.0 - 14 Temmuz 2018 - -Aşağıdaki değişiklikler 1.1 sürümünün bir parçasıdır: - -- Gereksinim 2.6 "Pano, hassas veriler içerebilecek metin alanlarında devre dışı bırakılır." kaldırıldı. -- Gereksinim 2.2 "Hassas veriler, uygulama alanı veya sistem kimlik depolama alanları dışındaki alanlarda saklanmamalıdır." eklendi. -- Gereksinim 2.1, "Sistem kimlik bilgileri depolama olanakları, PII, kullanıcı kimlik bilgileri veya kriptografik anahtarlar gibi hassas verileri depolamak için uygun şekilde kullanılır." olarak yeniden ifade edildi. - -## V1.0 12 - Ocak 2018 - -Aşağıdaki değişiklikler 1.0 sürümünün bir parçasıdır: - -- 8.12 ile aynı olan 8.9 silindi. -- 4.6 daha genel hale getirildi. -- Küçük düzeltmeler (yazım hataları vb.) diff --git a/Document-tr/GLOSSARY.md b/Document-tr/GLOSSARY.md deleted file mode 100644 index 0cc8be3e5..000000000 --- a/Document-tr/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Ek A: Sözlük - -## Address Space Layout Randomization (ASLR) - -Bellek bozulması hatalarını sömürmeyi daha zor hale getiren bir teknik. - -## Application Security - -Uygulama düzeyinde güvenlik, örneğin temeldeki işletim sistemine veya bağlı ağlara odaklanmak yerine Open Systems Interconnection Reference Model (OSI Modeli) uygulama katmanını oluşturan bileşenlerin analizine odaklanır. - -## Application Security Verification - -Bir uygulamanın OWASP MASVS'ye karşı teknik değerlendirmesi. - -## Application Security Verification Report - -Belirli bir uygulama için doğrulayıcı tarafından üretilen genel sonuçları ve destekleyici analizi belgeleyen bir rapor. - -## Authentication - -Bir uygulama kullanıcısının iddia edilen kimliğinin doğrulanması. - -## Automated Verification - -Sorunları bulmak için güvenlik açığı imzalarını kullanan otomatik araçların (dinamik analiz araçları, statik analiz araçları veya her ikisi de) kullanımı. - -## Black box testing - -Bir uygulamanın işlevselliğini, iç yapılarına veya çalışmalarına bakmadan inceleyen bir yazılım testi yöntemidir. Component – Diğer bileşenlerle iletişim kuran ilişkili disk ve ağ arabirimlerine sahip bağımsız bir kod birimi. - -## Component - -Diğer bileşenlerle iletişim kuran ilişkili disk ve ağ arabirimlerine sahip bağımsız bir kod birimi. - -## Cross-Site Scripting (XSS) - -İstemci tarafı komut dosyalarının içeriğe eklenmesine izin veren, genellikle web uygulamalarında bulunan bir güvenlik açığı. - -## Cryptographic module - -Kriptografik algoritmaları uygulayan ve/veya kriptografik anahtarlar üreten donanım, yazılım ve/veya ürün yazılımı. - -## CWE - -CWE, topluluk tarafından geliştirilmiş, yaygın yazılım güvenliği zayıflıklarının bir listesidir. Ortak bir dil, yazılım güvenlik araçları için bir ölçü ve zayıflık tespiti, zafiyet etkilerini hafifletme ve önleme çabaları için bir temel olarak hizmet eder. - -## DAST - -DAST teknolojileri, çalışma durumundaki bir uygulamadaki güvenlik açığının göstergesi olan koşulları tespit etmek için tasarlanmıştır. - -## Design Verification - -Bir uygulamanın güvenlik mimarisinin teknik değerlendirmesi. - -## Dynamic Verification - -Bir uygulamanın yürütülmesi sırasında sorunları bulmak için güvenlik açığı imzaları kullanan otomatik araçların kullanılması. - -## Globally Unique Identifier(GUID) - -Yazılımda tanımlayıcı olarak kullanılan benzersiz bir referans numarası. - -## Hyper Text Transfer Protocol(HTTP) - -Dağıtılmış, işbirliğine dayalı, hiper ortam bilgi sistemleri için bir uygulama protokolü. World Wide Web için veri iletişiminin temelidir. - -## Hardcoded keys - -Cihazın kendisinde saklanan şifreleme anahtarları. - -## IPC - -Süreçler Arası İletişim, IPC prosesleri faaliyetlerini koordine etmek için birbirleriyle ve çekirdekle iletişim kurar. - -## Input Validation - -Güvenilmeyen kullanıcı girdilerinin standartlaştırılması ve doğrulanması. - -## JAVA Bytecode - -Java bayt kodu, Java sanal makinesinin (JVM) talimat kümesidir. Her bir bayt kodu, parametreleri geçirmek için sıfır veya daha fazla bayt ile birlikte talimatı (işlem kodu) temsil eden bir veya bazı durumlarda iki bayttan oluşur. - -## Malicious Code - -Uygulama sahibinin haberi olmadan geliştirmesi sırasında uygulamaya eklenen ve uygulamanın amaçlanan güvenlik politikasını atlatan kod. Virüs veya solucan gibi kötü amaçlı yazılımlarla aynı şey değildir! - -## Malware - -Uygulama kullanıcısı veya yöneticisinin bilgisi olmadan çalışma süresi sırasında bir uygulamaya eklenen yürütülebilir kod. - -## Open Web Application Security Project (OWASP) - -Açık Web Uygulama Güvenliği Projesi (OWASP), uygulama yazılımının güvenliğini artırmaya odaklanmış dünya çapında ücretsiz ve açık bir topluluktur. Misyonumuz, kişilerin ve kuruluşların uygulama güvenlik riskleri hakkında bilinçli kararlar alabilmesi için uygulama güvenliğini "görünür" hale getirmektir. Bakınız: - -## Personally Identifiable Information (PII) - -PII, tek bir kişiyi tanımlamak, temasa geçmek veya yerini belirlemek ya da bağlam içinde bir kişiyi tanımlamak için tek başına veya diğer bilgilerle birlikte kullanılabilen bilgilerdir. - -## PIE - -PIE, birincil bellekte herhangi bir yere yerleştirilen ve mutlak adresine bakılmaksızın düzgün şekilde çalışan bir makine kodu gövdesidir. - -## PKI - -PKI, genel anahtarları ilgili varlık kimlikleriyle bağlayan bir düzenlemedir. Bağlama, bir sertifika yetkilisi (CA) tarafından ve sertifika yetkilisi tarafından tescil ve sertifikaların verilmesi süreci aracılığıyla oluşturulur. - -## SAST - -SAST, güvenlik açıklarının göstergesi olan kodlama ve tasarım koşulları için uygulama kaynak kodunu, bayt kodunu ve ikili dosyaları analiz etmek için tasarlanmış bir dizi teknolojidir. SAST çözümleri, bir uygulamayı çalışmayan bir durumda "içten dışa" analiz eder. - -## SDLC - -Yazılım geliştirme yaşam döngüsü. - -## Security Architecture - -Güvenlik kontrollerinin nerede ve nasıl kullanıldığını tanımlayan ve açıklayan ve ayrıca hem kullanıcı hem de uygulama verilerinin konumunu ve hassasiyetini tanımlayan ve açıklayan bir uygulamanın tasarımının bir özetidir. - -## Security Configuration - -Güvenlik kontrollerinin nasıl kullanıldığını etkileyen bir uygulamanın yapılandırması. - -## Security Control - -Bir güvenlik kontrolü (örneğin, bir erişim kontrol kontrolü) gerçekleştiren veya çağrıldığında bir güvenlik etkisine neden olan (örneğin bir denetim kaydı oluşturma) bir işlev veya bileşen. - -## SQL Injection (SQLi) - -Kötü amaçlı SQL ifadelerinin bir giriş noktasına eklendiği, veri odaklı uygulamalara saldırmak için kullanılan bir kod enjeksiyon tekniğidir. - -## SSO Authentication - -Tek Oturum Açma (SSO), kullanıcının kullandığı platform, teknoloji veya etki alanına bakılmaksızın, bir kullanıcı bir istemcide oturum açtığında ve ardından diğer istemcilerde otomatik olarak oturum açtığında gerçekleşir. Örneğin, google'da oturum açtığınızda otomatik olarak youtube, docs ve mail hizmetine giriş yaparsınız. - -## Threat Modeling - -Tehdit ajanlarını, güvenlik bölgelerini, güvenlik kontrollerini ve önemli teknik ve ticari varlıkları belirlemek için giderek artan şekilde iyileştirilmiş güvenlik mimarileri geliştirmekten oluşan bir teknik. - -## Transport Layer Security - -İnternet üzerinden iletişim güvenliği sağlayan kriptografik protokoller. - -## URI and URL - -Bir URI, bir adı veya web kaynağını tanımlamak için kullanılan bir karakter dizisidir. URL genellikle bir kaynağa referans olarak kullanılır. - -## User acceptance testing (UAT) - -Geleneksel olarak, tüm yazılım testlerinin yayınlanmadan önce gerçekleştirildiği üretim ortamı gibi davranan bir test ortamı. - -## Verifier - -OWASP MASVS gereksinimlerine göre bir başvuruyu inceleyen kişi veya ekip. - -## Whitelist - -İzin verilen veri veya işlemlerin listesi, örneğin giriş doğrulaması gerçekleştirmesine izin verilen karakterlerin listesi. - -## X.509 Certificate - -X.509 sertifikası, genel anahtarın sertifikada bulunan kullanıcıya, bilgisayara veya hizmet kimliğine ait olduğunu doğrulamak için yaygın olarak kabul edilen uluslararası X.509 genel anahtar altyapısı (PKI) standardını kullanan dijital bir sertifikadır. diff --git a/Document-tr/SUMMARY.md b/Document-tr/SUMMARY.md deleted file mode 100644 index 6369b691c..000000000 --- a/Document-tr/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# İçindekiler - -- [Değişiklik günlüğü](CHANGELOG.md) -- [Önsöz](0x01-Foreword.md) -- [Kapak Sayfası](0x02-Frontispiece.md) -- [MASVS'yi Kullanmak](0x03-Using_the_MASVS.md) -- [Değerlendirme ve Sertifikasyon](0x04-Assessment_and_Certification.md) - -## Güvenlik Gereksinimleri - -- [V1: Mimari, Tasarım ve Tehdit Modelleme Gereksinimleri](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Veri Depolama ve Gizlilik Gereksinimleri](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Kriptografi Gereksinimleri](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Kimlik Doğrulama ve Oturum Yönetimi Gereksinimleri](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Ağ İletişim Gereksinimleri](0x10-V5-Network_communication_requirements.md) -- [V6: Platform Etkileşim Gereksinimleri](0x11-V6-Interaction_with_the_environment.md) -- [V7: Kod Kalitesi ve Derleme Ayar Gereksinimleri](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Dayanıklılık Gereksinimleri](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Ekler - -- [Ek A: Sözlük](GLOSSARY.md) -- [Ek B: Referanslar](0x91-Appendix-B_References.md) diff --git a/Document-tr/book.json b/Document-tr/book.json deleted file mode 100644 index af7bced46..000000000 --- a/Document-tr/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "tr" -} diff --git a/Document-tr/images/CC-license.png b/Document-tr/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-tr/images/CC-license.png and /dev/null differ diff --git a/Document-tr/images/MASVS-levels.png b/Document-tr/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-tr/images/MASVS-levels.png and /dev/null differ diff --git a/Document-tr/images/NowSecure_logo.png b/Document-tr/images/NowSecure_logo.png deleted file mode 100644 index 1623c1b7f..000000000 Binary files a/Document-tr/images/NowSecure_logo.png and /dev/null differ diff --git a/Document-tr/images/OWASP_logo.png b/Document-tr/images/OWASP_logo.png deleted file mode 100644 index 9baaef889..000000000 Binary files a/Document-tr/images/OWASP_logo.png and /dev/null differ diff --git a/Document-tr/images/Randorisec_logo.png b/Document-tr/images/Randorisec_logo.png deleted file mode 100644 index c47304d1e..000000000 Binary files a/Document-tr/images/Randorisec_logo.png and /dev/null differ diff --git a/Document-tr/images/license.png b/Document-tr/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-tr/images/license.png and /dev/null differ diff --git a/Document-tr/images/masvs-levels-new.jpg b/Document-tr/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-tr/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-tr/images/masvs-mini-cover.jpg b/Document-tr/images/masvs-mini-cover.jpg deleted file mode 100644 index ca669209b..000000000 Binary files a/Document-tr/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-tr/images/masvs-mini-cover.png b/Document-tr/images/masvs-mini-cover.png deleted file mode 100644 index f90283553..000000000 Binary files a/Document-tr/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-tr/metadata.md b/Document-tr/metadata.md deleted file mode 100644 index e40b9aacb..000000000 --- a/Document-tr/metadata.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -# This is the main metadata file. -# Variables below can be overwritten by the local metadata -# file (e.g. Document-fr/metadata.md) - -# Custom Template variables (cover, first page, etc.) -languagetext: 'Türkçe' - -# Language variables -lang: 'tr' - ---- diff --git a/Document-tr/metadata.yml b/Document-tr/metadata.yml deleted file mode 100644 index cc443fc92..000000000 --- a/Document-tr/metadata.yml +++ /dev/null @@ -1,3 +0,0 @@ -language: 'tr' -languagetext: 'Türkçe' -toc_title: 'İçindekiler' diff --git a/Document-zhcn/0x01-Foreword.md b/Document-zhcn/0x01-Foreword.md deleted file mode 100644 index 0d4dfb0b3..000000000 --- a/Document-zhcn/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# 前言 - -在现代社会，技术革命无处不在。在不到10年前，智能手机是笨重的设备，并且几乎没有键盘。对于精通技术的用户来说，这样的玩物太昂贵了。今天，智能手机是我们生活中不可或缺的一部分。我们依赖智能手机获取日常信息、导航定位、沟通交流。它们已经渗透到商业和社交生活中的每一个角落。 - -每个新技术也相对地带来新的风险，而要跟上这些一直不断出现的变化是安全行业面临的一大挑战。防守方总是落后于技术发展几步。例如，许多人都会以旧的思维去考虑问题：智能手机就像小型电脑，而移动应用程序就像电脑上的软件一样，所以两样东西的安全方面的要求应该是一样的。可事实并非如此。智能手机操作系统不同于桌面操作系统，移动应用与网页应用又不同。举个例子，在现今的移动操作系统环境中，基于签名的病毒检测方法不起作用：它不仅与移动应用发行模式不兼容，而且由于移动系统的沙盒限制，在技术上也不可行。此外，某些类别的漏洞（如缓冲区溢出和跨站脚本XSS），和桌面应用与网页应用比起来，在普通移动应用程序中并不流行。 - -随着时间的推移，由于移动计算行业的发展，业界已经对安全问题有了可行的解决方案。我们的手机和其应用程序存储并处理我们的个人信息、照片、录音录像、笔记、银行账户信息、商业信息以及卫星定位等等。所以保证数据安全就相当于保证了移动安全。手机应用程序一般以客户端的形式存在以连接到我们日常使用的服务处理终端，处理我们与外界交换的每条信息。入侵了一个人的智能手机，就相当于得到对这个人的生活的所有信息。相较于电脑，智能手机的移动设备更容易丢失或被盗。随着移动恶意软件愈演愈烈，对移动数据保护的需求就愈发显著。 - -因此，移动应用的安全标准必须侧重于移动应用如何处理、存储和保护敏感信息。作为现代移动操作系统，iOS和安卓都为数据的存储与通讯安全提供了很好的API。但是，确保安全的前提是这些API都被正确地使用。数据存储、应用间通信、正确使用加密API和安全网络通信只是需要仔细考虑的一些方面而已。 - -需要业界共识的一个重要问题是，在保护数据的机密性和完整性方面究竟应该做到多严谨。例如，我们大多数人会认为移动应用应该在TLS交换中验证服务器证书。但是，SSL证书绑定呢？不这样做会导致漏洞的产生吗？如果移动应用程序处理敏感数据，这应是一项要求，还是可能会适得其反？另一种情况是，操作系统对应用程序进行沙盒保护，我们是否需要加密SQLite中的数据？适合一个应用的安全需求可能对于另一个应用来说不切实际。MASVS试图使用适合不同威胁情况的验证级别来标准化这些要求。 - -此外，具有系统权限的恶意软件和远程控制黑客软件的出现使人们意识到移动操作系统本身存在可利用的缺陷。因此，容器化策略被越来越多地用于提供对于敏感数据的保护和防止对于客户端的篡改。硬件级的安全功能和操作系统级的容器化解决方案（如 Android For Work和三星Knox）确实存在，但它们在不同设备上并非都可以使用。作为一种辅助措施，软件级别的措施可以提供相对有效的保护效用，但是目前没有标准或测试流程来验证这些类型的保护。 - -因此，移动应用安全测试报告各式各样：例如，一些测试人员把安卓移动应用程序中缺乏代码混淆或root检测认定为"安全漏洞"。另一方面，一些测试人员认为字符串加密、调试器检测或控制流混淆等措施为非必要措施。因为事情并非非黑即白的，这种不考虑实际情况的判断的缺乏实际意义。移动应用程序的韧性要求取决于一个它面临的移动客户端的威胁。软件保护并非毫无用处，它们最终可能会被绕过，因此不能将软件保护用作安全控制的替代品。 - -MASVS的总体目标是为移动应用程序安全提供基础需求（MASVS-L1），同时包括了额外的纵深防御措施（MASVS-L2） 和针对移动应用程序客户端威胁的保护（MASVS-R）。MASVS旨在实现以下目标： - -- 罗列出移动应用安全开发的需求以供软件架构师和开发人员使用; -- 提供可用于移动应用安全测试的行业标准; -- 阐明软件保护机制在移动安全中的作用，并提供验证其有效性的要求; -- 提出针对不同用例的安全级别的具体建议。 - -我们知道要取得100%的行业共识是不可能实现的。然而，我们希望MASVS在移动应用开发和测试的所有阶段都能够提供指导。作为开源标准，MASVS将随着时间的推移而发展，我们也欢迎任何协作与建议。 - -本纳德·穆勒 （Bernhard Mueller) diff --git a/Document-zhcn/0x02-Frontispiece.md b/Document-zhcn/0x02-Frontispiece.md deleted file mode 100644 index d3989e538..000000000 --- a/Document-zhcn/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# 关于标准 - -![OWASP Logo](images/OWASP_logo.png) - -欢迎阅读移动应用安全验证标准（MASVS. MASVS 是一个社区项目，其宗旨是建立一个安全需求的框架给人们去设计、开发和测试iOS和Android的移动应用程序。 - -MASVS是社区努力和行业反馈的成果。我们希望该标准会随着时间的推移不断更新，并且非常欢迎来自社区的意见反馈。 - -与我们取得联系的最佳方式是通过OWASP Mobile Project Slack频道: - -可以通过以下URL创建帐户: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/) - -## 版权和许可 - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -版权所有©2021 OWASP基金会。本作品是根据[知识共享署名-相同方式共享 4.0 国际许可](https://creativecommons.org/licenses/by-sa/4.0/)。对于任何重复使用或分发，您必须向他人明确此作品的许可条款。 - - - -## 致谢 - -| 项目负责人 | 主要作者 | 贡献者和审稿人 -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| 语言 |翻译和审核 | -| --------------- | ------------------------------------------------------------ | -| 繁體中文 | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| 簡體中文 | Bob Peng, Harold Zang, Jack S | -| 法语 | Romuald Szkudlarek, Christian Dong (审核) | -| 德文 | Rocco Gränitz, Sven Schleier (审核) | -| 印地语 | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 西班牙语 | Martin Marsicano, Carlos Holguera | -| 日语 | Koki Takeyama, Riotaro Okada (审核) | -| 俄语 | Gall Maxim, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| 韩语 | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| 波斯语 | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| 葡萄牙语 | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| 巴西葡萄牙语 | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| 土耳其 | Anıl Baş, Haktan Emik | -| 希腊语 | Panagiotis Yialouris | - -本文档是由Jim Manico编写的OWASP Application Security Verification Standard的一个分支。 - -## 赞助商 - -虽然MASVS和MASTG都是由社区自愿创建和维护的，但是有时候仍然需要一点外部的帮助。因此，我们感谢我们的赞助商提供资金来聘请技术编辑。但是，他们的赞助不会以任何方式影响MASVS或MASTG的内容。赞助方案的具体细节：[OWASP项目Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages"). - - - -最后，我们要感谢每一位从[Leanpub](https://leanpub.com/mobile-security-testing-guide)购买了这本书并以这种方式赞助我们的人。 diff --git a/Document-zhcn/0x03-Using_the_MASVS.md b/Document-zhcn/0x03-Using_the_MASVS.md deleted file mode 100644 index 99bc492e1..000000000 --- a/Document-zhcn/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,83 +0,0 @@ -# 移动应用安全验证标准 - -MASVS 可以被用于确立移动应用程序的安全程度。此标准(MASVS)的建立遵循了下面三个主要目标： - -- 可用于业界应用的安全度量标准 - 提供一个安全标准，让开发者和使用者们可以比较现有的移动应用程序； -- 可用于指导纲领 - 为移动应用程序整个开发阶段和测试提供安全指引； -- 可用于采购检验的验证参考 - 提供一个移动应用程序安全的验证标准。 - -## 移动应用安全模型 (Mobile AppSec Model) - -MASVS定义了两个安全验证级别（MASVS-L1 和 MASVS-L2），以及一系列的抵抗逆向工程防御韧性准则（MASVS-R）。 MASVS-L1是建议所有的移动应用程序都应该遵守的要求，MASVS-L2则针对的是处理高度敏感数据的移动应用程序。MASVS-R提供了需要防范客户端威胁时可以使用的额外防护管控方法。 - -满足MASVS-L1中所提到的要求，可以确保移动应用程序的安全，使开发流程符合信息安全的最佳实践方法，并且确保移动应用程序可以防御常见的安全问题。 MASVS-L2添加了额外的纵深防御（defense-in-depth），例如证书绑定（SSL pinning）。因此，MASVS-L2可以使移动应用程序能够更好的防范复杂的攻击行为 - 假设移动操作系统的安全控件完好无损，并且最终用户不被视为潜在的恶意用户。满足全部或者部分的MASVS-R软件保护要求，可以帮助阻止特定的客户端威胁，包括最终用户是恶意用户或者手机操作系统遭到破坏的情况。 - -**I: 虽然我们建议应该在每一个移动应用程序中实施MASVS-L1准则，但是否实施最终应是基于风险的决策，该决策应与软件所有者沟通。** - -**II: 请注意，MASVS-R和中所提到的软件保护准则无法确保不被绕过，绝对不能用作安全管控的替代品。相反的，这些软件保护准则旨在增加已落实MASVS-L1或MASVS- L2的移动应用程序，针对特定的威胁提供额外的防御。** - -![Verification Levels](images/masvs-levels-new.jpg) - -### 文档结构 - -MASVS的第一部分阐述了移动应用的安全模型和可用的安全验证级别，接着是有关如何使用本标准的建议。第二部分则是阐述了安全准则的细节和和对应的安全验证级别。基于技术的的目的或范畴，此准则被分成8个类别（从V1到V8）。准则类别与条目的命名方法如下（MASVS和MASTG使用相同的方法命名）： - -- *准则类别：* MASVS-Vx，例如：MASVS-V2: 数据存储和隐私 -- *准则条目：* MASVS-Vx.y，例如： MASVS-V2.2: "敏感数据不应被写入应用程序日志" - -### 安全验证等级细节 - -#### MASVS-L1: 标准安全等级 - -实现MASVS-L1的移动应用程序需要遵循移动应用程序安全的最佳实践方法。它包含了代码的质量，敏感数据的处理以及与移动环境交互的基本安全准则。此外，MASVS-L1必须有一个测试流程来验证安全管控。MASVS-L1适用于所有的移动应用程序。 - -#### MASVS-L2: 纵深防御（Defense-in-Depth） - -MASVS-L2引入了高于标准要求的高级安全管控方法。为了实现MASVS-L2，首先需要有一个威胁模型，并且把安全视为应用程序的一部分，加入到应用程序的架构和设计之中。MASVS-L2适用于处理高度敏感数据的应用程序，例如手机银行应用程序。 - -#### MASVS-R: 抵抗逆向工程和篡改的能力 - -符合MASVS-R的应用程序需具有最先进的安全性，并且可以抵抗有明确定义的特定客户端攻击，例如：篡改，程序修改或者逆向工程提取敏感代码或数据。这样的应用程序需要使用硬件安全模块或者是使用足够强大且经过验证的软件保护技术。MASVS-R适用于处理高度敏感数据的应用程序，并且可以用作保护知识产权或防篡改应用程序的一种方式。 - -### 使用建议 - -基于风险评估和应用程序的安全等级需求，应用程序可以被验证为符合MASVS L1或者L2。L1适用于所有移动应用程序，而L2通常建议用于处理更敏感数据或功能的应用程序。 MASVS-R（或其中的一部分）可以用于验证应用程序抵抗特定威胁的韧性。例如：重新封装或提取敏感数据。*另外*，也可以被用于更严谨的安全验证。 - -总而言之，可以使用如下的验证类别组合： - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -不同的验证类别组合反映出不同的安全等级和弹性。这样的组合方式是为了让安全具有灵活性，例如：手机移动游戏程序出于可用性的需求，可能不需要加入MASVS-L2的安全控制机制，如：双因子身份验证，但是在防篡改方面会存在强烈的业务需求。 - -#### 如何选择安全验证等级和类型 - -实现MASVS L2的安全准则可以增加安全性，但是也会增加开发成本，并有可能降低最终用户的体验，这是一种普遍存在的权衡。一般来说，是否采用L2来开发应用程序，要考虑风险与成本(比如，当机密性或完整性被破坏所造成的潜在损失高于额外的安全管控机制的成本时，就应该使用L2)。总体来说，在应用MASVS之前，风险评估应该是第一步。 - -##### 举例 - -###### MASVS-L1 - -- 应用于所有的移动应用程序。MASVS-L1列举了在不过分影响开发成本以及用户体验下的最佳安全实践方法。任何不适用于更严格安全等级的移动应用程序应该采用MASVS-L1标准。 - -###### MASVS-L2 - -- 医疗保健行业：存储个人身份信息的移动应用程序，因为这些信息可被用于身份盗窃，诈骗钱财或者其他的欺骗行为，所以应采用MASVS-L2。对于美国的医疗保健行业，需要遵守相关的信息保密法规 - 《健康保险可移植性和责任法案》（HIPAA）中的隐私权，安全性，违约通知规则和患者安全规则。 - -- 金融行业：可以访问和处理高度敏感信息（例如：信用卡卡号，个人信息或者转账功能）的移动应用程序。这些移动应用程序需要有额外的安全控制措施来防止欺诈行为。金融业相关的应用程序需确保遵守支付卡行业数据安全标准（PCI DSS），《格莱姆·里奇·布利利法案》和《萨班斯-奥克斯利法案》（SOX）。 - -###### MASVS L1+R - -- 以知识产权（IP）保护为商业目标的移动应用程序。MASVS-R中列举的韧性控制可以用于增加攻击者获取源代码，篡改以及破解的难度。 - -- 游戏行业：游戏应用程序对于防篡改和作弊有着强烈的需求，例如在线竞技游戏。游戏作弊对于在线游戏来说，是一个至关重要的问题，因为大量作弊者的存在，会导致其他玩家的不满，并且最终导致整个游戏的失败。MASVS-R提供了基础的防篡改控件，从而增加游戏作弊者的工作量。 - -###### MASVS L2+R - -- 金融产业：允许用户执行转账操作的手机银行应用程序，存在代码注入和在被不安全设备中运行的风险。在这种情况下，可以使用MASVS-R的安全管控机制了来防止篡改，从而提高恶意程序开发者的门槛。 - -- 所有在移动设备中需要存储敏感数据，以及支持不同种类的移动设备和操作系统的移动应用程序，建议采用MASVS L2+R。在这种情况下，安全控制机制可以被用来提高纵深防御，从而增加攻击者提取机密数据的难度。 - -- 带有内购功能的程序，建议采用服务端和MASVS L2来保护付费内容。但是，在某些情况下，无法使用服务端保护。在这些情况下，应该使用MASVS-R来增加逆向和篡改的难度。 diff --git a/Document-zhcn/0x04-Assessment_and_Certification.md b/Document-zhcn/0x04-Assessment_and_Certification.md deleted file mode 100644 index 38cd056f4..000000000 --- a/Document-zhcn/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# 评估与认证 - -## OWASP对MASVS认证和信任标志的立场 - -OWASP是一个中立的，对无厂商偏好的非盈利性组织。OWASP不会对任何厂商和软件进行认证。 - -任何像这样的保证声明，信任标志或认证，都没有经过OWASP官方的审查，注册或认证。因此，对于任何声称经过OWASP认证的第三方机构，各方必须谨慎地考虑其真实性。 - -这段声明并不是为了阻止任何组织提供认证服务，但任何组织都不应宣称拥有OWASP的官方认证。 - -## 认证移动应用程序的指南 - -移动应用安全认证标准（MASVS）推荐测试人员通过“Open Book”的方式对移动应用进行验证。也就是说，测试人员需要取得所有关于被测试应用的关键信息，比如，程序设计和开发人员的信息，项目文档，源码，用户服务登录权限，以及每个用户类别至少一个测试用户的用户名和密码。 - -需要注意的是，MASVS涵盖移动应用程序客户端的安全性，应用程序与其远程端点之间的网络通信，以及与用户身份验证和会话管理相关的一些基本和通用需求。它不包含对应用程序相关联的远程服务(例如web服务)的特定要求，以及与身份验证和会话管理相关的通用要求。威胁建模必须涵盖MASVS V1指定远程服务，并根据例如OWASP ASVS的相关标准进行验证。 - -提供认证的机构必须在所有的报告中阐明以下几点：认证的范围（特别是在关键的模块不在认证的范围中时），认证结果的总结（包含通过的和未通过的测试项目）并清楚阐明如何改进未通过的项目。业界的标准做法也要求测试人员保存详细的工作记录，截屏，录屏，可以复现的具体攻击过程，电子记录，网络代理的记录以及其他相关的笔记（例如目标服务器中待清理文件的清单）。仅仅报告自动化工具发现的问题是远远不够的，因为这样做，无法证明所有需认证的项目都已经经过了详细的测试。在出现争议的情况下，认证机构必须能够提供足够的证据来证明每一个验证的需求都经过了测试。 - -### 使用OWASP移动安全测试指南（MASTG） - -OWASP MASTG是用于测试移动应用程序安全性的手册。它描述了验证MASVS中列出的相关安全准则的技术过程。MASTG提供了一个测试案例的列表，每个测试案例都映射到MASVS中的一个安全准则。相比MASVS对于安全准则的通用性和一般性的描述，MASTG提供了基于不同移动操作系统的详细建议以及测试流程。 - -### 自动化安全测试工具的作用 - -使用自动化扫描工具对移动应用程序进行静态与动态的扫描可以提升应用程序安全测试的效率。但是，仅仅通过使用自动化工具来进行对MASVS验证是不切实际的。因为每个移动应用程序都是不一样的。此外，了解应用程序的总体架构、业务逻辑和以及相关技术框架的缺点，是验证移动应用程序安全性的必要条件。 - -## 其他用途 - -### 作为详细的安全架构指南 - -MASVS可以用来作为安全架构师的参考资料。SABSA与TOGAF，作为目前两个主流的的安全架构框架，缺少了很多关于移动安全架构评估的必要信息，而MASVS填补了这方面的空白。安全架构师可以使用MASVS作为参考，进行移动应用程序的安全设计。 - -### 作为安全编程检查清单 - -MASVS定义了两个安全检查级别用来对应不同的安全需求。相关单位可以按照自身需求自行定义对其适用的安全检查清单。相关单位还可以Fork MASVS 的 GitHub Repository来制定符合其自身需求的安全标准。注意由于MASVS可能进行更新，需要维护Fork版本的可追溯性。 也就是说，假如一个移动应用程序通过了安全测试准则4.1，随着MASVS的更新，此应用程序也通过的更新版本的安全测试准则4.1。 - -### 作为移动安全测试的基准 - -一套完整的移动安全测试方法应该包括所有MASVS列出的安全准则。OWASP移动安全测试指南(MASTG)对每个安全准则的验证需求都给出了黑盒与白盒测试的相关案例。 - -### 作为自动化单元和集成测试的指南 - -除了应用架构之外,大多数MASVS的安全准则，都是可以测试的。MASVS所定义的安全准则都可作为自动化单元测试、集成测试和验收测试集成到持续的软件开发生命周期中。这不仅有助于提升开发人员的安全意识，还提高了最终应用程序的整体质量，并有利于在软件发布早期的安全测试中减少安全漏洞的数量。 - -### 作为安全开发培训的参考资料 - -MASVS还可以用来定义移动应用程序的安全特性。市面上很多“安全编程”的课程不过是传授一些黑客技巧顺带加一点安全编程的小提示。这样的课程因其覆盖面的局限性因此对开发人员没有很大的帮助。移动开发安全课程可以参考MASVS进行制定，在覆盖十大代码安全问题的同时，重点关注与强调MASVS中提及的主动安全防护控制。 diff --git a/Document-zhcn/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-zhcn/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 98c77f8cb..000000000 --- a/Document-zhcn/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1：架构，设计和威胁建模要求 - -## 控制目标 - -在一个理想的环境中，整个开发流程都要考虑到安全需求。然而实际上，安全需求通常只是SDLC后期的考虑因素。除了技术上的控制，MASVS要求开发流程在规划程序架构设计时就明确考虑安全需求，并且清楚所有组件的功能性与安全性。大多数的移动应用程序都是作为远程应用的客户端，因此远端应用的安全性也必须被充分纳入考量。所以，不仅仅只局限测试于移动应用，完整的移动安全测试需要包含测设远端应用的安全性。 - -“V1”这个类别罗列了应用程序的架构和设计相关的需求。这是唯一没有对应到OWASP移动测试指南（MSTG）的技术测试类别。为了涵盖威胁建模，安全SDLC，秘钥管理等相关主题，建议读者参考其他相对应的OWASP项目与其他标准（下文将会列出链接）。 - -## 安全验证要求 - -下面列出了 `MASVS-L` 和 `MASVS-L2` 的要求。 - -| # | MSTG-ID | 描叙 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | 所有应用程序组件都须标注出来，并且确定它们全部是必需的。 | x | x | -| **1.2** | MSTG-ARCH-2 | 所有安全控制都必须在客户端与各个远程端点被强制执行。 | x | x | -| **1.3** | MSTG-ARCH-3 | 该移动应用程序的高级架构与所有的远程服务都应该被定义，并且该设计解决了所有安全的相关问题。 | x | x | -| **1.4** | MSTG-ARCH-4 | 在移动应用程序环境下敏感的数据应该被清楚的标识出来。 | x | x | -| **1.5** | MSTG-ARCH-5 | 所有应用程序组件都是根据它们提供的业务功能和/或安全功能来进行定义的。 | | x | -| **1.6** | MSTG-ARCH-6 | 已经制定了此 移动应用程序 和 相关的远程服务 的威胁模型，以识别潜在的威胁以及制定应对措施。 | | x | -| **1.7** | MSTG-ARCH-7 | 所有的安全控制都必须被集中管理。 | | x | -| **1.8** | MSTG-ARCH-8 | 如果移动应用程序用到加密密钥，就必须对密钥管理有明确的规定，并且强制推行密钥生命周期。理想情况下，应遵循 NIST SP 800-57密钥管理标准。 | | x | -| **1.9** | MSTG-ARCH-9 | 该移动应用程序存在强制更新的机制。 | | x | -| **1.10** | MSTG-ARCH-10 | 安全性在软件开发生命周期的所有阶段中都仔细纳入考量。 | | x | -| **1.11** | MSTG-ARCH-11 | 漏洞提交方案存在并且可用。 | | x | -| **1.12** | MSTG-ARCH-12 | 该应用程序必须遵守相关隐私法律法规。 | x | x | - -## 参考文献 - -更多信息，另请参见： - -- OWASP Mobile Top 10: M10 (外部功能) - -- OWASP 威胁建模 - -- OWASP 安全SDLC速查表 - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-zhcn/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-zhcn/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index c21209334..000000000 --- a/Document-zhcn/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,67 +0,0 @@ -# V2：数据存储和隐私要求 - -## 控制目标 - -保护敏感数据（例如用户登录信息和私人信息）是移动安全的重点。首先，不正确地使用操作系统机制（如IPC）将会使敏感资料以外地泄露给同一台设备上的其他应用程序。此外，数据也可能会意外泄漏到云存储，备份或键盘缓存中。与其他类型的设备相比，移动设备更容易丢失或被盗。因此，攻击者得以更容易地窃取敏感信息。所以，在移动应用程序中，对敏感信息的保护机制尤为重要。 - -注意：由于MASVS是以应用程序开发为中心的，因此它並不包括设备级的解决方案（诸如移动设备管理（Mobile Device Management - MDM ））。然而，我们还是建议您在企业环境中使用相关的设备级的解决方案来进一步提升数据的安全性。 - -### 敏感数据的定义 - -MASVS规范中涉及的敏感信息指的是用户登录信息和在实际应用情況中的任何敏感信息，例如： - -- 可能被犯罪分子滥用的个人身份识别信息（PII），如身份证号码，信用卡号码，银行账号，个人健康信息，电话号码，家庭住址； -- 一旦泄露，将会引起企业财产和声誉损失的高度敏感的数据，如合同信息，保密协议涵盖的信息，管理层人员信息； -- 任何被法律或出于合规原因必须受到保护的数据。 - - - -## 安全验证要求 - -通过遵循基本的规则，大多数的数据泄露问题是可以避免的。本章节列出的大多数验证都是必需要遵守的。 - -| # | MSTG-ID |描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | 如必须存储敏感信息（诸如PII，用户登录数据，加密密钥等），必须使用操作系统所提供的安全存储机制。| x | x | -| **2.2** | MSTG-STORAGE-2 | 敏感数据不应存储在应用程序容器或者系统凭据存储功能以外的地方。 | x | x | -| **2.3** | MSTG-STORAGE-3 | 敏感数据不应被写入应用程序日志。 | x | x | -| **2.4** | MSTG-STORAGE-4 | 如非绝对必要，敏感数据不能与第三方共享。 | x | x | -| **2.5** | MSTG-STORAGE-5 | 键盘缓存应当在处理敏感数据的文本输入上被禁用。 | x | x | -| **2.6** | MSTG-STORAGE-6 | 该应用程序使用的IPC机制不应泄露任何敏感数据。 | x | x | -| **2.7** | MSTG-STORAGE-7 | 该应用程序用户界面不应泄露任何敏感数据，如密码或密码。 | x | x | -| **2.8** | MSTG-STORAGE-8 | 移动操作系统生成的备份中不应包含敏感数据。 | | x | -| **2.9** | MSTG-STORAGE-9 | 当应用程序被移至后台时，存在当前视图中的敏感数据应当被删除。 | | x | -| **2.10** | MSTG-STORAGE-10 | 该应用程序不会在内存中保存超过必要时效的敏感数据，并且在使用后会彻底清除内存中的敏感数据。 | | x | -| **2.11** | MSTG-STORAGE-11 | 该应用程序采用了最低设备访问安全策略，强制要求用户设置设备密码。 | | x | -| **2.12** | MSTG-STORAGE-12 | 该应用程序主动告知用户其处理的用户个人身份信息的类型，并且主动告知用户使用该应用程序时应遵循的最佳安全做法。 | x | x | -| **2.13** | MSTG-STORAGE-13 | 不应将任何敏感数据存储在本地移动设备上。应用程序应在需要时从远程端点获取数据，并仅将其保存在内存作为临时使用中。 | | x | -| **2.14** | MSTG-STORAGE-14 | 如果需要在本地存储敏感数据，则应该使用需要身份验证的硬件级别加密的存储密钥对其进行加密。 | | x | -| **2.15** | MSTG-STORAGE-15 | 在多次用户尝试登陆应用失败后，应用程序将清除本地应用存储。 | | x | - -## 参考文献 - -OWASP移动安全测试指南对本章节中列出的验证要求都提供了的详细说明。 - -- Android：测试数据存储 - -- iOS：测试数据存储 - - -更多信息，另请参见: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-zhcn/0x08-V3-Cryptography_Verification_Requirements.md b/Document-zhcn/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 3a94c972d..000000000 --- a/Document-zhcn/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3：加密要求 - -## 控制目标 - -在移动设备上，涉及保护存储的数据时，加密是必不可少的因素。 这也是一个可能出现严重错误的地方，尤其是在不遵循标准规则的情况下。本章中的管理目的是：确保经过安全验证的应用程序，使用加密技术，并依照了业界的最佳做法。这里包括: - -- 使用经过验证的密码函数库； -- 正确选择和配置加密基元（cryptographic primitives）； -- 在任何需要随机数的地方都使用安全的随机数生成器。 - -## 安全验证要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | 该应用程序不依赖带有硬编码密钥的对称加密方式作为唯一的加密方法。 | x | x | -| **3.2** | MSTG-CRYPTO-2 | 该应用程序使用经过实现验证的密码基元。 | x | x | -| **3.3** | MSTG-CRYPTO-3 | 该应用在特定的案例下使用了合适的加密基元，参数配置符合行业最佳实践。 | x | x | -| **3.4** | MSTG-CRYPTO-4 | 该应用不使用基于安全目的而被广泛认为已经淘汰的加密协议或者算法。 | x | x | -| **3.5** | MSTG-CRYPTO-5 | 该应用不会将相同的秘钥重复用于多种途径。 | x | x | -| **3.6** | MSTG-CRYPTO-6 | 所有的随机数都被一个足够安全的随机数生成器生成。 | x | x | - -## 参考文献 - -OWASP 移动安全测试指南提供了验证本节中列出的要求的详细说明。 - -- Android: 测试密码学 - -- iOS: 测试密码学 - - -测试密码学: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-zhcn/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-zhcn/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 8ed4ad433..000000000 --- a/Document-zhcn/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4：身份验证 和 会话管理 - -## 控制目标 - -在绝大多数的移动应用程序架构中，用户登录到远程服务只是其中的一个组成部分。尽管大多数应用逻辑发生在客户终端，MASVS 定义了关于如何管理用户帐户和会话的基本要求。 - -## 安全验证要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | 如果该应用提供给用户访问远程服务，某些形式的认证，例如用户名/密码认证，都应在远程终端施行。 | x | x | -| **4.2** | MSTG-AUTH-2 | 如果状态会话管理被使用，则远程端点使用随机生成的会话标识符来认证客户端请求，而不会发送用户的凭证。 | x | x | -| **4.3** | MSTG-AUTH-3 | 如果无状态的基于令牌认证机制被使用，该服务器所提供的令牌应用安全算法签名。 | x | x | -| **4.4** | MSTG-AUTH-4 | 当用户注销时，远程端点应终止已经存在的会话。 | x | x | -| **4.5** | MSTG-AUTH-5 | 一套密码策略存在并且被强制执行在远程端点上。 | x | x | -| **4.6** | MSTG-AUTH-6 | 该远程终端执行一种机制来对抗提交凭据的次数过多。 | x | x | -| **4.7** | MSTG-AUTH-7 | 在预设不活动时间和访问令牌到期之后，在远程端点的会话将无效。 | x | x | -| **4.8** | MSTG-AUTH-8 | 生物特征认证（如果有的话）不是事件绑定的（即，使用仅返回“true”或“false”的API）. 相反，它基于解锁钥匙串/密钥库。 | | x | -| **4.9** | MSTG-AUTH-9 | 第二个因素认证存在于远程端点, 并且始终如一的按需执行。 | | x | -| **4.10** | MSTG-AUTH-10 | 敏感交易需要逐步进行身份验证。 | | x | -| **4.11** | MSTG-AUTH-11 | 该应用通过用户账号通知其所有敏感行为。用户可以查看设备列表, 查看场景信息 (IP 地址，位置，等等。) 以及屏蔽特定设备。 | | x | -| **4.12** | MSTG-AUTH-12 | 授权模型应该在远程端点被定义和被强制执行。 | x | x | - -## 参考文献 - -OWASP移动安全性测试指南提供了验证上面列出的要求的详细说明。 - -- 常规：身份验证和会话管理 - -- Android：测试本地身份验证 - -- iOS：测试本地身份验证 - - -有关更多信息，另请参见： - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-zhcn/0x10-V5-Network_communication_requirements.md b/Document-zhcn/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 3778cc295..000000000 --- a/Document-zhcn/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5：网络通信要求 - -## 控制目标 - -本节中列出的控制目标, 目的是确保移动应用程序和远程服务端点之间交换的信息的机密性和完整性。确保移动应用程序必须使用TLS协议作为网络信息传输的安全加密通道。L2列出了额外的深度防御措施，如SSL证书绑定。 - -## 安全验证要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | 在网络传输中使用TLS对数据加密。整个应用程序始终使用安全加密通道。 | x | x | -| **5.2** | MSTG-NETWORK-2 | 此TLS设置符合当前的最佳实践，当移动操作系统不支持推荐的标准时，则设置为最接近的标准。 | x | x | -| **5.3** | MSTG-NETWORK-3 | 当安全通道被建立后，该应用程序将验证远程端点的X.509证书。 并且仅接受由受信任的CA签名的证书。 | x | x | -| **5.4** | MSTG-NETWORK-4 | 该应用程序要么使用自己的证书存储区，要么固定端点证书或公钥，即便随后提供一个不同的，受信任的CA签署的证书或者秘钥，也不会与端点建立连接。 | | x | -| **5.5** | MSTG-NETWORK-5 | 该应用程序不依赖单一的不安全通信渠道（电子邮件或SMS）进行关键操作（例如：注册和帐户恢复）。 | | x | -| **5.6** | MSTG-NETWORK-6 | 该应用程序仅依赖于最新的连接和安全库。 | | x | - -## 参考文献 - -OWASP移动安全测试指南提供了验证本节中列出的要求的详细说明。 - -- 常规：测试网络通信 - -- Android: 测试网络通信 - -- iOS: 测试网络通信 - - -有关更多信息，另请参见： - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-zhcn/0x11-V6-Interaction_with_the_environment.md b/Document-zhcn/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index b70cc00b4..000000000 --- a/Document-zhcn/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,46 +0,0 @@ -# V6: 平台交互要求 - -## 控制目标 - -此组中的控制应确保应用程序以安全的方式使用平台API和标准组件。 -此外，这些控制还须涵盖不同应用之间的IPC通信安全。 - -## 安全验证要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | 该应用程序仅仅请求最少且必要的权限。 | x | x | -| **6.2** | MSTG-PLATFORM-2 | 所有外部以及用户输入都需要经过验证，并在必要时进行安全检查和过滤。所有通过用户界面，IPC 机制导入的数据，比如Intent、自定义的URL和来自网络的数据，都在此范畴内。 | x | x | -| **6.3** | MSTG-PLATFORM-3 | 除非这些机制得到正确的保护，否则应用程序不应通过自定义URL导出敏感数据。 | x | x | -| **6.4** | MSTG-PLATFORM-4 | 除非这些机制得到正确的保护，否则应用程序不应通过IPC导出敏感数据。 | x | x | -| **6.5** | MSTG-PLATFORM-5 | 除非明确要求，否则在WebViews中禁用JavaScript。 | x | x | -| **6.6** | MSTG-PLATFORM-6 | 设置WebViews只允许使用所需的最小协议处理程序集（比如，仅支持https）。具有潜在危险的处理程序，如文件存储、电话和应用程序id，应该被禁用。 | x | x | -| **6.7** | MSTG-PLATFORM-7 | 如果WebView可以调用应用程序的native方法，应确保WebView仅执行应用程序中的JavaScript。 | x | x | -| **6.8** | MSTG-PLATFORM-8 | 仅使用安全序列化API实现对象的反序列化。 | x | x | -| **6.9** | MSTG-PLATFORM-9 | 该应用程序具有保护屏幕覆盖攻击的机制。（仅限于Android） | | x | -| **6.10** | MSTG-PLATFORM-10 | 在销毁WebView之前，应清除WebView 的缓存、保存的文件以及加载的资源（比如JavaScript）。 | | x | -| **6.11** | MSTG-PLATFORM-11 | 该应用程序在用户输入敏感数据时应禁用第三方键盘程序。 仅限于iOS）| | x | - -## 参考文献 - -OWASP移动安全测试指南提供了验证本节中列出的要求的详细说明。 - -- Android: 测试平台交互 - -- iOS: 测试平台交互 - - -有关详细信息，请参阅： - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-zhcn/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-zhcn/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index adbf282d5..000000000 --- a/Document-zhcn/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: 代码质量和编译要求 - -## 控制目标 - -此控制的目标是确保应用程序开发时遵循基本安全编程实践，并确保应用程序使用编译器所提供的基本安全功能。 - -## 安全验证要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | 该应用程序使用有效的证书进行签名， 且私钥受到足够保护。 | x | x | -| **7.2** | MSTG-CODE-2 | 该应用程序以发布模式进行编译， 并配有适合发布版本的设置（例如不可调试模式）。 | x | x | -| **7.3** | MSTG-CODE-3 | 调试符号已从二进制文件中删除。 | x | x | -| **7.4** | MSTG-CODE-4 | 调试代码以及开发人员协助代码（例如程序后门、 隐藏设置）已被删除。应用程序不应记录详细错误或调试消息。 | x | x | -| **7.5** | MSTG-CODE-5 | 检查所有应用程序使用的第三方组件， 库以及框架，并检查其已知漏洞。| x | x | -| **7.6** | MSTG-CODE-6 | 该应用程序需能捕获并处理程序异常。 | x | x | -| **7.7** | MSTG-CODE-7 | 默认情况下， 安全控制中的错误处理逻辑拒绝访问。 | x | x | -| **7.8** | MSTG-CODE-8 | 对于没有自动进行内存管理的程序语言， 内存的分配，释放及使用需要被妥当地处理。 | x | x | -| **7.9** | MSTG-CODE-9 | 编译器提供的免费内置的二进制安全保护机制，例如代码缩小化， 堆栈保护，PIE支持和自动引用计数，已经开启。 | x | x | - -## 参考文献 - -OWASP 移动安全测试指南提供了验证上述要求的详细说明。 - -- Android: 测试代码质量和编译设置 - -- iOS: 测试代码质量和编译设置 - - -有关详细信息，请参阅： - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-zhcn/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-zhcn/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index 2316a4701..000000000 --- a/Document-zhcn/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,64 +0,0 @@ -# V8: 韧性要求 - -## 控制目标 - -本节涵盖的是对于应用程序中敏感数据（或功能）的处理以及访问的纵深防御措施。缺少这些防御措施并不会导致漏洞的产生，但是会降低应用程序对于逆向工程和某些客户端攻击的抵御能力。 - -相关人员应根据实际需求，基于应用程序可能面对的篡改或逆向工程进行风险评估从而实施本章节中的提到防御。我们建议查阅OWASP文档中的"逆向工程和未经授权的代码篡改的技术风险"章节（请参阅下面的参考资料）来了解相关的技术和业务风险。 - -**请注意，本章节列出的软件保护措施不能作为安全控制的替代品。MASVR-R中列出的防御措施旨在同时满足MASVS的安全要求的前提下，对于特定威胁的提供额外的保护。** - -此外，还有以下几点注意事项： - -1. 必须定义威胁模型且明确描述应用程序客户端所面临的威胁。此外，必须制定方案所提供的保护等级。例如，防御的既定目标可以是保护应用程序以迫使恶意软件作者必须投入大量精力来进行手动逆向分析。 - -2. 威胁模型必须敏感。例如，如果攻击者只需将白盒作为一个整体进行代码提升，那么在白盒实现中隐藏加密密钥就无从下手了。 - -3. 为了验证防御措施的有效性，必须通过具有相关经验（防篡改，防代码混淆）的从业人员进行手动测试（另见OWASP移动安全测试指南中的“逆向工程”和“评估软件保护”章节）。 - -### 阻碍动态分析与篡改 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | 该应用程序具有检测移动设备越狱（iOS）或rooted（安卓）的功能。在检测到时，必须提醒用户或终止应用程序。 | x | -| **8.2** | MSTG-RESILIENCE-2 | 该应用程序具有检测和防御调试器的功能。必须涵盖所有相关的调试协议。 | x | -| **8.3** | MSTG-RESILIENCE-3 | 该应用程序具有检测和防御对于其可执行文件和对于其沙盒中关键数据篡改的机制。 | x | -| **8.4** | MSTG-RESILIENCE-4 | 该应用程序具有检测和防御逆向工程工具与框架的机制。 | x | -| **8.5** | MSTG-RESILIENCE-5 | 该应用程序具有检测和防御模拟器的使用。 | x | -| **8.6** | MSTG-RESILIENCE-6 | 该应用程序具有检测和防御对于其内存空间中代码和数据篡改的机制。 | x | -| **8.7** | MSTG-RESILIENCE-7 | 该应用程序在每个防御类别中实现多个机制（8.1~8.6）。请注意，应用程序的韧性会随所用机制的原创性和多样性而增强。 | x | -| **8.8** | MSTG-RESILIENCE-8 | 检测机制应触发不同类型的（例如延迟的或隐避的）响应和防御机制。 | x | -| **8.9** | MSTG-RESILIENCE-9 | 代码混淆须应用于程序性的防御，这反过来又阻碍了通过动态分析攻击。 | x | - -### 设备绑定 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | 该应用程序使用从多个设备特 有的属性中派生的设备指纹实现设备绑定功能。 | x | - -### 阻碍理解 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | 应用程序须对所有可执行文件和库进行文件级加密。必须对其中重要代码和数据段进行加密或加壳。普通的静态分析不应获取重要的代码或数据。 | x | -| **8.12** | MSTG-RESILIENCE-12 | 如果应用程序使用代码混淆来保护敏感的数据运算，则代码混淆须使用最新的方法及研究成果，以防御自动与手动反混淆。 如有可能，相对于硬件级别，尽可能使用硬件级别的代码隔离。 | x | - -### 阻碍窃听 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | 作为深度防御的一项措施，除了对网络通信， 对于应用程序级的通信加密可进一步阻止窃听。 | x | - -## 参考文献 - -OWASP 移动安全测试指南提供了验证本节中列出的要求的详细说明。 - -- Android: 测试对于逆向工程的韧性 - -- iOS: 测试对于逆向工程的韧性 - - -有关详细信息，请参阅： - -- OWASP Mobile Top 10: M8 - -- OWASP Mobile Top 10: M9 - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-zhcn/0x90-Appendix-A_Glossary.md b/Document-zhcn/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 8ff9e18a3..000000000 --- a/Document-zhcn/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Appendix A: Glossary - -- **地址空间配置随机加载 (ASLR)** – 一种能让内存损坏漏洞的攻击更加困难的技术。 -- **应用程序安全(Application Security)** – 应用程序安全是针对OSI模型应用组件的分析，而不是针对操作系统或者网络连接。 -- **应用程序安全验证(Application Security Verification)** – 针对应用程序使用 OWASP MASVS 进行技术评估。 -- **应用程序安全验证报告(Application Security Verification Report)** – 一份针对特定的应用程序，由检测者制作并记录所有结果与相关分析的报告。 -- **身份验证(Authentication)** – 对应用程序的使用者身份验证。 -- **自动化验证(Automated Verificatio)** – 使用自动化工具（包括动态分析，静态分析或者两者皆使用），利用漏洞特征来挖掘漏洞。 -- **黑盒测试(Black box testing)** – 一种软件测试方法，在不知道内部结构和运作方式的状况下检测应用程序的功能。 -- **组件(Component)** – 一个独立的代码单元，具有与其他组件交流的关联磁盘和网络界面。 -- **跨站脚本(XSS)** – 一个常见的网站安全漏洞，它导致受到由攻击者控制的客户端脚本注入到网站的内容里。 -- **密码模块(Cryptographic module)** – 用于加密算法和/或生成加密密钥的软件，硬件或/和固件。 -- **通用缺陷列表(CWE)** – CWE是由社区开发的常见安全漏洞列表。它是一种通用的语言，是软件安全工具的衡量标准也是漏洞识别，缓解以及预防工作的基准。 -- **动态应用程序安全测试(DAST)** – 动态应用程序安全测试 (DAST) 技术被设计用来检测处于运行状态的应用程序的安全漏洞。 -- **设计验证(Design Verification)** – 应用程序安全架构的技术评估。 -- **动态验证(Dynamic Verification)** – 使用自动化工具在应用程序运行期间用漏洞签名来寻找漏洞。 -- **全局唯一标识符(GUID)** – 一个用作在软件中用作识别的唯一标识。 -- **超文本传输协议(HTTP)** – 一个用于分布式，协作式和超文本信息系统的应用层协议。它是万维网(World Wide Web)的资料通信的基础。 -- **硬编码密钥(Hardcoded keys)** – 存储在设备本身之中的加密密钥。 -- **进程间通信(IPC)** – 进程间通信 （Inter Process Communications）,在IPC，处理程序之间的通信交流并且与内核进行通信交流以协调其活动。 -- **输入验证(Input Validation)** – 一个规范化和验证用来处理不受信任用户的输入的机制。 -- **Java 字节码(JAVA Bytecode)** – Java 字节码是Java虚拟机的指令合集。每个字节码由一个或者两个字节（有些时候）组成，用来表示指令(opcode)，以及用于传递变量的零个或者多个字节。 -- **恶意代码(Malicious Code)** – 程序代码在程序所有者不知道的情况下添加到应用程序当中，它规避了应用程序的预期安全策略。恶意代码与恶意程序（如病毒或者蠕虫）不同。 -- **恶意程序(Malware)** – 在程序使用者和管理员不知情的情况下，可执行的程序代码在程序运行的时候被引入到程序。 -- **开放式Web应用程序安全项目(OWASP)** – 开放式Web应用程序安全项目 (OWASP) 是一个全球性的免费开发社区，致力于提高应用程序软件的安全性。我们的任务是使应用程序安全性“可见化”，以便人们和机构能够就应用程序安全风险做出明智的决策。请参阅： -- **个人验证信息(Personally Identifiable Information (PII))** – PII 是一个可以单独使用或者与其他信息一起使用的信息，用来识别、联络、定位某一个人，或者在上下文中识别个人。 -- **不基于地址的可执行代码(PIE)** – 地址无关可执行文件(Position-independent executable (PIE))是指可以在存储器中任意位置正确的运行，而不受到绝对地址影响的一种机器码。 -- **公钥基础设施(PKI)** – PKI是一种将公钥与实体的相应身份绑定的协议。绑定是通过认证机构(CA)的注册和发布过程建立的。 -- **静态应用程序安全测试(SAST)** – 静态应用程序安全测试(Static application security testing (SAST))是一系列的技术，其目的是用于分析程序源码，字节码和二进制代码，用于程序代码的编写和陈述安全漏洞的设计条件。SAST解决方案在非运行状态下“由内而外”的分析应用程序。 -- **SDLC** – 软件开发生命周期。 -- **安全架构(Security Architecture)** – 一个程序设计的抽象概念，用于辨识和描述安全控制的使用位置和方式，还可以用于辨识和描述用户和应用程序资料的位置和敏感性。 -- **安全配置(Security Configuration)** – 一个会影响安全控制措施使用方式的应用程序的配置文件。 -- **安全控制措施(Security Control)** – 一个功能或者组件执行安全检查（例如：一个访问控制检查）或者被调用时导致的安全结果（例如：生成一个审查记录）。 -- **SQL注入(SQLi)** – 用于攻击由数据驱动的应用程序，将恶意的SQL语句插入到注入点（entry point）。 -- **单点登录身份验证(SSO Authentication)** – 不论用户使用任何平台，技术或者是域名，单点登录身份验证(Single Sign On(SSO))可以让用户登录到一个客户端然后自动登录到其他的客户端。例如：当一个用户在登录谷歌时候，会自动登录到油管，谷歌文档和Gmail。 -- **威胁模型分析(Threat Modeling)** – 一种开发日益完善的安全体系结构以识别威胁媒介，安全区域，安全控制以及重要的技术和业务资产的方法。 -- **传输层安全性协议(Transport Layer Security)** – 提供互联网安全通信的加密协议。 -- **统一资源标志符和统一资源定位器(URI and URL)** – 统一资源标志符是用于识别名称或者网络资源的字符串。统一资源定位器通常用作资源的引用。 -- **用户验收测试(User acceptance testing (UAT))** – 所有的软件在上线前会在一个跟生产环境相似的测试环境中运行。 -- **验证者(Verifier)** – 基于OWASP MASVS要求，审核应用程序的个人或者团队。 -- **白名单(Whitelist)** – 一个列出了被准许的资料和操作的列表。例如：一个允许执行输入验证的字符列表。 -- **X.509 证书(X.509 Certificate)** – X.509证书是一个数字证书，它使用广泛接受的国际X.509公钥基础设施标准来验证公钥是否属于证书中包含的用户，电脑或者服务。 diff --git a/Document-zhcn/0x91-Appendix-B_References.md b/Document-zhcn/0x91-Appendix-B_References.md deleted file mode 100644 index c70ee7b0d..000000000 --- a/Document-zhcn/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# 附录B：参考资料 - -下列项目内容可以帮助使用者/采纳者更了解这个标准: - -- OWASP 移动安全项目 - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP 移动安全测试指南 - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP 移动应用十大风险 - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP 逆向工程以及程序代码修改的预防 - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -相同的，下列网站可以帮助使用者/采纳者更了解这个标准： - -- MITRE 常见弱点列举 - [https://cwe.mitre.org/](https://cwe.mitre.org/) -- PCI 安全性标准委员会 - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI 数据安全标准 (DSS) 要求和安全评估程序 第三版 - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-zhcn/CHANGELOG.md b/Document-zhcn/CHANGELOG.md deleted file mode 100644 index d17a39b8b..000000000 --- a/Document-zhcn/CHANGELOG.md +++ /dev/null @@ -1,98 +0,0 @@ -# 更新日志 - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 2020年3月7日 - 国际发行 - -以下是版本1.2的更改： - -- 提供MASVS的简体中文翻译。 -- 更改MASVS封面的标题。 -- 从MSTG中删除Mobile Top 10与CWE，并与MASVS中的现有引用进行合并。 - -## V1.2-RC - 2019年10月5号 - 预发行版 (仅限英语) - -以下为1.2-RC版本所包含的更新内容： - -晋升为同类安全指南最成功的作品。 - -- 更改要求 MSTG-STORAGE-1 "需要被使用"（need to be used）。 -- 增加侧重于数据保护的要求 MSTG-STORAGE-13， MSTG-STORAGE-14， 和 MSTG-STORAGE-15。 -- 更新要求MSTG-AUTH-11，以保护上下文信息（contextual information）。 -- 更新要求MSTG-CODE-4，以涵盖更多信息而不仅仅是排错调试（debugging）。 -- 添加要求MSTG-PLATFORM-10，以进一步安全的使用WebViews。 -- 添加要求MSTG-AUTH-12，以提醒开发人员部署授权，特别是在多用户应用程序（multi-user apps）的情况下。 -- 在怎样使用MASVS进行风险评估中添加了一点描述。 -- 在付费内容（paid content）中添加了一点描述。 -- 增加要求MSTG-ARCH-11，以包含针对L2应用程序的 责任披露政策（Responsible Disclosure policy）。 -- 增加要求MSTG-ARCH-12，以向应用程序开发人员展示他们应遵守的相关的国际隐私法律。 -- 为英文版的引用（references）创建了一个固定的格式。 -- 添加要求MSTG-PLATFORM-11，以反击通过第三方键盘进行的间谍活动（spying）。 -- 添加要求MSTG-MSTG-RESILIENCE-13，以阻止在应用程序中的窃听。 - -## V1.1.4 - 2019年7月4号 - 峰会版 - -以下为1.1.4版本所包含的更新内容： - -- 修复所有轻量级标记语言（markdown）问题。 -- 更新法文和西班牙文翻译。 -- 完成更新日志的繁体中文和日文翻译。 -- 自动验证 轻量级标记语言 的语法以及网址是否可以访问。 -- 新增标记代码到各个要求，以便于未来在MSTG中可以快速以及方便的找到相关建议和测试方案。 -- 缩减仓库大小，新增Generated到.gitignore文件中。 -- 新增行为守则以及撰稿准则（Contributing guidelines）。 -- 新增拉取要求（Pull-Request）模版。 -- 更新与Gitbook网页仓库同步的功能。 -- 更新所有翻译版本用来产生XML/JSON/CSV 的脚本。 -- 完成繁体中文版《前言》的翻译。 - -## V1.1.3 - 2019年1月9号 - 小幅度修正 - -以下为1.1.3版本所包含的更新内容： - -- 修正要求7.1内西班牙文翻译问题。 -- 在致谢区重新安排翻译者名字。 - -## V1.1.2 - 2019年1月3号 - 赞助者与国际翻译版 - -以下为1.1.2版本所包含的更新内容： - -- 新增感谢信，这封感谢信给予那些购买了电子版的人。 -- 在V4中添加了丢失身份验证链接和更新损坏的身份验证。 -- 修正英文版中的4.7和4.8互换。 -- 首次国际翻译版本！ - - 修正了西班牙文翻译。翻译目前已与英文版同步（1.1.2）。 - - 修正了俄罗斯文翻译。翻译目前已与英文版同步（1.1.2）。 - - 新增繁体中文，法文，德文和日文的第一版翻译。 -- 简化文件格式以方便后续翻译工作。 -- 新增自动化发布方式。 - -## V1.1.0 - 2018年7月14号 - -以下为1.1版本所包含的更新内容： - -- 删除要求2.6"在可能包含敏感信息的文字栏上停止使用剪贴板"。 -- 增加要求2.2"任何敏感资料不可以被存储在应用程序容器之外或者系统凭据存储设施中（System credential storage facilities）"。 -- 更新要求2.1的用词，改为 "系统凭据存储设施可以适当的用于存储敏感信息，例如：个人资料，使用者凭据或者加密密钥"。 - -## V1.0 - 2018年1月12号 - -以下为1.0版本所包含的更新内容： - -- 因为要求8.9和要求8.12 相同，因此删除要求8.9。 -- 使得要求4.6更加通用。 -- 一些小幅度修改（错别字或者错误的语法等）。 diff --git a/Document-zhcn/GLOSSARY.md b/Document-zhcn/GLOSSARY.md deleted file mode 100644 index 7ae68395f..000000000 --- a/Document-zhcn/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Appendix A: Glossary - -## 地址空间配置随机加载 (ASLR) - -一种能让内存损坏漏洞的攻击更加困难的技术。 - -## 应用程序安全(Application Security) - -应用程序安全是针对OSI模型应用组件的分析，而不是针对操作系统或者网络连接。 - -## 应用程序安全验证(Application Security Verification) - -针对应用程序使用 OWASP MASVS 进行技术评估。 - -## 应用程序安全验证报告(Application Security Verification Report) - -一份针对特定的应用程序，由检测者制作并记录所有结果与相关分析的报告。 - -## 身份验证(Authentication) - -对应用程序的使用者身份验证。 - -## 自动化验证(Automated Verificatio) - -使用自动化工具（包括动态分析，静态分析或者两者皆使用），利用漏洞特征来挖掘漏洞。 - -## 黑盒测试(Black box testing) - -一种软件测试方法，在不知道内部结构和运作方式的状况下检测应用程序的功能。 - -## 组件(Component) - -一个独立的代码单元，具有与其他组件交流的关联磁盘和网络界面。 - -## 跨站脚本(XSS) - -一个常见的网站安全漏洞，它导致受到攻击者控制的客户端脚本注入到网站的内容里。 - -## 密码模块(Cryptographic module) - -用于加密算法和/或生成加密密钥的软件，硬件或/和固件。 - -## 通用缺陷列表(CWE) - -CWE是由社区开发的常见安全漏洞列表。它是一种通用的语言，是软件安全工具的衡量标准也是漏洞识别，缓解以及预防工作的基准。 - -## 动态应用程序安全测试(DAST) - -动态应用程序安全测试 (DAST) 技术被设计用来检测处于运行状态的应用程序的安全漏洞。 - -## 设计验证(Design Verification) - -应用程序安全架构的技术评估。 - -## 动态验证(Dynamic Verification) - -使用自动化工具在应用程序运行期间用漏洞签名来寻找漏洞。 - -## 全局唯一标识符(GUID) - -一个用作在软件中用作识别的唯一标识。 - -## 超文本传输协议(HTTP) - -一个用于分布式，协作式和超文本信息系统的应用层协议。它是万维网(World Wide Web)的资料通信的基础。 - -## 硬编码密钥(Hardcoded keys) - -存储在设备本身之中的加密密钥。 - -## 进程间通信(IPC) - -进程间通信 （Inter Process Communications）,在IPC，处理程序之间的通信交流并且与内核进行通信交流以协调其活动。 - -## 输入验证(Input Validation) - -一个规范化和验证用来处理不受信任用户的输入的机制。 - -## Java 字节码(JAVA Bytecode) - -Java 字节码是Java虚拟机的指令合集。每个字节码由一个或者两个字节（有些时候）组成，用来表示指令(opcode)，以及用于传递变量的零个或者多个字节。 - -## 恶意代码(Malicious Code) - -程序代码在程序所有者不知道的情况下添加到应用程序当中，它规避了应用程序的预期安全策略。恶意代码与恶意程序（如病毒或者蠕虫）不同。 - -## 恶意程序(Malware) - -在程序使用者和管理员不知情的情况下，可执行的程序代码在程序运行的时候被引入到程序。 - -## 开放式Web应用程序安全项目(OWASP) - -开放式Web应用程序安全项目 (OWASP) 是一个全球性的免费开发社区，致力于提高应用程序软件的安全性。我们的任务是使应用程序安全性“可见化”，以便人们和机构能够就应用程序安全风险做出明智的决策。请参阅： - -## 个人验证信息(Personally Identifiable Information (PII)) - -PII 是一个可以单独使用或者与其他信息一起使用的信息，用来识别、联络、定位某一个人，或者在上下文中识别个人 - -## 不基于地址的可执行代码(PIE) - -地址无关可执行文件(Position-independent executable (PIE))是指可以在存储器中任意位置正确的运行，而不受到绝对地址影响的一种机器码。 - -## 公钥基础设施(PKI) - -PKI是一种将公钥与实体的相应身份绑定的协议。绑定是通过认证机构(CA)的注册和发布过程建立的。 - -## 静态应用程序安全测试(SAST) - -静态应用程序安全测试(Static application security testing (SAST))是一系列的技术，其目的是用于分析程序源码，字节码和二进制代码，用于程序代码的编写和陈述安全漏洞的设计条件。SAST解决方案在非运行状态下“由内而外”的分析应用程序。 - -## SDLC - -软件开发的生命周期。 - -## 安全架构(Security Architecture) - -一个程序设计的抽象概念，用于辨识和描述安全控制的使用位置和方式，还可以用于辨识和描述用户和应用程序资料的位置和敏感性。 - -## 安全配置(Security Configuration) - -一个会影响安全控制措施使用方式的应用程序的配置文件。 - -## 安全控制措施(Security Control) - -一个功能或者组件执行安全检查（例如：一个访问控制检查）或者被调用时导致的安全结果（例如：生成一个审查记录）。 - -## SQL注入(SQLi) - -用于攻击由数据驱动的应用程序，将恶意的SQL语句插入到注入点（entry point）。 - -## 单点登录身份验证(SSO Authentication) - -不论用户使用任何平台，技术或者是域名，单点登录身份验证(Single Sign On(SSO))可以让用户登录到一个客户端然后自动登录到其他的客户端。例如：当一个用户在登录谷歌时候，会自动登录到油管，谷歌文档和Gmail。 - -## 威胁模型分析(Threat Modeling) - -一种开发日益完善的安全体系结构以识别威胁媒介，安全区域，安全控制以及重要的技术和业务资产的方法。 - -## 传输层安全性协议(Transport Layer Security) - -提供互联网安全通信的加密协议。 - -## 统一资源标志符和统一资源定位器(URI and URL) - -统一资源标志符是用于识别名称或者网络资源的字符串。统一资源定位器通常用作资源的引用。 - -## 用户验收测试(User acceptance testing (UAT)) - -所有的软件在上线前会在一个跟生产环境相似的测试环境中运行。 - -## 验证者(Verifier) - -基于OWASP MASVS要求，审核应用程序的个人或者团队。 - -## 白名单(Whitelist) - -一个列出了被准许的资料和操作的列表。例如：一个允许执行输入验证的字符列表。 - -## X.509 证书(X.509 Certificate) - -X.509证书是一个数字证书，它使用广泛接受的国际X.509公钥基础设施标准来验证公钥是否属于证书中包含的用户，电脑或者服务。 diff --git a/Document-zhcn/Summary.md b/Document-zhcn/Summary.md deleted file mode 100644 index 3640b1dc2..000000000 --- a/Document-zhcn/Summary.md +++ /dev/null @@ -1,18 +0,0 @@ -目录 -更改日志 -前言 -绪论 -如何使用MASVS -评估和认证 -安全要求 -V1：体系结构、设计和威胁建模要求 -V2：数据存储和隐私要求 -V3：加密要求 -V4：身份验证和会话管理要求 -V5：网络通信要求 -V6：平台交互要求 -V7：代码质量和生成设置要求 -V8：韧性要求 -附录 -附录 A - 词汇表 -附录 B - 参考文献 diff --git a/Document-zhcn/images/CC-license.png b/Document-zhcn/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-zhcn/images/CC-license.png and /dev/null differ diff --git a/Document-zhcn/images/MASVS-levels.png b/Document-zhcn/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-zhcn/images/MASVS-levels.png and /dev/null differ diff --git a/Document-zhcn/images/OWASP_logo.png b/Document-zhcn/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-zhcn/images/OWASP_logo.png and /dev/null differ diff --git a/Document-zhcn/images/license.png b/Document-zhcn/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-zhcn/images/license.png and /dev/null differ diff --git a/Document-zhcn/images/masvs-cover-1.1.xcf b/Document-zhcn/images/masvs-cover-1.1.xcf deleted file mode 100644 index 7e4ddd1e0..000000000 Binary files a/Document-zhcn/images/masvs-cover-1.1.xcf and /dev/null differ diff --git a/Document-zhcn/images/masvs-levels-new.jpg b/Document-zhcn/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-zhcn/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-zhcn/images/masvs-mini-cover.jpg b/Document-zhcn/images/masvs-mini-cover.jpg deleted file mode 100644 index bae43fdf8..000000000 Binary files a/Document-zhcn/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-zhcn/images/masvs-mini-cover.png b/Document-zhcn/images/masvs-mini-cover.png deleted file mode 100644 index 15d07d0c2..000000000 Binary files a/Document-zhcn/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-zhcn/metadata.md b/Document-zhcn/metadata.md deleted file mode 100644 index 9014bc2a9..000000000 --- a/Document-zhcn/metadata.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'zhcn' # bug with polyglossia / switch back to english -languagetext: '(Simplified Chinese Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: '目录' - -mainfont: 'Noto Sans' -sansfont: 'Noto Sans' -monofont: 'Noto Sans Mono' -CJKmainfont: 'Noto Sans CJK SC' - ---- diff --git a/Document-zhtw/0x01-Foreword.md b/Document-zhtw/0x01-Foreword.md deleted file mode 100644 index 5a507f41c..000000000 --- a/Document-zhtw/0x01-Foreword.md +++ /dev/null @@ -1,26 +0,0 @@ -# 前言 - -科技的進步是相當快速的。就在不到10年前，智慧手機只是一個對於精通技術的商務人士所使用的一個昂貴的玩具，而且是一個又大然後有一個小小鍵盤的玩具。到今天，智慧手機已經變成我們每天不可缺少的一部份。我們開始依賴它，不只是在資訊的吸收上，甚至到導航，溝通，它已經成為了我們每天生活中工作和社交上一個獨特，重要而且難已被取代的工具。 - -每個新的技術也相對的帶著新的安全風險，而要跟上這些一直不斷出現的風險也是資安產業需要面對的一個大挑戰。防衛者一直都慢了幾步，舉例來說，一般人都會用舊的思維去做很多事情：智慧手機就像一台小電腦，行動應用程式就像是電腦上的程式，所以兩個東西對於資訊安全上的需求，應該就是一樣的吧？可是事實並非如此。智慧手機的作業系統與電腦的作業系統差異甚多，而行動應用程式也跟一般的網頁或電腦應用不同。再舉一個例子，電腦一般都會用特徵碼型態的防毒軟體去進行掃描，而在現今的行動作業系統上，這完全無法被合理化：因為這不只跟行動應用程式的發行模式不符合，同時也因為系統沙箱本身的限制造成技術上的困難。同時，有些弱點問題，例如緩衝區溢出或是跨網注入攻擊等點，是與常常以特殊或不尋常方式去執行的行動應用程式不相關，而這些問題卻是常在一般作業系統或是桌機應用程式上會看到的（當然也會有些例外）。 - -隨著時間的前進，我們的行業已經更好地掌握了行動應用威脅領域。 事實證明，行動應用安全是完全與資料保護相關：應用程式儲存了我們的個人訊息，圖片，錄音，筆記，帳戶資料，商業消息，位置等等。 它們成為了我們的端末設備，將我們連接到我們每天使用的服務，並做為處理我們與他人之間交換每條訊息的通信中心。 入侵一個人的智慧手機，你就可以獲得關於這個人未經過濾的與他息息相關的一切。 當我們認為行動電話更容易丟失或被盜或行動應用的惡意軟體正在增加時，對資料保護的需求就會變得更加明顯。 - -因此，行動應用的安全標準必須注意如何處理行動應用，儲存和保護敏感資料。 儘管iOS和Android等現代行動作業系統提供了許多用於安全資料儲存和通信的良好API，但是仍必須正確實施和使用這些API才有效。 資料儲存，應用程式之間的通信，加密API的正確使用和安全的網路通信只是需要仔細考慮的其中一方面而已。 - -需要這個行業共識的一個重要問題是，在保護資料的機密性和完整性方面應該要做到多嚴謹。 例如，我們大多數人都同意行動應用程式應該在TLS交換中驗證伺服器憑證。 但是SSL憑證綁定呢？ 不這樣做會導致漏洞嗎？ 應用程式處理中有要求要處理敏感資料，是否應該處理，還是這可能適得其反？ 我們是否需要加密儲存在SQLite資料庫中的資料，即使作業系統對應應用程式進行沙盒處理？ 適用於一個應用程式的需求可能對另一個應用程式不切實際。 MASVS嘗試使用不同的威脅情況和其驗證級別來標準化這些需求。 - -此外，出現於根系統中的惡意軟體和遠端管理工具使人們意識到行動作業系統本身具有可利用的缺陷，因此有越來越多的容器化策略用於為敏感資料提供額外保護並防止用戶端篡改。 這反而讓事情變得更複雜。 硬體支援的安全功能和作業系統級容器化解決方案（例如Android for Work和Samsung Knox）確實存在，但它們並非在所有的設備上都可以使用。 就像OK繃一樣，這可以施作於軟體的保護措施 - 但遺憾的是，沒有任何標准或測試流程來驗證這些類型的保護措施。 - -因此，行動應用安全測試報告充斥各處：例如，一些測試人員將Android應用中缺乏模糊處理或根檢測報告認定為“安全漏洞”。 另一方面，字符串加密，除錯器檢測或控制流混淆等措施不被視為需被強制執行。 然而，這種看待事物的二位元方式沒有任何意義，因為彈性不是二位元命題：它取決於一個旨在防範的特定用戶端威脅。 軟體保護並非無用，但最終可以繞過它們，因此絕不能將它們用作資安控制的替代品。 - -MASVS的總體目標是為行動應用安全（MASVS-L1）提供基准，同時還允許包含縱深防禦措施（MASVS-L2）和針對用戶端威脅的保護（MASVS-R））。 MASVS旨在實現以下目標： - -- 為尋求開發安全行動應用程式的軟體架構師和開發人員提供需求; -- 提供可在行動應用安全審查中進行測試的行業標準; -- 明確軟體保護機制在行動安全中的作用，並提供方式驗證其有效性的需求; -- 針對不同範例建議其安全級別並提供具體建議。 - -我們知道要做到 100％ 的行業共識是不可能實現的。 儘管如此，我們希望MASVS能夠在行動應用程式開發和測試的所有階段提供指導。 作為開源標準，MASVS將隨著時間的推進而發展，我們歡迎任何貢獻和建議。 - -Bernhard Mueller 撰寫 diff --git a/Document-zhtw/0x02-Frontispiece.md b/Document-zhtw/0x02-Frontispiece.md deleted file mode 100644 index e8dede6a5..000000000 --- a/Document-zhtw/0x02-Frontispiece.md +++ /dev/null @@ -1,52 +0,0 @@ -# 關於本標準 - -![OWASP Logo](images/OWASP_logo.png) - -歡迎參閱 Mobile Application Security Verification Standard (MASVS). MASVS 是一個社群的成果，目的在於建立一個安全需求的架構給人們去設計、開發和測試iOS跟Android的安全行動應用程式。 - -MASVS是結合社群的努力和業界意見反饋來訂定的標準。我們期望這份標準能夠隨著時間演進不斷更新，也十分歡迎來自社群的意見反饋。透過OWASP Mobile Project的Slack channel與我們連絡是聯絡我們的最佳方式，以下是我們的Slack channel連結: - -可以從以下的網址創建帳號：[https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## 版權和許可 - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 The OWASP Foundation. 本文檔在 Creative Commons Attribution ShareAlike 3.0 協議許可下發布。 對於任何二次使用或發布，你必須向其他人說明清楚這項成果的版權。 - - - -## 致謝 - -| 項目負責人 | 主要作者 | 貢獻者和校稿人員 -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| 語言 | 翻譯和複查人員 | -| --------------- | ------------------------------------------------------------ | -| 繁体中文 | Peter Chi, and Lex Chien, Henry Hu, Leo Wang | -| 简体中文 | Bob Peng, Harold Zang, Jack S | -| 法文 | Romuald Szkudlarek, Abderrahmane Aftahi, Christian Dong (Review) | -| 德文 | Rocco Gränitz, Sven Schleier (Review) | -| 印地語 | Mukesh Sharma, Ritesh Kumar, Atul Kunwar, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 西班牙文 | Martin Marsicano, Carlos Holguera | -| 日文 | Koki Takeyama, Riotaro Okada (Review) | -| 韓文 | Youngjae Jeon, Jeongwon Cho, Jiyou Han, Jiyeon Sung | -| 俄文 | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| 波斯語 | Hamed Salimian, Ramin Atefinia, Dorna Azhirak, Bardiya Akbari, Mahsa Omidvar, Alireza Mazhari, Milad Khoshdel | -| 葡萄牙語 | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| 巴西葡萄牙語 | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| 土耳其 | Anıl Baş, Haktan Emik | -| 希臘語 | Panagiotis Yialouris | - -本文檔最初是 Jim Manico 撰寫的 OWASP Application Security Verification Standard 的一個分支。 - -## 贊助者 - -雖然 MASVS 和 MASTG 都是由社群自願創建和維護的，但有時仍需要一些外部的協助。因此，我們感謝我們的贊助者提供資金來聘請技術編輯。請注意，他們的贊助不會以任何方式影響 MASVS 或 MASTG 的內容。贊助方案可在[OWASP Project Wiki](https://owasp.org/www-project-mobile-app-security/#div-sponsorship "OWASP Mobile Application Security Testing Guide Sponsorship Packages")找到。 - - - -最後，我們要感謝所有從[Leanpub](https://leanpub.com/mobile-security-testing-guide)購買這本書並以這種方式贊助我們的人。 diff --git a/Document-zhtw/0x03-Using_the_MASVS.md b/Document-zhtw/0x03-Using_the_MASVS.md deleted file mode 100644 index c0f15da55..000000000 --- a/Document-zhtw/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,81 +0,0 @@ -# 行動應用資訊安全驗證標準(Mobile Application Security Verification Standard) - -MASVS可以被用來確立一個行動應用Application的資訊安全程度。本標準(MASVS)的建立是遵循下列三個主要目標： - -- 作為業界應用的資安標準 - 提供一個資訊安全標準，讓開發者和使用者們可以比較現有的行動應用之資訊安全程度。 -- 作為軟體開發的指導綱領 - 提供一個行動應用軟體開發流程中各個步驟的指引，以便行動應用的開發與測試。 -- 作為採購檢驗的驗證參考 - 提供一個行動應用資訊安全的驗證基準。 - -## 行動應用的資訊安全模型(Mobile AppSec Model) - -MASVS定義了兩個嚴格的資訊安全驗證等級(L1和L2), 還有一系列的抗逆向工程防禦韌性準則(MASVS-R)，抗逆向工程準則會根據各種應用的不同威脅模型有相對應的調整。MASVS-L1和MASVS-L2包含通用的資訊安全準則，MASVS-L1是建議所有的行動應用都應該遵循的要求，而MASVS-L2則是針對處理高機敏資訊的行動應用。與此同時，MASVS-R則提供了需要防範用戶端威脅(client-side threat)時，可以使用的額外防護控管方法。 - -落實MASVS-L1可以確保行動應用的安全，使開發流程符合資訊安全的最佳實踐方法，並且確保行動應用可以防範常見的資訊安全弱點。MASVS-L2則是增加了更多的防禦縱深(defense-in-depth)，例如憑證綁定(SSL pinning)。因此，MASVS-L2可以使中行動應用能夠更好的防範複雜的攻擊行為 - 假設行動裝置作業系統的資訊安全管控完好，並且用戶端使用者並不被視為潛在的惡意用戶。落實全部或部分MASVS-R的軟體防護要求，可以幫助防止當用戶端使用者是惡意使用者或行動裝置作業系統被入侵時的特定用戶端威脅(client-side threats)。 - -**I: 雖然我們建議在每個行動應用程式中規劃符合 MASVS-L1 的標準，但是是否要執行這些控制項目最終仍須是風險控管的決定，也必須是要與企業業主溝通協調。** - -**II: 請注意在 MASVS-R 以及 OWASP 行動應用安全測試指南(OWASP Mobile Application Security Testing Guide)當中所提及的軟體保護控制項目中的軟體保護控制項目最終仍有可能被攻破，因此不能以此文件及指南當為資安控制的替代方案。本文件及指南之目的是依 MASVS-L1 及 MASVS-L2 為提供行動應用程式因威脅標準及保護層次不同對應至 MASVS 中。** - -![Verification Levels](images/masvs-levels-new.jpg) - -### 文檔結構 - -MASVS的第一個部分先闡述行動應用的資訊安全模型和可用的安全驗證等級，接著提供如何使用本標準的建議。安全準則的細節和對應的安全驗證等級，則是在第二部分。本標準中的準則，根據技術的目的/範疇，被分類成8個類別(從V1到V8)。準則類別與條目的命名方法，如下所示(MASVS和MASTG都使用相同的命名邏輯): - -- *準則類別:* MASVS-Vx，例如：MASVS-V2: 資訊存儲與隱私 -- *準則條目:* MASVS-Vx.y，例如： MASVS-V2.2: "機敏資訊不應該被寫進應用程式紀錄檔(application logs)" - -### 安全驗證等級細節 - -#### MASVS-L1: 標準安全等級 - -達到MASVS-L1的行動應用需要符合資訊安全的最佳實踐方法(best practices)。它包含了程式碼品質、處理機敏資訊和與行動環境交互的基本安全準則。另外，MASVS-L1也要求必須要有驗證資訊安全控管的測試流程。MASVS-L1(標準安全等級)適用於所有的行動應用程式。 - -#### MASVS-L2: 防禦縱深(加強安全等級) - -MASVS-L2引入了高於標準安全等級的進階安全控管方法。要落實MASVS-L2，首先必須要有一個威脅模型分析，並且把資訊安全視為行動應用的不可分割部分，加入到應用的架構和設計之中。加強安全等級適用於處理機敏資訊的應用程式，例如：行動銀行。 - -#### MASVS-R: 抗逆向工程和竄改的韌性 - -符合MASVS-R的應用程式必須應用最新資訊安全技術，並且有足夠的韌性來抵抗明確定義的特定用戶端攻擊，例如資訊竄改， 程序修改或逆向工程來提取機敏的資訊或程式碼。這樣的應用程式需要使用硬體安全模塊或者是被驗證過的高安全性軟體防護技術。MASVS-R適用於處理高機敏資訊的應用程式，並且可以被用來當作一種保護智慧財產的方法或防止竄改應用程式的方法。 - -### 使用建議 - -根據風險評估和應用程式的安全等級需求，應用程式可以被驗證為符合MASVS-L1或L2。L1適用於所有行動應用，而L2通常建議需要處理機敏資訊或功能的行動應用遵循。MASVS-R (或其一部分)可以被用於驗證行動應用抵抗特定威脅的韌性，例如：重封裝或提取機敏資訊。*另外*，也可以被用於更嚴謹的資訊安全驗證。 - -總而言之，可行的驗證類別組合，如下所示: - -- MASVS-L1 -- MASVS-L1+R -- MASVS-L2 -- MASVS-L2+R - -不同的驗證類別組合反映出不同的資訊安全等級和韌性。這樣的組合方式是為了保留一些彈性，例如: 手機遊戲程式因為高可用性的需求，可能不須加入MASVS-L2的安全控管機制，如: 雙因子驗證，但相對的手機遊戲程式對防止竄改的安全控管，通常會有很高的需求。 - -#### 如何選擇安全驗證等級和準則 - -落實MASVS-L2的安全準則可以增進資訊安全，但是也會同時增加開發成本以及可能降低使用者體驗。一般來說，決定是否採用L2來開發應用，取決於其風險與成本考量 (也就是說，當因為應用程式的保密性或完整性被破壞導致的潛在損失比增加額外安全控管機制的成本高時，會考慮採用L2)。因此，風險評估應該被視為是應用MASVS之前的第一步。 - -##### 範例 - -###### MASVS-L1 - -- 適用於所有行動應用程式。MASVS-L1列舉了可以不過分影響開發成本和使用者體驗的資訊安全最佳實踐方法。任何不適用於更嚴格安全等級的行動應用程式，應該採用MASVS-L1的準則。 - -###### MASVS-L2 - -- 醫療保健產業: 儲存個人可識別資訊(personally identifiable information)的行動應用程式，建議採用MASVS-L2，因為個人可識別資訊是機敏資訊，可能被用於冒用身份，詐騙取財或其他各種欺騙行為。對於美國的醫療保健行業，需要遵循相關的資訊保密法規 - 健康保險便利和責任法案(HIPAA) 中的Privacy, Security, Breach Notification Rules and Patient Safety Rule。 - -- 金融產業: 可以存取高機敏資訊(例如: 信用卡號碼，個人資訊或轉帳功能)的行動應用程式，建議採用MASVS-L2。這些行動應用程式必須確保有額外的資訊安全控管機制來防止詐騙。金融相關應用程式須確保遵循支付卡產業資料安全標準(PCI DSS)，金融服務法現代化法案(Gramm Leech Bliley Act)以及薩班斯-奧克斯利法案 (SOX)。 - -###### MASVS L1+R - -- 以智慧財產的保護為商業目的之一的行動應用程式，建議採用MASVS L1+R。MASVS-R中列舉的安全控管機制可以被用於增加攻擊者獲取原始程式碼，竄改或破壞程式的難度。 - -- 遊戲產業: 對於防止竄改程式和作弊，遊戲應用程式有強烈的需求。遊戲作弊行為對線上遊戲來說，是一個很重要的議題，因為遊戲作弊者的存在，會引起玩家群體的不滿，並且最終導致整個遊戲的失敗。MASVS-R提供了基礎的防篡改機制來幫助減小遊戲作弊者出現的可能性。 - -###### MASVS L2+R - -- 金融產業: 允許使用者做轉帳操作的行動銀行應用程式，有程式碼注入和在被入侵的裝置上執行的風險。在這種情況下，MASVS-R的安全控管機制可以被用來防止篡改和提高惡意程式開發者的進入門檻。 - -- 所有被設計需要儲存機敏資料在行動裝置和支持許多不同種類行動裝置與作業系統版本的行動應用程式，建議採用MASVS L2+R。在此情況下，安全控管機制可以被用於提高防禦縱深的手段，進而提高攻擊者提取機敏資訊的難度。 diff --git a/Document-zhtw/0x04-Assessment_and_Certification.md b/Document-zhtw/0x04-Assessment_and_Certification.md deleted file mode 100644 index 8e4537db0..000000000 --- a/Document-zhtw/0x04-Assessment_and_Certification.md +++ /dev/null @@ -1,47 +0,0 @@ -# 評估與認證 - -## OWASP 對 MASVS 認證與信任標誌聲明 - -OWASP是一個中立無廠商偏好的非營利組織。OWASP本身並不會認證/授權任何廠商、認證機構或者軟體。 - -任何這樣的保證聲明、信任標誌或認證，都不會是OWASP官方正式審查、註冊或認證的！因此，任何組織都必須十分謹慎地看待，且不應輕易相信任何宣稱其擁有MASVS認證或信任標誌的第三方機構。 - -這段聲明並不是阻止任何組織去提供相關的認證服務，但任何組織不該宣稱擁有OWASP官方的認證。 - -## 行動應用程式認證指南 - -推薦使用行動應用資訊安全驗證標準(MASVS)來驗證行動應用程式的方法是採用“開書(open book)”的方式。也就是說測試人員會被給予存取關鍵資源(如：誰是應用程式的開發者和架構師、專案文件、原始程式碼，以及對端點<伺服器、應用程式>存取的合法授權帳號<至少每個不同權限各有一個帳號>)的權限。 - -請注意MASVS只包含了對應用程式用戶端(client-side)、應用程式與其遠端端點的網路通訊，以及一些對使用者驗證和會話(session)管理的通用基本準則。MASVS不包含對與應用程式相關連的遠端服務(如：Web服務)的個別準則，安全地只使用部分對使用者驗證和會話(session)管理的通用準則的方法。然而，MASVS V1要求遠端服務必須被包括在整體威脅模型，並且以適用的標準來驗證遠端服務，例如OWASP ASVS。 - -提供認證的機構必須要在所有的報告中，闡明以下幾點：認證的範圍(尤其如果有重要程式模塊不在認證範圍中)、認證結果總結(包含通過和失敗的測試項目)並清楚的解釋如何改進未通過的項目。業界的標準做法也同時要求保持詳細的工作記錄、螢幕截屏或影片、可以重複有效地執行弱點入侵的腳本和測試的電子紀錄(如：擷取下來的代理伺服器記錄檔和相關的筆記(如：待清理清單))。只是簡單的執行工具和報告發現的問題是不足夠的，因為這樣無法提供足夠的證據說明所有的認證相關的問題/準則都已經被完整地測試。為了防止爭議，認證機構必須提供充足的支持證據來證明所有需驗證的項目都已經確實地被測試過。 - -### OWASP 移動安全檢測操作指南 (MASTG) - -OWASP MASTG是測試行動應用程式安全的指導手冊。它描述了驗證被列在MASVS中相關準則的技術流程。MASTG提供了一個測試方案的列表，每一個測試方案都可以連結到一個MASVS的準則。雖然MASVS的準則都是概念性的和通用性的，MASTG提供了對不同行動作業系統的相對應深層次的建議以及測試流程。 - -### 自動化資訊安全檢測工具的使用 - -在可能的情況下，為了增加效率，程式碼掃描工具和黑箱測試工具的使用是被鼓勵的。然而，要完成MASVS的驗證是不可以只單獨依賴自動化工具的，因為每個行動應用程式都是不同的，而且了解應用程式的整體架構、商業邏輯和應用特定技術和框架帶來的缺點是驗證應用程式安全的必要條件。 - -## 其他用途 - -### 詳解安全架構開發指南 - -常見的行動應用資訊安全驗證標準(MASVS)使用方式是把MASVS當成是安全架構師的參考資料。目前兩個主要的安全架構框架：SABSA或TOGAF，都缺少了很多完成行動應用程式安全架構檢查所必需的資訊。MASVS透過提供這些缺失的必需資訊來幫助安全架構師在常見的行動應用程式議題上，選擇更好的安全控管機制。 - -### 取代現成的安全程式設計檢查表(Secure Coding Checklists) - -許多組織都可以透過套用MASVS而受益，藉由選擇兩個安全等級之一或以MASVS為基準(fork)，發展出因應各個應用程式的風險等級需求的行業特殊準則。我們鼓勵這樣以MASVS為基準的再發展(fork)，只要可以維持其可追溯性。如此一來，當一個應用程式已經通過了準則4.1，也就意味著隨著標準演進，此應用程式通過了再發展版本的準則4.1。 - -### 基本安全性檢測與方式 - -好的行動應用程式安全檢測方法應該包含所有MASVS列舉的準則。OWASP 移動安全檢測操作指南(MASTG)描述了黑箱測試和白箱測試對每一個需檢測準則的測試方案。 - -### 自動化單元與和測試指南 - -MASVS被設計為擁有高度可測試性，除了架構上的需求以外，自動化單元、整合測試和驗收測試基於MASVS準則，可以被整合到程式持續開發生命周期(continuous development lifecycle)中。這不僅增強了開發人員的資安意識，也增進了應用程式的整體品質，更減少了在程式發布前階段，資訊安全測試的工作量(因為有提前做了整體自動化測試，可以減少後續發現重複或明顯問題的機會)。 - -### 安全性開發培訓課程 - -MASVS也可以被用來定義安全行動應用程式的特性。很多“安全開發”課程，其實只是道德駭客課程，再加上一點點程式開發的小提示。這樣的課程並不能很好的幫助開發人員。因此，安全開發課程可以使用MASVS，並且主要專注在MASVS中列舉的預先防護的資安控管機制，而不是其他MASVS的資安議題(例如：十大程式安全問題)。 diff --git a/Document-zhtw/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document-zhtw/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index b569f50ee..000000000 --- a/Document-zhtw/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,37 +0,0 @@ -# V1: 架構, 設計和威脅模型分析準則 - -## 控制目標 - -在一個完美的世界中，整個開發階段都會考慮到安全性。 然而實際上，安全性常常只是 SDLC 後期的考慮因素。 除了技術控制之外， MASVS 需要制定流程，以確保在規劃行動應用程式的結構時明確考慮到安全性的問題，並確認所有元件的功能性和安全性是清楚的。 由於大多數行動應用程式是作為遠程服務的用戶端，因此必須確保妥善的安全標準也運用在這些服務 - 但獨立測試行動應用程式是不夠的。 - -“V1”這個類別列出了與應用程式的架構和設計有關的要求。 因此，這是唯一沒有對應到 OWASP Mobile Application Security Testing Guide 裡的技術測資的類別。 為了涵蓋威脅模型分析，安全 SDLC，密鑰管理等主題，MASVS 的用戶應參考相對應的OWASP項目 和/或 其他標準，例如下面連結所提到的。 - -## 安全驗證準則 - -以下列出了 MASVS-L1 和 MASVS-L2 的要求。 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | 所有應用程式組成元件都已歸類並且已知是必需的。 | x | x | -| **1.2** | MSTG-ARCH-2 | 安全控制永遠不會僅僅在客戶端強制執行，而是在相對應的遠程端點上也必須強制執行。 | x | x | -| **1.3** | MSTG-ARCH-3 | 行動應用程式的高級架構和所有連接的遠程服務已經被定義，並且該架構已解決了安全性的問題。 | x | x | -| **1.4** | MSTG-ARCH-4 | 在行動應用程式環境中被認為敏感的資料已被明確歸類。 | x | x | -| **1.5** | MSTG-ARCH-5 | 所有應用程式的組成都根據它們提供的業務功能 和/或 安全功能進行定義。 | | x | -| **1.6** | MSTG-ARCH-6 | 行動應用程式和相關遠程服務的威脅模型已經制定，以識別潛在的威脅和對策。 | | x | -| **1.7** | MSTG-ARCH-7 | 所有安全控制都有一個集中的管理。 | | x | -| **1.8** | MSTG-ARCH-8 | 如何管理加密金鑰（如果有）有明確方針，而且加密金鑰生命週期需強制實施。 理想情況下，遵循 NIST SP 800-57 等鑰匙管理標準。 | | x | -| **1.9** | MSTG-ARCH-9 | 存在強制行動應用程式更新的機制。 | | x | -| **1.10** | MSTG-ARCH-10 | 安全性在軟體開發生命週期的所有階段中仔細納入考量。 | | x | -| **1.11** | MSTG-ARCH-11 | 需要一個有效的責任披露政策被執行。 | | x | -| **1.12** | MSTG-ARCH-12 | 應用程式需遵守隱私法規及政策。 | x | x | - -## 參考 - -更多資訊請參閱： - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Thread modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document-zhtw/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document-zhtw/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index b4c6213b7..000000000 --- a/Document-zhtw/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,65 +0,0 @@ -# V2: 資料存儲和隱私要求 - -## 管理目標 - -保護機敏資料（如用戶憑據和個人訊息）是行動安全的重點。首先，如果操作系統機制諸如 IPC 使用不當，這將會讓敏感的資料被無意中暴露在同一設備或其他應用程式上。此外，資料可能會無意中從雲端被存取，備份，甚至從鍵盤緩存中洩漏。此外，與其他類型的設備相比，行動設備很容易丟失或被盜。因此，第三方可以更容易地竊取相關資訊。在這種情況下，可以實施額外的保護機制使獲取機敏資料更加困難。 - -注意：由於 MASVS 是以應用程式開發為中心的，因此它並不包括像 MDM 那樣的解決方案和策略。我們建議您在企業環境中使用相關策略來進一步增強資料的安全性。 - -### 機敏資料的定義 - -MASVS 規範中的涉及敏感資料用戶憑證和在特定情況中被視為機敏的任何其他資料，例如： - -- 可能被犯罪集團濫用的個人識別資料（PII）：社會安全號碼，信用卡號碼，銀行帳號，醫療資訊; -- 可能因洩漏其極機敏資料而導致財務損傷，合約資料，保密協議，管理資料等; -- 任何必須被法律保護或出於同原因而受到保護的資料。 - -## 安全驗證要求 - -通過遵循簡單的規則與定義可以防止絕大多數資料洩露問題， 本章中列出的大多管理目標對於所有驗證級別都是必需的。 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | 系統的憑證儲存功能適用於儲存機敏資料，如個人識別訊息，用戶憑證，加密密鑰等。 | x | x | -| **2.2** | MSTG-STORAGE-2 | 機敏資料不儲存在應用程式的服務器或系統以外的憑證儲存功能。 | x | x | -| **2.3** | MSTG-STORAGE-3 | 機敏資料未寫入應用程式日誌。 | x | x | -| **2.4** | MSTG-STORAGE-4 | 除非對架構有必要，否則不與第三方共享機敏資料。 | x | x | -| **2.5** | MSTG-STORAGE-5 | 於明文輸入機敏資料部分禁用鍵盤緩存。 | x | x | -| **2.6** | MSTG-STORAGE-6 | 機敏資料不通過 IPC 機制公開。 | x | x | -| **2.7** | MSTG-STORAGE-7 | 密碼和定義參數等機敏資料不會通過用戶界面公開。 | x | x | -| **2.8** | MSTG-STORAGE-8 | 在行動作業系統生成任何備份的檔案中不可包含機敏資料。 | | x | -| **2.9** | MSTG-STORAGE-9 | 行動應用程式移至背景執行時需刪除機敏資料。 | | x | -| **2.10** | MSTG-STORAGE-10 | 應用程式不會在記憶體中保存超過必要時效的機敏資料，並且在使用後會明確清除記憶體內容。 | | x | -| **2.11** | MSTG-STORAGE-11 | 應用程式採用了最低訪問安全策略，會要求用戶設置密碼等。 | | x | -| **2.12** | MSTG-STORAGE-12 | 應用程式已主動告知如何處理用戶的個人識別訊息，並且主動告知用戶的使用應用程式時要遵循的要點。 | x | x | -| **2.13** | MSTG-STORAGE-13 | 機敏資料不應被儲存在行動應用裝置本機儲存空間上。機敏資料應儲存在遠端端點，然後在需要時讀取並儲存於記憶體中。 | | x | -| **2.14** | MSTG-STORAGE-14 | 如果機敏資料需要被儲存於行動應用裝置本機儲存空間，該資料應經過本機認證程序後可被使用之硬體加密系統加密後儲存。 | | x | -| **2.15** | MSTG-STORAGE-15 | 行動應用程式的本機儲存空間應在多次認證失敗後，自動進行資料清除之工作。 | | x | - -## 參考 - -OWASP 行動安全檢測指南列出相關要求，並且相關章節中有詳細說明。 - -- For Android - -- For iOS - - -更多相關信息，另請參閱： - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document-zhtw/0x08-V3-Cryptography_Verification_Requirements.md b/Document-zhtw/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 4a851819d..000000000 --- a/Document-zhtw/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: 加密要求 - -## 管理目標 - -加密是保護行動設備上儲存的資料的重要因素。 特別是如果不遵守標準規則開發，事情可能出現嚴重錯誤。 本章中的管理目的是檢測經過驗證的應用程序是否根據行業最佳實踐使用加密，例如： - -- 使用經過驗證的加密方式; -- 正確選擇和設置加密明文; -- 在需要亂數的地方皆有使用亂數產生器. - -## 安全檢測要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | 應用程式不可使用 hardcoded 作為加密方法。| x | x | -| **3.2** | MSTG-CRYPTO-2 | 應用程式中使用驗證過的加密演算法。 | x | x | -| **3.3** | MSTG-CRYPTO-3 | 使用適用於該案例中所應使用的加密演算法， 並基於業界最佳實踐的方式設定其參數。 | x | x | -| **3.4** | MSTG-CRYPTO-4 | 應用程式不應使用基於安全目的而被廣 泛棄用的加密協議和算法。 | x | x | -| **3.5** | MSTG-CRYPTO-5 | 加密金鑰不重複使用。 | x | x | -| **3.6** | MSTG-CRYPTO-6 | 所有亂數是經由安全的亂數產生器產生。 | x | x | - -## 參考 - -OWASP 行動安全檢測指南列出相關要求，並且相關章節中有詳細說明。 - -- Android - -- iOS - - -更多相關信息，另請參閱： - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document-zhtw/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document-zhtw/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 541171211..000000000 --- a/Document-zhtw/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: 身份驗證和對談管理準則 - -## 控制目標 - -在多數情況下，登錄遠端服務的用戶是整個行動應用程式架構整體的ㄧ部分。 即使大多數邏輯發生在端點，MASVS定義了有關如何管理用戶帳戶和對談的一些基本要求。 - -## 安全驗證準則 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | 如果應用程式向用戶提供對遠端服務的訪問權限，則用戶名/密碼驗證等一些形式的身份驗證會在遠端端點執行。 | x | x | -| **4.2** | MSTG-AUTH-2 | 如果使用有狀態的對談管理，則遠端端點使用隨機生成的交談識別碼來驗證客戶端請求，而不發送用戶憑證。 | x | x | -| **4.3** | MSTG-AUTH-3 | 如果使用無狀態token-based驗證方式，則服務器會提供使用安全算法簽名的token。 | x | x | -| **4.4** | MSTG-AUTH-4 | 當用戶登出時，遠端端點會終止現有對談。 | x | x | -| **4.5** | MSTG-AUTH-5 | 存在密碼方針，並在遠端端點強制實行。 | x | x | -| **4.6** | MSTG-AUTH-6 | 遠端端點實施了一個可以防止多次提交憑證的機制。 | x | x | -| **4.7** | MSTG-AUTH-7 | 在事先定義的不活動時段和用來訪問的token過期後，對談在遠端端點將無效。 | x | x | -| **4.8** | MSTG-AUTH-8 | 生物辨識認證（如果有的話）不受事件限制（即是像簡單地返回“真”或“假”的API）。 相反，它是基於解鎖鑰匙串/密鑰庫。 | | x | -| **4.9** | MSTG-AUTH-9 | 遠端端點存在第二個驗證要素，並且始終強制執行2FA準則。 | | x | -| **4.10** | MSTG-AUTH-10 | 敏感的交易需要進一步認證。 | | x | -| **4.11** | MSTG-AUTH-11 | 應用程式通過其帳戶通知用戶所有登錄活動。 用戶可以查看用於訪問帳戶的裝置列表（如實際位置，IP等），以及阻檔特定裝置。 | | x | -| **4.12** | MSTG-AUTH-12 | 驗證方式需在遠端端點定義並執行。 | x | x | - -## 參考 - -OWASP Mobile Application Security Testing Guide 提供了有關驗證本章節中列出的準則的詳細使用說明。 - -- In general - -- For Android - -- For iOS - - -更多資訊請參閱： - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document-zhtw/0x10-V5-Network_communication_requirements.md b/Document-zhtw/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index e21afb383..000000000 --- a/Document-zhtw/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,38 +0,0 @@ -# V5: 網路通訊規範 - -## 管理目標 - -本節中列出的管理目標是確保行動應用程式和遠端服務之間交換的訊息的機密性和完整性。確保行動應用程式必須使用 TLS 協議為網路傳輸作為安全加密的通道。L2 列出了其他加強防禦措施，例如 SSL 固定。 - -## 安全驗證要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | APP 網路傳輸資料均使用 TLS 協議作為加密協定. | x | x | -| **5.2** | MSTG-NETWORK-2 | TLS 協定使用，必須符合目前業界規範， 如已通報不安全的協定標準，須立即修正。 | x | x | -| **5.3** | MSTG-NETWORK-3 | 在與遠端建立資料傳輸通道時，須先驗證 X.509 證書，且只能接受有簽名受信任的 CA 憑證。 | x | x | -| **5.4** | MSTG-NETWORK-4 | 應用程式中公鑰和數位憑證來確保系統資訊安全， 並不能隨意與不明遠端建立連線，提供受信任 CA 憑證. | | x | -| **5.5** | MSTG-NETWORK-5 | 應用程式的相關重要操作，不可只依賴單一方式驗證 （如電子郵件或者 SMS) | | x | -| **5.6** | MSTG-NETWORK-6 | 應用程式需隨時更新連接方式以及資料庫安全性 | | x | - -## 參考 - -OWASP Mobile Application Security Testing Guide 提供了有關驗證本章節中列出的準則的詳細使用說明。 - -- Android - -- iOS - - -更多相關信息，另請參閱： - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document-zhtw/0x11-V6-Interaction_with_the_environment.md b/Document-zhtw/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 701e87890..000000000 --- a/Document-zhtw/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: 平台互動規範 - -## 控制目標 - -這個群組中的控制確保應用程式以安全的方式使用平台API和標準元件。 此外，控制還涵蓋應用程式（IPC）之間的通訊。 - -## 安全驗證要求 - -| # | MSTG-ID | 描述 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | 應用程式僅請求必要的最小權限集。 | x | x | -| **6.2** | MSTG-PLATFORM-2 | 來自外部來源和用戶的所有輸入都經過驗證，並在必要時進行消毒。 這包括通過UI，IPC機制像是意圖、自定義URL和網路來源接收的資料。 | x | x | -| **6.3** | MSTG-PLATFORM-3 | 除非適當保護這些機制，否則應用程式不會通過自定義URL結構輸出機密功能。 | x | x | -| **6.4** | MSTG-PLATFORM-4 | 除非適當保護這些機制，否則應用程序不會通過IPC設備輸出機密功能。 | x | x | -| **6.5** | MSTG-PLATFORM-5 | 除非明確地要求，否則在 WebView 中禁止使用 JavaScript。 | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebViews被設置為僅允許所需最少量協議處理程序（理想情況下，僅支援https）。 潛在危險的處理程序，例如f ile、tel 和 app-id 則不能使用。 | x | x | -| **6.7** | MSTG-PLATFORM-7 | 如果應用程式的 native 方法被暴露給 WebView，請驗證 WebView 是否僅提供應用程式套件中包含的JavaScript。 | x | x | -| **6.8** | MSTG-PLATFORM-8 | 如果有任何物件反序列化，要使用安全序列化 API 執行。 | x | x | -| **6.9** | MSTG-PLATFORM-9 | 行動應用程式需保護自己防衛螢幕覆蓋攻擊 (Screen Overlay Attack)。（僅針對 Android 系統）| | x | -| **6.10** | MSTG-PLATFORM-10 | WebView 的暫存，儲存，以及其他讀取的資源（如 JavaScript 等），需在 WebView 結束前全數清除。 | | x | -| **6.11** | MSTG-PLATFORM-11 | 確認當機敏資料被輸入前，並沒有使用任何其他廠商所製作的客製鍵盤應用程式。（僅針對 iOS 系統）| | x | - -## 參考 - -OWASP Mobile Application Security Testing Guide 提供了有關驗證本章節中列出的準則的詳細使用說明。 - -- Android - -- iOS - - -更多資訊請參閱： - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document-zhtw/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document-zhtw/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index fef668f6b..000000000 --- a/Document-zhtw/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: 程式碼品質與建立設定要求 - -## 控管目的 - -此控管目的是確保實作編碼時將遵照應用程式開發基本安全性，且基本(免費)安全性功能是藉由啟用編譯器所提供。 - -## 安全性驗證要求 - -| # | MSTG-ID | 說明 | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | 應用程式經由有效的憑證所提供所簽章，其私鑰是受到適當保護的 | x | x | -| **7.2** | MSTG-CODE-2 | 應用程式已在發佈模式建置，其設定適用於發佈版本(不可除錯的)| x | x | -| **7.3** | MSTG-CODE-3 | 除錯標記已從原生二元碼中移除 | x | x | -| **7.4** | MSTG-CODE-4 | 除錯程式碼已移除（如測試代碼，後門，隱藏設定等），應用程式將不紀錄詳細錯誤或偵錯訊息| x | x | -| **7.5** | MSTG-CODE-5 | 所有行動應用程式使用的第三方套件，如函式庫及框架，皆經識別及已知漏洞查驗 | x | x | -| **7.6** | MSTG-CODE-6 | 應用程式進行例外處理| x | x | -| **7.7** | MSTG-CODE-7 | 預設無法存取安全性控管的錯誤處理邏輯 | x | x | -| **7.8** | MSTG-CODE-8 | 在非託管程式碼，記憶體將被安全的被分配、釋出及使用 | x | x | -| **7.9** | MSTG-CODE-9 | 由Toolchain所提供的免費安全性功能將啟用，如簡化位元組碼(byte-code)、堆疊(Stack)保護、PIE支援、自動參考計數(Reference Counting)| x | x | - -## 參考資料 - -OWASP 行動應用安全性測試指南針對此章節所列出的認證要，提供詳細的說明 - -- Android - -- iOS - - -更多資訊，請參考： - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document-zhtw/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document-zhtw/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index c7071562d..000000000 --- a/Document-zhtw/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,68 +0,0 @@ -# V8: 彈性準則 - -## 控制目標 - -本節涵蓋對於存取機敏資料的功能的行動應用程序建議的縱身防禦措施。 -缺少任何這些控件不會導致漏洞 - 相反的，它們增加逆向工程及特定的用戶端攻擊對行動應用程式的彈性 - -基於對未經授權篡改應用程式和/或代碼逆向工程所導致的風險的評估，應根據需要應用本節中的控件。 -我們建議諮詢OWASP文件"逆向工程技術風險和未經授權的代碼修改逆向工程和代碼修改預防"(參考下面)列出的業務風險以及相關的技術威脅。 - -注意: 軟體保護絕不是使用在一個安全控制元件替換，MASVR-R中列出的控件旨在增加特定威脅，對滿足MASVS安全要求的應用程式，提供額外的保護控制 - -以下注意事項採用: - -1. 威脅模型必須明確概述用戶端抵擋的威脅。 此外，必須具體說明該方案旨在提供的保護等級。 例如，一個明確的目標可以強制使搜尋特定惡意軟體的作者對應用程式投入大量的手動逆向工程作業來實作。 - -2. 威脅模型必須是敏感的。 例如，如果攻擊者可以簡單地將整個白箱code lift，那麼將加密金鑰隱藏在白箱中就沒有意義。 - -3. 保護的有效性應始終由具有測試所使用的特定類型防篡改和混淆經驗的專家進行驗證（另請參閱 Mobile Application Security Testing Guide 中的“逆向工程”和“評估軟體保護”章節）。 - -### 阻礙動態分析和篡改 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | 應用程式通過提醒用戶或終止應用程式來檢測並回應超級用戶權限或越獄設備的存在。 | x | -| **8.2** | MSTG-RESILIENCE-2 | 應用程式防止和回應偵錯 和/或 檢測的偵錯器附加上去。 必須涵蓋所有可用的偵錯協議。 | x | -| **8.3** | MSTG-RESILIENCE-3 | 應用程式檢測和回應自己的沙箱中可執行的檔案和重要資料遭竄改。 | x | -| **8.4** | MSTG-RESILIENCE-4 | 應用程式檢測和回應設備上廣泛使用的逆向工程工具和架構的存在。 | x | -| **8.5** | MSTG-RESILIENCE-5 | 應用程式檢測並回應在模擬器中運行。 | x | -| **8.6** | MSTG-RESILIENCE-6 | 應用程式檢測並回應篡改其自己的記憶體空間中的程式碼和資料。 | x | -| **8.7** | MSTG-RESILIENCE-7 | 應用程式在各個防禦類別（8.1到8.6）中實施多種機制。 請注意，彈性隨著所用機制的數量，原創性的多樣性而變化。 | x | -| **8.8** | MSTG-RESILIENCE-8 | 檢測機制觸發不同類型的回應，包括延遲和暗中回應。 | x | -| **8.9** | MSTG-RESILIENCE-9 | 混淆應用於程序化防禦，這反過來通過動態分析阻止去除混淆。 | x | - -### 裝置綁定 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | 應用程式使用從裝置特有的多個特性 衍生的設備指紋實作“裝置綁定”功能。 | x | - -### 防止洩漏 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 | 屬於應用程式的所有可執行的檔案和函式庫都在文件級別上加密 和/或 可執行的檔案內的重要程式碼和資料片段被加密或打包。 瑣碎的靜態分析不會顯示重要的程式碼或資據。 | x | -| **8.12** | MSTG-RESILIENCE-12 | 考慮到當前發布的研究，如果混淆的目標是保護機密的計算，則使用混淆方案，該方案既適用於特定任務又良好的適用於手動和自動去混淆辦法。必須通過手動測試來驗證混淆方案的有效性。請注意，比起混淆，盡可能使用基於硬體的隔離功能。 | x | - -### 防止竊聽 - -| # | MSTG-ID | 描述 | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | 因應縱深防禦，除了需要與通訊對象有強度足夠的加密通訊架構，應用層也需要有足夠的加密機制去預防任何中間人竊聽的可能性產生。 | x | - -## 參考 - -OWASP Mobile Application Security Testing Guide 提供了有關驗證本章節中列出的準則的詳細使用說明。 - -- Android - -- iOS - - - - -更多資訊請參閱： - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- WASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document-zhtw/0x90-Appendix-A_Glossary.md b/Document-zhtw/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 55824116e..000000000 --- a/Document-zhtw/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# 附錄 A - 詞彙表 - -- **位址空間組態隨機載入(Address Space Layout Randomization, ASLR)** – 一種能讓利用記憶體損壞漏洞的攻擊更加困難的技術。 -- **應用程式安全(Application Security)** – 應用層安全性是針對 OSI 模型應用層元件的分析，而非針對作業系統或是網路連線。 -- **應用程式安全驗證(Application Security Verification)** – 對應用程式利用 OWASP MASVS 進行技術評鑑。 -- **應用程式安全驗證報告(Application Security Verification Report)** – 一份針對特定應用程式，由檢驗者製作，紀錄所有結果與相關分析的報告。 -- **身份驗證(Authentication)** – 對應用程式使用者鑒別身分的驗證。 -- **自動化驗證(Automated Verification)** – 採用自動化工具(包括動態分析工具、靜態分析工具或兩者皆採用)以利用弱點特徵來發掘問題。 -- **黑箱測試(Black box testing)** – 一種軟體測試方法，能在未知內部結構與運作情形的狀況下檢驗應用程式功能。 -- **元件(Component)** – 一個獨立的程式碼單元，具有與其他元件通訊的相關磁碟和網路介面. -- **跨站腳本(Cross-Site Scripting, XSS)** – 網路應用程式中常見的安全漏洞，允許將客戶端的腳本注入內容。 -- **密碼模組(Cryptographic module)** – 實作加密演算法和/或生成加密金鑰的硬體，軟體 和/或 韌體。 -- **共通弱點條目(CWE)** – CWE 是社群開發的常見軟體安全漏洞列表。它是一種通用語言，是軟體安全工具的衡量標準，也是弱點識別，緩解和預防工作的基準。 -- **動態應用程式安全測試(DAST)** – 動態應用程式安全性測試（DAST）技術旨在檢測標示處於運行狀態的應用程式中的安全漏洞。 -- **設計驗證(Design Verification)** – 應用程式安全架構的技術評估。 -- **動態驗證(Dynamic Verification)** – 運用自動化工具來在應用程式執行期間使用漏洞簽名尋找問題。 -- **全局唯一識別元(Globally Unique Identifier, GUID)** – 用作軟體識別的唯一標識。 -- **超文本傳輸協定(Hyper Text Transfer Protocol, HTTP)** – 用於分佈式、協作式和超媒體資訊系統的應用層協定。它是全球資訊網的資料通訊的基礎。 -- **硬編碼密鑰(Hardcoded keys)** – 儲存在裝置本身中的加密金鑰。 -- **行程間通訊(IPC)** – 行程間通訊（Inter-Process Communication)，在IPC，處理程序彼此通訊並與內核通訊以協調其活動 -- **輸入驗證(Input Validation)** – 不受信任用戶輸入的標準化和驗證。 -- **JAVA位元組碼(JAVA Bytecode)** – JAVA位元組碼是Java虛擬機器執行的一種指令格式。每個位元組碼由一個或有些時候兩個位元組組成，用來表示指令（opcode），以及用於傳遞參數的零個或多個位元組。 -- **惡意程式碼(Malicious Code)** – 程式碼在應用程式所有者不知情的情況下添加入應用程式，它繞過了應用程式預期的安全方針。與病毒或蠕蟲等惡意軟體不同！ -- **惡意軟體(Malware)** – 在應用程式使用者及管理員不知情的情況下，在運行期間添加入應用程式的可執行程式碼。 -- **開放網路應用程式安全計畫(Open Web Application Security Project, OWASP)** – 開放網路應用程式安全計畫（OWASP）是一個全球性的免費開放社群，致力於提高應用程式軟體的安全性。 我們的任務是使應用程式安全性“可見”，以便人們和機構能夠就應用程式安全風險做出明智的決策。參閱：http：//www.owasp.org/ -- **個人可識別資訊(Personally Identifiable Information, PII)** – 是可以單獨使用或與其他資訊一起使用的資訊，用於辨識、聯絡、定位單一人士，或在上下文中識別個人。 -- **地址無關可執行文件(PIE)** – Position-independent executable (PIE) 是指可在主存儲器中任意位置正確地運行，而不受其絕對地址影響的一種機器碼。 -- **公開金鑰基礎建設(PKI)** – PKI是一種將公開金鑰與實體的相應身份鏈結的協定。鏈結是通過數位憑證認證機構（CA）註冊和發布憑證的過程建立。 -- **靜態應用程式安全測試(SAST)** – Static application security testing (SAST) 是一組技術，旨在分析應用程式原始碼，位元組碼和二進制程式碼，用於程式碼編寫和指示安全漏洞的設計條件。SAST解決方案在非運行狀態下“由內而外”分析應用程式。 -- **系統發展生命週期(SDLC)** – 軟體開發生命週期。 -- **安全架構(Security Architecture)** – 應用程式設計的抽象概念，用於辨識和描述安全控制的使用位置和方式，還可以辨識和描述用戶和應用程式資料的位置和敏感性。 -- **安全配置(Security Configuration)** – 影響安全控制使用方式的應用程式運行時配置。 -- **安全控制措施(Security Control)** – 功能或元件執行安全檢查（例如，訪問控制檢查）或被呼叫時所導致的安全結果（例如，產生審查記錄）。 -- **SQL資料隱碼攻擊(SQL Injection, SQLi)** – 用於攻擊資料驅動的應用程式的程式碼注入技術，將惡意SQL語句插入 entry point。 -- **單一簽入身分驗證(SSO Authentication)** – Single Sign On(SSO)發生在當用戶登錄到一個客戶端然後自動登錄到其他客戶端時，無論用戶使用何種平台，技術或域。例如，當你在google登入時，您自動登入了YouTube，文檔和郵件服務。 -- **威脅模型分析(Threat Modeling)** – 一種由開發日益完善的安全架構，以識別威脅媒介，安全區域，安全控制以及重要的技術和業務資產所組成的技術。 -- **傳輸層安全性協定(Transport Layer Security, TLS)** – 提供覆蓋網際網路的通訊安全性的加密協定。 -- **統一資源識別符/統一資源定位符(URI/URL fragments)** – 統一資源識別符是用於標識名稱或網路資源的字元串。統一資源定位符常常用作資源的引用。 -- **用戶驗收測試(User acceptance testing, UAT)** – 傳統上，測試環境的行為類似於在上線之前執行所有軟體測試的生產環境。 -- **驗證員(Verifier)** – 正在根據OWASP ASVS要求審核應用程式的人員或團隊。 -- **白名單(Whitelist)** – 允許資料或操作的列表，例如允許執行輸入驗證的字元列表。 -- **X.509憑證(X.509 Certificate)** – X.509憑證是一種數位憑證，它使用廣泛接受的國際X.509公開金鑰基礎建設（PKI）標準來驗證公開金鑰是否屬於憑證中包含的用戶，電腦或服務。 diff --git a/Document-zhtw/0x91-Appendix-B_References.md b/Document-zhtw/0x91-Appendix-B_References.md deleted file mode 100644 index 6e30d5535..000000000 --- a/Document-zhtw/0x91-Appendix-B_References.md +++ /dev/null @@ -1,16 +0,0 @@ -# 附錄B: 參考資料 - -以下專案內容將幫助使用者/適用者更了解這個標準 - -- OWASP 行動應用安全性專案 - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP 行動應用安全測試指南 -[https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP 行動應用 Top 10 風險 - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP 逆向工程及程式碼編修防護 -[https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -- 相同的，以下網站將幫助使用者/適用者更了解這個標準 -- MITRE 常見弱點列舉 - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI 安全性標準委員會 - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI 資料安全性標準(DSS)要求和安全評估程序 第三版- [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document-zhtw/CHANGELOG.md b/Document-zhtw/CHANGELOG.md deleted file mode 100644 index b6da76d72..000000000 --- a/Document-zhtw/CHANGELOG.md +++ /dev/null @@ -1,99 +0,0 @@ -# 修改日誌 - -## 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](https://github.com/dalibo/pandocker) and [Github Actions](https://github.com/OWASP/owasp-masvs/tree/master/.github/workflows). -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 excellent translation work. - -## V1.2 - 2020年3月7日-國際發行 - -The following changes are part of release 1.2: - -- Translation in simplified Chinese of the MASVS available. -- Change of title in MASVS book cover. -- Removed Mobile Top 10 and CWE from MSTG and merged to existing references in MASVS. - -## V1.2-RC - 2019年10月5号 - 预发行版 (仅限英语) - -以下为1.2-RC版本所包含的更新内容： - -晋升为同类安全指南最成功的作品。 - -- 更改要求 MSTG-STORAGE-1 "需要被使用"（need to be used）。 -- 增加侧重于数据保护的要求 MSTG-STORAGE-13， MSTG-STORAGE-14， 和 MSTG-STORAGE-15。 -- 更新要求MSTG-AUTH-11，以保护上下文信息（contextual information）。 -- 更新要求MSTG-CODE-4，以涵盖更多信息而不仅仅是排错调试（debugging）。 -- 添加要求MSTG-PLATFORM-10，以进一步安全的使用WebViews。 -- 添加要求MSTG-AUTH-12，以提醒开发人员部署授权，特别是在多用户应用程序（multi-user apps）的情况下。 -- 在怎样使用MASVS进行风险评估中添加了一点描述。 -- 在付费内容（paid content）中添加了一点描述。 -- 增加要求MSTG-ARCH-11，以包含针对L2应用程序的 责任披露政策（Responsible Disclosure policy）。 -- 增加要求MSTG-ARCH-12，以向应用程序开发人员展示他们应遵守的相关的国际隐私法律。 -- 为英文版的引用（references）创建了一个固定的格式。 -- 添加要求MSTG-PLATFORM-11，以反击通过第三方键盘进行的间谍活动（spying）。 -- 添加要求MSTG-MSTG-RESILIENCE-13，以阻止在应用程序中的窃听。 - -## V1.1.4 - 2019年7月4日 - 高峰會版本 - -以下為 1.1.4 版本內所包含的修正資料: - -- 修正所有輕量級標記語言問題。 -- 更新法文及西班牙文翻譯版。 -- 完成繁體中文及日文版本的修改日誌翻譯。 -- 將輕量級標記語言句法進行自動化確認並確定所有網址皆可連線。 -- 新增標記代碼到各項需求，以利於未來在 MSTG 當中可以快速及方便的找到相關建議及測試方案。 -- 縮減倉儲大小，新增 Generated 到 .gitignore。 -- 新增行為守則及共做規則。 -- 新增拉取要求(Pull Request)模版。 -- 更新與 Gitbook 網頁同步倉儲的功能。 -- 更新所有翻譯版本產出 XML/JSON/CSV 的執行腳本。 -- 完成繁體中文版本前言部分翻譯。 - -## V1.1.3版 - 2019年1月9日 小幅度修正 - -以下為 1.1.3 版本內所包含的修正資料: - -- 修正需求 7.1 內的西班牙文翻譯。 -- 於致謝區重新安排翻譯者名字。 -- 日文版小幅度修正。 - -## V1.1.2 - 2019年1月3日 贊助者與國際翻譯版本 - -以下為 1.1.2 版本內所包含的修正資料: - -- 新增感謝函給予購買電子書版本的使用者。 -- 在V4中添加了丟失的身份驗證連接和更新損壞的身份驗證。 -- 修正英文版當中 4.7 與 4.8 的互換。 -- 第一次的國際翻譯版本! - - 修正西班牙文翻譯。翻譯目前已與英文版同步（1.1.2)。 - - 修正俄羅斯文翻譯。翻譯目前已與英文版同步（1.1.2)。 - - 新增第一版繁體中文，法文，德文，以及日文翻譯版本！ -- 簡化文件格式方便後續翻譯工作。 -- 新增自動化發佈的方式。 - -## V1.1.0 - 2018年7月14日 - -以下為 1.1 版本內所包含的修正資料: - -- 移除需求 2.6 "在可能包含敏感資料的文字欄位上停用剪貼板"。 -- 新增需求 2.2 "任何敏感資料不可被儲存在應用程式容器之外或其他系統層的敏感資料儲存系統"。 -- 重新修改用詞於需求 2.1 改為 "系統層的敏感資料儲存系統可適當的用於儲存敏感資料，例如個人資料，使用者資料，或是加密金鑰"。 - -## V1.0 - 2018年1月12日 - -以下為 1.0 版本內所包含的修正資料: - -- 因需求 8.12 與需求 8.9 相同，刪除 8.9。 -- 將需求 4.6 修改為較廣義定義。 -- 其他小幅度修改 (錯字或文法等) diff --git a/Document-zhtw/GLOSSARY.md b/Document-zhtw/GLOSSARY.md deleted file mode 100644 index a52240f1f..000000000 --- a/Document-zhtw/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# 附錄 A - 詞彙表 - -## 位址空間組態隨機載入(Address Space Layout Randomization, ASLR) - -一種能讓利用記憶體損壞漏洞的攻擊更加困難的技術。 - -## 應用程式安全(Application Security) - -應用層安全性是針對 OSI 模型應用層元件的分析，而非針對作業系統或是網路連線。 - -## 應用程式安全驗證(Application Security Verification) - -對應用程式利用 OWASP MASVS 進行技術評鑑。 - -## 應用程式安全驗證報告(Application Security Verification Report) - -一份針對特定應用程式，由檢驗者製作，紀錄所有結果與相關分析的報告。 - -## 身份驗證(Authentication) - -對應用程式使用者鑒別身分的驗證。 - -## 自動化驗證(Automated Verification) - -採用自動化工具(包括動態分析工具、靜態分析工具或兩者皆採用)以利用弱點特徵來發掘問題。 - -## 黑箱測試(Black box testing) - -一種軟體測試方法，能在未知內部結構與運作情形的狀況下檢驗應用程式功能。 - -## 元件(Component) - -一個獨立的程式碼單元，具有與其他元件通訊的相關磁碟和網路介面. - -## 跨站腳本(Cross-Site Scripting, XSS) - -網路應用程式中常見的安全漏洞，允許將客戶端的腳本注入內容。 - -## 密碼模組(Cryptographic module) - -實作加密演算法和/或生成加密金鑰的硬體，軟體 和/或 韌體。 - -## 共通弱點條目(CWE) - -CWE 是社群開發的常見軟體安全漏洞列表。它是一種通用語言，是軟體安全工具的衡量標準，也是弱點識別，緩解和預防工作的基準。 - -## 動態應用程式安全測試(DAST) - -動態應用程式安全性測試（DAST）技術旨在檢測標示處於運行狀態的應用程式中的安全漏洞。 - -## 設計驗證(Design Verification) - -應用程式安全架構的技術評估。 - -## 動態驗證(Dynamic Verification) - -運用自動化工具來在應用程式執行期間使用漏洞簽名尋找問題。 - -## 全局唯一識別元(Globally Unique Identifier, GUID) - -用作軟體識別的唯一標識。 - -## 超文本傳輸協定(Hyper Text Transfer Protocol, HTTP) - -用於分佈式、協作式和超媒體資訊系統的應用層協定。它是全球資訊網的資料通訊的基礎。 - -## 硬編碼密鑰(Hardcoded keys) - -儲存在裝置本身中的加密金鑰。 - -## 行程間通訊(IPC) - -行程間通訊（Inter-Process Communication)，在IPC，處理程序彼此通訊並與內核通訊以協調其活動 - -## 輸入驗證(Input Validation) - -不受信任用戶輸入的標準化和驗證。 - -## JAVA位元組碼(JAVA Bytecode) - -JAVA位元組碼是Java虛擬機器執行的一種指令格式。每個位元組碼由一個或有些時候兩個位元組組成，用來表示指令（opcode），以及用於傳遞參數的零個或多個位元組。 - -## 惡意程式碼(Malicious Code) - -程式碼在應用程式所有者不知情的情況下添加入應用程式，它繞過了應用程式預期的安全方針。與病毒或蠕蟲等惡意軟體不同！ - -## 惡意軟體(Malware) - -在應用程式使用者及管理員不知情的情況下，在運行期間添加入應用程式的可執行程式碼。 - -## 開放網路應用程式安全計畫(Open Web Application Security Project, OWASP) - -開放網路應用程式安全計畫（OWASP）是一個全球性的免費開放社群，致力於提高應用程式軟體的安全性。 我們的任務是使應用程式安全性“可見”，以便人們和機構能夠就應用程式安全風險做出明智的決策。參閱：http：//www.owasp.org/ - -## 個人可識別資訊(Personally Identifiable Information, PII) - -是可以單獨使用或與其他資訊一起使用的資訊，用於辨識、聯絡、定位單一人士，或在上下文中識別個人。 - -## 地址無關可執行文件(PIE) - -Position-independent executable (PIE) 是指可在主存儲器中任意位置正確地運行，而不受其絕對地址影響的一種機器碼。 - -## 公開金鑰基礎建設(PKI) - -PKI是一種將公開金鑰與實體的相應身份鏈結的協定。鏈結是通過數位憑證認證機構（CA）註冊和發布憑證的過程建立。 - -## 靜態應用程式安全測試(SAST) - -Static application security testing (SAST) 是一組技術，旨在分析應用程式原始碼，位元組碼和二進制程式碼，用於程式碼編寫和指示安全漏洞的設計條件。SAST解決方案在非運行狀態下“由內而外”分析應用程式。 - -## 系統發展生命週期(SDLC) - -軟體開發生命週期。 - -## 安全架構(Security Architecture) - -應用程式設計的抽象概念，用於辨識和描述安全控制的使用位置和方式，還可以辨識和描述用戶和應用程式資料的位置和敏感性。 - -## 安全配置(Security Configuration) - -影響安全控制使用方式的應用程式運行時配置。 - -## 安全控制措施(Security Control) - -功能或元件執行安全檢查（例如，訪問控制檢查）或被呼叫時所導致的安全結果（例如，產生審查記錄）。 - -## SQL資料隱碼攻擊(SQL Injection, SQLi) - -用於攻擊資料驅動的應用程式的程式碼注入技術，將惡意SQL語句插入 entry point。 - -## 單一簽入身分驗證(SSO Authentication) - -Single Sign On(SSO)發生在當用戶登錄到一個客戶端然後自動登錄到其他客戶端時，無論用戶使用何種平台，技術或域。例如，當你在google登入時，您自動登入了YouTube，文檔和郵件服務。 - -## 威脅模型分析(Threat Modeling) - -一種由開發日益完善的安全架構，以識別威脅媒介，安全區域，安全控制以及重要的技術和業務資產所組成的技術。 - -## 傳輸層安全性協定(Transport Layer Security, TLS) - -提供覆蓋網際網路的通訊安全性的加密協定。 - -## 統一資源識別符/統一資源定位符(URI/URL fragments) - -統一資源識別符是用於標識名稱或網路資源的字元串。統一資源定位符常常用作資源的引用。 - -## 用戶驗收測試(User acceptance testing, UAT) - -傳統上，測試環境的行為類似於在上線之前執行所有軟體測試的生產環境。 - -## 驗證員(Verifier) - -正在根據OWASP ASVS要求審核應用程式的人員或團隊。 - -## 白名單(Whitelist) - -允許資料或操作的列表，例如允許執行輸入驗證的字元列表。 - -## X.509憑證(X.509 Certificate) - -X.509憑證是一種數位憑證，它使用廣泛接受的國際X.509公開金鑰基礎建設（PKI）標準來驗證公開金鑰是否屬於憑證中包含的用戶，電腦或服務。 diff --git a/Document-zhtw/SUMMARY.md b/Document-zhtw/SUMMARY.md deleted file mode 100644 index a07de76e4..000000000 --- a/Document-zhtw/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# 目錄 - -- [前言](0x01-Foreword.md) -- [Changelog](CHANGELOG.md) -- [卷首](0x02-Frontispiece.md) -- [使用 MASVS](0x03-Using_the_MASVS.md) -- [評估與認證](0x04-Assessment_and_Certification.md) - -## 安全要求 - -- [V1: 架構、設計和威脅模型分析準則](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: 資料存儲和隱私要求](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: 加密要求](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: 身份驗證和對談管理準則](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: 網路通訊規範](0x10-V5-Network_communication_requirements.md) -- [V6: 平台互動要求](0x11-V6-Interaction_with_the_environment.md) -- [V7: 程式碼品質和與建立設定要求](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: 彈性要求](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## 附錄 - -- [附錄 A - 詞彙表](GLOSSARY.md) -- [附錄 B - 參考資料](0x91-Appendix-B_References.md) diff --git a/Document-zhtw/book.json b/Document-zhtw/book.json deleted file mode 100644 index eeb5a62d7..000000000 --- a/Document-zhtw/book.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "root" : ".", - - "structure": { - "readme": "0x01-Foreword.md" - }, - - "language": "zhtw" -} diff --git a/Document-zhtw/images/CC-license.png b/Document-zhtw/images/CC-license.png deleted file mode 100644 index b20d04de9..000000000 Binary files a/Document-zhtw/images/CC-license.png and /dev/null differ diff --git a/Document-zhtw/images/MASVS-levels.png b/Document-zhtw/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document-zhtw/images/MASVS-levels.png and /dev/null differ diff --git a/Document-zhtw/images/OWASP_logo.png b/Document-zhtw/images/OWASP_logo.png deleted file mode 100644 index ca9268c9b..000000000 Binary files a/Document-zhtw/images/OWASP_logo.png and /dev/null differ diff --git a/Document-zhtw/images/license.png b/Document-zhtw/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document-zhtw/images/license.png and /dev/null differ diff --git a/Document-zhtw/images/masvs-cover-1.1.xcf b/Document-zhtw/images/masvs-cover-1.1.xcf deleted file mode 100644 index 7e4ddd1e0..000000000 Binary files a/Document-zhtw/images/masvs-cover-1.1.xcf and /dev/null differ diff --git a/Document-zhtw/images/masvs-levels-new.jpg b/Document-zhtw/images/masvs-levels-new.jpg deleted file mode 100644 index 60e423a4e..000000000 Binary files a/Document-zhtw/images/masvs-levels-new.jpg and /dev/null differ diff --git a/Document-zhtw/images/masvs-mini-cover.jpg b/Document-zhtw/images/masvs-mini-cover.jpg deleted file mode 100644 index bae43fdf8..000000000 Binary files a/Document-zhtw/images/masvs-mini-cover.jpg and /dev/null differ diff --git a/Document-zhtw/images/masvs-mini-cover.png b/Document-zhtw/images/masvs-mini-cover.png deleted file mode 100644 index 15d07d0c2..000000000 Binary files a/Document-zhtw/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document-zhtw/metadata.md b/Document-zhtw/metadata.md deleted file mode 100644 index 362fa0f31..000000000 --- a/Document-zhtw/metadata.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -# This overide the main Document/metadata.md file -#lang: 'zhtw' # bug in polyglossia, switch back to english -languagetext: '(Traditional Chinese Translation)' - -# toc-title is translated when `lang` is correctly defined -toc-title: '目录' - -mainfont: 'Noto Sans' -sansfont: 'Noto Sans' -monofont: 'Noto Sans Mono' -CJKmainfont: 'Noto Sans CJK TC' - ---- diff --git a/Document/0x01-Foreword.md b/Document/01-Foreword.md similarity index 73% rename from Document/0x01-Foreword.md rename to Document/01-Foreword.md index 5beeb0789..316779423 100644 --- a/Document/0x01-Foreword.md +++ b/Document/01-Foreword.md @@ -2,19 +2,19 @@ Technological revolutions can happen quickly. Less than a decade ago, smartphones were clunky devices with little keyboards - expensive playthings for tech-savvy business users. Today, smartphones are an essential part of our lives. We've come to rely on them for information, navigation and communication, and they are ubiquitous both in business and in our social lives. -Every new technology introduces new security risks, and keeping up with those changes is one of the main challenges the security industry faces. The defensive side is always a few steps behind. For example, the default reflex for many was to apply old ways of doing things: Smartphones are like small computers, and mobile apps are just like classic software, so surely the security requirements are similar? But it doesn't work like that. Smartphone operating systems are different from Desktop operating systems, and mobile apps are different from web apps. For example, the classical method of signature-based virus scanning doesn't make sense in modern mobile OS environments: Not only is it incompatible with the mobile app distribution model, it's also technically impossible due to sandboxing restrictions. Also, some vulnerability classes, such as buffer overflows and XSS issues, are less relevant in the context of run-of-the-mill mobile apps than in, say, Desktop apps and web applications (exceptions apply). +Every new technology introduces new security risks, and keeping up with those changes is one of the main challenges the security industry faces. The defensive side is always a few steps behind. For example, the default reflex for many was to apply old ways of doing things: Smartphones are like small computers, and mobile apps are just like classic software, so surely the security requirements are similar? But it doesn't work like that. Smartphone operating systems are different from desktop operating systems, and mobile apps are different from web apps. For example, the classical method of signature-based virus scanning doesn't make sense in modern mobile OS environments: Not only is it incompatible with the mobile app distribution model, it's also technically impossible due to sandboxing restrictions. Also, some vulnerability classes, such as buffer overflows and XSS issues, are less relevant in the context of run-of-the-mill mobile apps than in, say, desktop apps and web applications (exceptions apply). Over time, our industry has gotten a better grip on the mobile threat landscape. As it turns out, mobile security is all about data protection: Apps store our personal information, pictures, recordings, notes, account data, business information, location and much more. They act as clients that connect us to services we use on a daily basis, and as communications hubs that processes each and every message we exchange with others. Compromise a person's smartphone and you get unfiltered access to that person's life. When we consider that mobile devices are more readily lost or stolen and mobile malware is on the rise, the need for data protection becomes even more apparent. -A security standard for mobile apps must therefore focus on how mobile apps handle, store and protect sensitive information. Even though modern mobile operating systems like iOS and Android offer good APIs for secure data storage and communication, those have to be implemented and used correctly in order to be effective. Data storage, inter-app communication, proper usage of cryptographic APIs and secure network communication are only some of the aspects that require careful consideration. +A security standard for mobile apps must therefore focus on how mobile apps handle, store and protect sensitive information. Even though modern mobile operating systems like iOS and Android offer mature APIs for secure data storage and communication, those have to be implemented and used correctly in order to be effective. Data storage, inter-app communication, proper usage of cryptographic APIs and secure network communication are only some of the aspects that require careful consideration. -An important question in need of industry consensus is how far exactly one should go in protecting the confidentiality and integrity of data. For example, most of us would agree that a mobile app should verify the server certificate in a TLS exchange. But what about SSL certificate pinning? Does not doing it result in a vulnerability? Should this be a requirement if an app handles sensitive data, or is it maybe even counter-productive? Do we need to encrypt data stored in SQLite databases, even though the OS sandboxes the app? What is appropriate for one app might be unrealistic for another. The MASVS is an attempt to standardize these requirements using verification levels that fit different threat scenarios. +An important question in need of industry consensus is how far exactly one should go in protecting the confidentiality and integrity of data. For example, most of us would agree that a mobile app should verify the server certificate in a TLS exchange. But what about certificate or public key pinning? Does not doing it result in a vulnerability? Should this be a requirement if an app handles sensitive data, or is it maybe even counter-productive? Do we need to encrypt data stored in SQLite databases, even though the OS sandboxes the app? What is appropriate for one app might be unrealistic for another. The MASVS is an attempt to standardize these requirements using profiles that fit different threat scenarios. -Furthermore, the appearance of root malware and remote administration tools has created awareness of the fact that mobile operating systems themselves have exploitable flaws, so containerization strategies are increasingly used to afford additional protection to sensitive data and prevent client-side tampering. This is where things get complicated. Hardware- backed security features and OS-level containerization solutions, such as Android for Work and Samsung Knox, do exist, but they aren't consistently available across different devices. As a band aid, it is possible to implement software-based protection measures - but unfortunately, there are no standards or testing processes for verifying these kinds of protections. +Furthermore, the appearance of root malware and remote administration tools has created awareness of the fact that mobile operating systems themselves have exploitable flaws, so containerization strategies are increasingly used to afford additional protection to sensitive data and prevent client-side tampering. This is where things get complicated. Hardware- backed security features and OS-level containerization solutions, such as Android Enterprise and Samsung Knox, do exist, but they aren't consistently available across different devices. As a band aid, it is possible to implement software-based protection measures - but unfortunately, there are no standards or testing processes for verifying these kinds of protections. -As a result, mobile app security testing reports are all over the place: For example, some testers report a lack of obfuscation or root detection in an Android app as “security flaw”. On the other hand, measures like string encryption, debugger detection or control flow obfuscation aren't considered mandatory. However, this binary way of looking at things doesn't make sense because resiliency is not a binary proposition: It depends on the particular client-side threats one aims to defend against. Software protections are not useless, but they can ultimately be bypassed, so they must never be used as a replacement for security controls. +As a result, mobile app security testing reports are all over the place: For example, some testers report a lack of obfuscation or root detection in an Android app as “security flaw”. On the other hand, measures like string encryption, debugger detection or control flow obfuscation aren't considered mandatory. However, this binary way of looking at things doesn't make sense because resilience is not a binary proposition: It depends on the particular client-side threats one aims to defend against. Software protections are not useless, but they can ultimately be bypassed, so they must never be used as a replacement for security controls. -The overall goal of the MASVS is to offer a baseline for mobile application security (MASVS- L1), while also allowing for the inclusion of defense-in-depth measures (MASVS-L2) and protections against client-side threats (MASVS-R). The MASVS is meant to achieve the following: +The overall goal of the MASVS is to offer a baseline for mobile application security, while also allowing for the inclusion of defense-in-depth measures and protections against client-side threats. The MASVS is meant to achieve the following: - Provide requirements for software architects and developers seeking to develop secure mobile applications; - Offer an industry standard that can be tested against in mobile app security reviews; diff --git a/Document/02-Frontispiece.md b/Document/02-Frontispiece.md new file mode 100644 index 000000000..3acb37784 --- /dev/null +++ b/Document/02-Frontispiece.md @@ -0,0 +1,67 @@ +# About the Standard + + + +The OWASP Mobile Application Security Verification Standard (MASVS) is the industry standard for mobile application security. It provides a comprehensive set of security controls that can be used to assess the security of mobile apps across various platforms (e.g., Android, iOS) and deployment scenarios (e.g., consumer, enterprise). The standard covers the key components of the mobile app attack surface including storage, cryptography, authentication and authorization, network communication, interaction with the mobile platform, code quality and resilience against reverse engineering and tampering. + +The OWASP MASVS is the result of years of community effort and industry feedback. We thank all the contributors who have helped shape this standard. We welcome your feedback on the OWASP MASVS at any time, especially as you apply it to your own organization and mobile app development projects. Getting inputs from a variety of mobile app developers will help us improve and update the standard which is revised periodically based on your inputs and feedback. + +You can provide feedback using GitHub Discussions in the OWASP MASVS repo , or contact the project leads directly . + +The OWASP MASVS and MASTG are trusted by the following platform providers and standardization, governmental and educational institutions. [Learn more](https://mas.owasp.org/MASTG/Intro/0x02b-MASVS-MASTG-Adoption/). + + + + + + + +## Authors + +### Sven Schleier + +Sven is specialised in penetration testing and application security and has guided numerous projects to build security in from the start. He strongly believes in knowledge sharing and is speaking worldwide at meetups and conferences, is an adjunct professor and is conducting hands-on workshops about mobile app security to penetration testers, developers and students. + +### Carlos Holguera + +Carlos is a mobile security research engineer with many years of hands-on experience in security testing for mobile apps and embedded systems such as automotive control units and IoT devices. He is passionate about reverse engineering and dynamic instrumentation of mobile apps and is continuously learning and sharing his knowledge. + +### Jeroen Beckers + +Jeroen is a mobile security lead responsible for quality assurance on mobile security projects and for R&D on all things mobile. Ever since his master's thesis on Android security, Jeroen has been interested in mobile devices and their (in)security. He loves sharing his knowledge with other people, as is demonstrated by his many talks & trainings at colleges, universities, clients and conferences. + +### Bernhard Mueller + +Bernhard is a cyber security specialist with a talent for hacking systems of all kinds. During more than a decade in the industry, he has published many zero-day exploits for software. BlackHat USA commended his pioneering work in mobile security with a Pwnie Award for Best Research. + +### Jeroen Willemsen + +Jeroen is a principal security architect with a passion for mobile security and risk management. He has supported companies as a security coach, a security engineer and as a full-stack developer. He loves explaining technical subjects: from security issues to programming challenges. + + + +## Contributors + +All of our contributors are listed in the Contributing section of the OWASP MAS website: + + + +## Donators + +While both the MASVS and the MASTG are created and maintained by the community on a voluntary basis, sometimes outside help is required. We therefore thank our donators for providing the funds to be able to hire technical editors. Note that their donation does not influence the content of the MASVS or MASTG in any way. The Donation Packages are described on the [OWASP MAS Website](https://mas.owasp.org/donate/packages/). + + + + + +## Changelog + +All our Changelogs are available online at the OWASP MASVS GitHub repository, see the Releases page: + + + +## Copyright and License + +Copyright © 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/ "Creative Commons Attribution-ShareAlike 4.0 International License"). For any reuse or distribution, you must make clear to others the license terms of this work. + + diff --git a/Document/03-Using_the_MASVS.md b/Document/03-Using_the_MASVS.md new file mode 100644 index 000000000..747fff4e0 --- /dev/null +++ b/Document/03-Using_the_MASVS.md @@ -0,0 +1,91 @@ +# The Mobile Application Security Verification Standard + +The Mobile Application Security Verification Standard (MASVS) is a comprehensive security standard developed by the Open Worldwide Application Security Project (OWASP). This framework provides a clear and concise set of guidelines and best practices for assessing and enhancing the security of mobile applications. The MASVS is designed to be used as a metric, guidance, and baseline for mobile app security verification, serving as a valuable resource for developers, application owners, and security professionals. + +The objective of the MASVS is to establish a high level of confidence in the security of mobile apps by providing a set of controls that address the most common mobile application security issues. These controls were developed with a focus on providing guidance during all phases of mobile app development and testing, and to be used as a baseline for mobile app security verification during procurement. + +By adhering to the controls outlined in the OWASP MASVS, organizations can ensure that their mobile applications are built with security in mind, reducing the risk of security breaches and protecting sensitive user data. Whether used as a metric, guidance, or baseline, the OWASP MASVS is an invaluable tool for enhancing the security of mobile applications. + +The OWASP MASVS is a living document and is regularly updated to reflect the changing threat landscape and new attack vectors. As such, it's important to [stay up-to-date](https://mas.owasp.org/MASVS/) with the latest version of the standard and adapt security measures accordingly. + +## Mobile Application Security Model + +The standard is divided into various groups that represent the most critical areas of the mobile attack surface. These control groups, labeled **MASVS-XXXXX**, provide guidance and standards for the following areas: + +- **MASVS-STORAGE:** Secure storage of sensitive data on a device (data-at-rest). +- **MASVS-CRYPTO:** Cryptographic functionality used to protect sensitive data. +- **MASVS-AUTH:** Authentication and authorization mechanisms used by the mobile app. +- **MASVS-NETWORK:** Secure network communication between the mobile app and remote endpoints (data-in-transit). +- **MASVS-PLATFORM:** Secure interaction with the underlying mobile platform and other installed apps. +- **MASVS-CODE:** Security best practices for data processing and keeping the app up-to-date. +- **MASVS-RESILIENCE:** Resilience to reverse engineering and tampering attempts. + +Each of these control groups contains individual controls labeled **MASVS-XXXXX-Y**, which provide specific guidance on the particular security measures that need to be implemented to meet the standard. + +## Mobile Application Security Profiles + +The MAS project has traditionally provided three verification levels (L1, L2 and R), which were revisited during the MASVS refactoring in 2023, and have been reworked as "security testing profiles" and moved over to the OWASP MASTG. These profiles are now aligned with the [NIST OSCAL (Open Security Controls Assessment Language)](https://pages.nist.gov/OSCAL/) standard, which is a comprehensive catalog of security controls that can be used to secure information systems. + +By aligning with OSCAL, the MASVS provides a more flexible and comprehensive approach to security testing. OSCAL provides a standard format for security control information, which allows for easier sharing and reuse of security controls across different systems and organizations. This allows for a more efficient use of resources and a more targeted approach to mobile app security testing. + +However, it is important to note that implementing these profiles fully or partially should be a risk-based decision made in consultation with business owners. The profiles should be tailored to the specific security risks and requirements of the mobile application being developed, and any deviations from the recommended controls should be carefully justified and documented. + +## Assumptions + +When using the MASVS, it's important to keep in mind the following assumptions: + +- The MASVS is not a substitute for following secure development best practices, such as secure coding or secure SDLC. These practices should be followed holistically in your development process and the MASVS complements them specifically for mobile apps. +- The MASVS assumes that you've followed the relevant standards of your industry and country for all elements of your app's ecosystem, such as backend servers, IoT, and other companion devices. +- The MASVS is designed to evaluate the security of mobile apps that can be analyzed statically by obtaining the app package, dynamically by running it on a potentially compromised device, and also considers any network-based attacks such as MITM. + +While the OWASP MASVS is an invaluable tool for enhancing the security of mobile applications, it cannot guarantee absolute security. It should be used as a baseline for security requirements, but additional security measures should also be implemented as appropriate to address specific risks and threats to the mobile app. + +### Security Architecture, Design and Threat Modeling for Mobile Apps + +> The OWASP MASVS assumes that best practices for secure architecture, design, and threat modeling have been followed as a foundation. + +Security must be a top priority throughout all stages of mobile app development, from the initial planning and design phase to deployment and ongoing maintenance. Developers need to follow secure development best practices and ensure that security measures are prioritized to protect sensitive data, comply with policies and regulations, and identify and address security issues that can be targeted by attackers. + +While the MASVS and MASTG focuses on controls and technical test cases for app security assessments, non-technical aspects such as following best practices laid out by [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/model/) or [NIST.SP.800-218 Secure Software Development Framework (SSDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) for secure architecture, design, and threat modeling are still important. The MASVS can also be used as reference and input for a threat model to raise awareness of potential attacks. + +To ensure that these practices are followed, developers can provide documentation or evidence of adherence to these standards, such as design documents, threat models, and security architecture diagrams. Additionally, interviews can be conducted to collect information on adherence to these practices and provide an understanding of the level of compliance with these standards. + +### Secure App Ecosystem + +> The OWASP MASVS assumes other relevant security standards are also leveraged to ensure that all systems involved in the app's operation meet their applicable requirements. + +Mobile apps often interact with multiple systems, including backend servers, third-party APIs, Bluetooth devices, cars, IoT devices, and more. Each of these systems may introduce their own security risks that must be considered as part of the mobile app's security design and threat modeling. For example, when interacting with a backend server, the [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) should be used to ensure that the server is secure and meets the required security standards. In the case of Bluetooth devices, the app should be designed to prevent unauthorized access, while for cars, the app should be designed to protect the user's data and ensure that there are no safety issues with the car's operation. + +### Security Knowledge and Expertise + +> The OWASP MASVS assumes a certain level of security knowledge and expertise among developers and security professionals using the standard. It's important to have a good understanding of mobile app security concepts, as well as the relevant tools and techniques used for mobile app security testing and assessment. To support this, the OWASP MAS project also provides the [OWASP Mobile Application Security Testing Guide (MASTG)](https://mas.owasp.org/MASTG/), which provides in-depth guidance on mobile app security testing and assessment. + +Mobile app development is a rapidly evolving field, with new technologies, programming languages, and frameworks constantly emerging. It's essential for developers and security professionals to stay current with these developments, as well as to have a solid foundation in fundamental security principles. + +OWASP SAMM provides a dedicated ["Education & Guidance"](https://owaspsamm.org/model/governance/education-and-guidance/) domain which aims to ensure that all stakeholders involved in the software development lifecycle are aware of the software security risks and are equipped with the knowledge and skills to mitigate these risks. This includes developers, testers, architects, project managers, executives, and other personnel involved in software development and deployment. + +## Applicability of the MASVS + +By adhering to the MASVS, businesses and developers can ensure that their mobile app are secure and meet industry-standard security requirements, regardless of the development approach used. This is the case for downloadable apps, as the project was traditionally focused on, but the MAS resources and guidelines are also applicable to other areas of the business such as preloaded applications and SDKs. + +### Native Apps + +Native apps are written in platform-specific languages, such as Java/Kotlin for Android or Objective-C/Swift for iOS. + +### Cross-Platform and Hybrid Apps + +Apps based on cross-platform (Flutter, React Native, Xamarin, Ionic, etc.) and hybrid (Cordova, PhoneGap, Framework7, Onsen UI, etc.) frameworks may be susceptible to platform-specific vulnerabilities that don't exist in native apps. For example, some JavaScript frameworks may introduce new security issues that don't exist in other programming languages. It is therefore essential to follow the security best practices of the used frameworks. + +The MASVS is agnostic to the type of mobile application being developed. This means that the guidelines and best practices outlined in the MASVS can be applied to all types of mobile apps, including cross-platform and hybrid apps. + +### Preloads + +Preloaded apps are apps that are installed on a user's device at factory time and may have elevated privileges that leave users vulnerable to exploitative business practices. Given the large number of preloaded apps on an average user's device, it's important to measure their risk in a quantifiable way. + +There are hundreds of preloads that may ship on a device, and as a result, automation is critical. A subset of MAS criteria that is automation-friendly may be a good basis. + +### SDKs + +SDKs play a vital role in the mobile app value chain, supplying code developers need to build faster, smarter, and more profitably. Developers rely on them heavily, with the average mobile app using 30 SDKs, and 90% of code sourced from third parties. While this widespread use delivers significant benefits to developers, it also propagates safety and security issues. + +SDKs offer a variety of functionality, and should be regarded as an individual project. You should evaluate how the MASVS applies to the used SDKs to ensure the highest possible security testing coverage. diff --git a/Document/0x04-Assessment_and_Certification.md b/Document/04-Assessment_and_Certification.md similarity index 54% rename from Document/0x04-Assessment_and_Certification.md rename to Document/04-Assessment_and_Certification.md index 83e6084e3..c8a81ea13 100644 --- a/Document/0x04-Assessment_and_Certification.md +++ b/Document/04-Assessment_and_Certification.md @@ -12,17 +12,19 @@ This should not inhibit organizations from offering such assurance services, as The recommended way of verifying compliance of a mobile app with the MASVS is by performing an "open book" review, meaning that the testers are granted access to key resources such as architects and developers of the app, project documentation, source code, and authenticated access to endpoints, including access to at least one user account for each role. -It is important to note that the MASVS only covers security of the (client-side) mobile app and the network communication between the app and its remote endpoint(s), as well as a few basic and generic requirements related to user authentication and session management. It does not contain specific requirements for the remote services (e.g. web services) associated with the app other than a limited set of generic requirements pertaining to authorization, authentication, control verification, and session management. However, MASVS V1 specifies that remote services must be covered by the overall threat model, and be verified against appropriate standards, such as the OWASP ASVS. +It is important to note that the MASVS only covers the security of the mobile app (client-side). It does not contain specific controls for the remote endpoints (e.g. web services) associated with the app and they should be verified against appropriate standards, such as the [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/). -A certifying organization must include in any report the scope of the verification (particularly if a key component is out of scope), a summary of verification findings, including passed and failed tests, with clear indications of how to resolve the failed tests. Keeping detailed work papers, screenshots or movies, scripts to reliably and repeatedly exploit an issue, and electronic records of testing, such as intercepting proxy logs and associated notes such as a cleanup list, is considered standard industry practice. It is not sufficient to simply run a tool and report on the failures; this does not provide sufficient evidence that all issues at a certifying level have been tested and tested thoroughly. In case of dispute, there should be sufficient supportive evidence to demonstrate that every verified requirement has indeed been tested. +A certifying organization must include in any report the scope of the verification (particularly if a key component is out of scope), a summary of verification findings, including passed and failed tests, with clear indications of how to resolve the failed tests. Keeping detailed work papers, screenshots or recording, scripts to reliably and repeatedly exploit an issue, and electronic records of testing, such as intercepting proxy logs and associated notes such as a cleanup list, is considered standard industry practice. It is not sufficient to simply run a tool and report on the failures; this does not provide sufficient evidence that all issues at a certifying level have been tested and tested thoroughly. In case of dispute, there should be sufficient supportive evidence to demonstrate that every verified control has indeed been tested. ### Using the OWASP Mobile Application Security Testing Guide (MASTG) -The OWASP MASTG is a manual for testing the security of mobile apps. It describes the technical processes for verifying the requirements listed in the MASVS. The MASTG includes a list of test cases, each of which map to a requirement in the MASVS. While the MASVS requirements are high-level and generic, the MASTG provides in-depth recommendations and testing procedures on a per-mobile-OS basis. +The OWASP MASTG is a manual for testing the security of mobile apps. It describes the technical processes for verifying the controls listed in the MASVS. The MASTG includes a list of test cases, each of which map to a control in the MASVS. While the MASVS controls are high-level and generic, the MASTG provides in-depth recommendations and testing procedures on a per-mobile-OS basis. + +Testing the app's remote endpoints is not covered in the MASTG. The [OWASP Web Security Testing Guide (WSTG)](https://owasp.org/www-project-web-security-testing-guide/) is a comprehensive guide with detailed technical explanation and guidance for testing the security of web applications and web services holistically and can be used in addition to other relevant resources to complement the mobile app security testing exercise. ### The Role of Automated Security Testing Tools -The use of source code scanners and black-box testing tools is encouraged in order to increase efficiency whenever possible. It is however not possible to complete MASVS verification using automated tools alone: Every mobile app is different, and understanding the overall architecture, business logic, and technical pitfalls of the specific technologies and frameworks being used, is a mandatory requirement to verify security of the app. +The use of source code scanners and black-box testing tools is encouraged in order to increase efficiency whenever possible. It is however not possible to complete MASVS verification using automated tools alone, since every mobile app is different. In order to fully verify the security of the app it is essential to understand the overall architecture, business logic, and technical pitfalls of the specific technologies and frameworks being used. ## Other Uses @@ -32,15 +34,15 @@ One of the more common uses for the Mobile Application Security Verification Sta ### As a Replacement for Off-the-shelf Secure Coding Checklists -Many organizations can benefit from adopting the MASVS, by choosing one of the two levels, or by forking MASVS and changing what is required for each application's risk level in a domain-specific way. We encourage this type of forking as long as traceability is maintained, so that if an app has passed requirement 4.1, this means the same thing for forked copies as the standard evolves. +Many organizations can benefit from adopting the MASVS, by choosing one of the two levels, or by forking MASVS and changing what is required for each application's risk level in a domain-specific way. We encourage this type of forking as long as traceability is maintained, so that if an app has passed control 4.1, this means the same thing for forked copies as the standard evolves. ### As a Basis for Security Testing Methodologies -A good mobile app security testing methodology should cover all requirements listed in the MASVS. The OWASP Mobile Application Security Testing Guide (MASTG) describes black-box and white-box test cases for each verification requirement. +A good mobile app security testing methodology should cover all controls listed in the MASVS. The OWASP Mobile Application Security Testing Guide (MASTG) describes black-box and white-box test cases for each verification control. ### As a Guide for Automated Unit and Integration Tests -The MASVS is designed to be highly testable, with the sole exception of architectural requirements. Automated unit, integration and acceptance testing based on the MASVS requirements can be integrated in the continuous development lifecycle. This not only increases developer security awareness, but also improves the overall quality of the resulting apps, and reduces the amount of findings during security testing in the pre-release phase. +The MASVS is designed to be highly testable, with the sole exception of architectural controls. Automated unit, integration and acceptance testing based on the MASVS controls can be integrated in the continuous development lifecycle. This not only increases developer security awareness, but also improves the overall quality of the resulting apps, and reduces the amount of findings during security testing in the pre-release phase. ### For Secure Development Training diff --git a/Document/05-MASVS-STORAGE.md b/Document/05-MASVS-STORAGE.md new file mode 100644 index 000000000..da0d8e912 --- /dev/null +++ b/Document/05-MASVS-STORAGE.md @@ -0,0 +1,5 @@ +# MASVS-STORAGE: Storage + +Mobile applications handle a wide variety of sensitive data, such as personally identifiable information (PII), cryptographic material, secrets, and API keys, that often need to be stored locally. This sensitive data may be stored in private locations, such as the app's internal storage, or in public folders that are accessible by the user or other apps installed on the device. However, sensitive data can also be unintentionally stored or exposed to publicly accessible locations, typically as a side-effect of using certain APIs or system capabilities such as backups or logs. + +This category is designed to help developers ensure that any sensitive data intentionally stored by the app is properly protected, regardless of the target location. It also covers unintentional leaks that can occur due to improper use of APIs or system capabilities. diff --git a/Document/06-MASVS-CRYPTO.md b/Document/06-MASVS-CRYPTO.md new file mode 100644 index 000000000..bb5f527d4 --- /dev/null +++ b/Document/06-MASVS-CRYPTO.md @@ -0,0 +1,5 @@ +# MASVS-CRYPTO: Cryptography + +Cryptography is essential for mobile apps because mobile devices are highly portable and can be easily lost or stolen. This means that an attacker who gains physical access to a device can potentially access all the sensitive data stored on it, including passwords, financial information, and personally identifiable information. Cryptography provides a means of protecting this sensitive data by encrypting it so that it cannot be easily read or accessed by an unauthorized user. + +The purpose of the controls in this category is to ensure that the verified app uses cryptography according to industry best practices, which are typically defined in external standards such as [NIST.SP.800-175B](https://csrc.nist.gov/publications/detail/sp/800-175b/rev-1/final) and [NIST.SP.800-57](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final). This category also focuses on the management of cryptographic keys throughout their lifecycle, including key generation, storage, and protection. Poor key management can compromise even the strongest cryptography, so it is crucial for developers to follow the recommended best practices to ensure the security of their users' sensitive data. diff --git a/Document/07-MASVS-AUTH.md b/Document/07-MASVS-AUTH.md new file mode 100644 index 000000000..7177cc2ef --- /dev/null +++ b/Document/07-MASVS-AUTH.md @@ -0,0 +1,7 @@ +# MASVS-AUTH: Authentication and Authorization + +Authentication and authorization are essential components of most mobile apps, especially those that connect to a remote service. These mechanisms provide an added layer of security and help prevent unauthorized access to sensitive user data. Although the enforcement of these mechanisms must be on the remote endpoint, it is equally important for the app to follow relevant best practices to ensure the secure use of the involved protocols. + +Mobile apps often use different forms of authentication, such as biometrics, PIN, or multi-factor authentication code generators, to validate user identity. These mechanisms must be implemented correctly to ensure their effectiveness in preventing unauthorized access. Additionally, some apps may rely solely on local app authentication and may not have a remote endpoint. In such cases, it is critical to ensure that local authentication mechanisms are secure and implemented following industry best practices. + +The controls in this category aim to ensure that the app implements authentication and authorization mechanisms securely, protecting sensitive user information and preventing unauthorized access. It is important to note that the security of the remote endpoint should also be validated using industry standards such as the [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/). diff --git a/Document/08-MASVS-NETWORK.md b/Document/08-MASVS-NETWORK.md new file mode 100644 index 000000000..0324da572 --- /dev/null +++ b/Document/08-MASVS-NETWORK.md @@ -0,0 +1,5 @@ +# MASVS-NETWORK: Network Communication + +Secure networking is a critical aspect of mobile app security, particularly for apps that communicate over the network. In order to ensure the confidentiality and integrity of data in transit, developers typically rely on encryption and authentication of the remote endpoint, such as through the use of TLS. However, there are numerous ways in which a developer may accidentally disable the platform secure defaults or bypass them entirely by utilizing low-level APIs or third-party libraries. + +This category is designed to ensure that the mobile app sets up secure connections under any circumstances. Specifically, it focuses on verifying that the app establishes a secure, encrypted channel for network communication. Additionally, this category covers situations where a developer may choose to trust only specific Certificate Authorities (CAs), which is commonly referred to as certificate pinning or public key pinning. diff --git a/Document/09-MASVS-PLATFORM.md b/Document/09-MASVS-PLATFORM.md new file mode 100644 index 000000000..74c1ed9f5 --- /dev/null +++ b/Document/09-MASVS-PLATFORM.md @@ -0,0 +1,7 @@ +# MASVS-PLATFORM: Platform Interaction + +The security of mobile apps heavily depends on their interaction with the mobile platform, which often involves exposing data or functionality intentionally through the use of platform-provided inter-process communication (IPC) mechanisms and WebViews to enhance the user experience. However, these mechanisms can also be exploited by attackers or other installed apps, potentially compromising the app's security. + +Furthermore, sensitive data, such as passwords, credit card details, and one-time passwords in notifications, is often displayed in the app's user interface. It is essential to ensure that this data is not unintentionally leaked through platform mechanisms such as auto-generated screenshots or accidental disclosure through shoulder surfing or device sharing. + +This category comprises controls that ensure the app's interactions with the mobile platform occur securely. These controls cover the secure use of platform-provided IPC mechanisms, WebView configurations to prevent sensitive data leakage and functionality exposure, and secure display of sensitive data in the app's user interface. By implementing these controls, mobile app developers can safeguard sensitive user information and prevent unauthorized access by attackers. diff --git a/Document/0x02-Frontispiece.md b/Document/0x02-Frontispiece.md deleted file mode 100644 index 904f31739..000000000 --- a/Document/0x02-Frontispiece.md +++ /dev/null @@ -1,54 +0,0 @@ -# About the Standard - -![OWASP Logo](images/OWASP_logo.png) - -Welcome to the Mobile Application Security Verification Standard (MASVS). 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: . - -Accounts can be created at the following URL: [https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/](https://owasp.slack.com/join/shared_invite/zt-g398htpy-AZ40HOM1WUOZguJKbblqkw#/). - -## Copyright and License - -[![Creative Commons License](images/CC-license.png)](https://creativecommons.org/licenses/by-sa/4.0/) - -Copyright © 2021 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. - - - -## Acknowledgements - -| Project Lead | Lead Author | Contributors and Reviewers -| ------- | --- | ----------------- | -| Sven Schleier and Carlos Holguera | Bernhard Mueller, Sven Schleier, Jeroen Willemsen and Carlos Holguera | Alexander Antukh, Mesheryakov Aleksey, Elderov Ali, Bachevsky Artem, Jeroen Beckers, Jon-Anthoney de Boer, Damien Clochard, Ben Cheney, Will Chilcutt, Stephen Corbiaux, Manuel Delgado, Ratchenko Denis, Ryan Dewhurst, @empty_jack, Ben Gardiner, Anton Glezman, Josh Grossman, Sjoerd Langkemper, Vinícius Henrique Marangoni, Martin Marsicano, Roberto Martelloni, @PierrickV, Julia Potapenko, 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 | - -
- -| Language | Translators & Reviewers | -| --------------- | ------------------------------------------------------------ | -| Brazilian Portuguese | Mateus Polastro, Humberto Junior, Rodrigo Araujo, Maurício Ariza, Fernando Galves | -| Chinese (Traditonal) | Peter Chi, 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) | -| Hindi | Mukesh Sharma, Ritesh Kumar, Kunwar Atul Singh, Parag Dave, Devendra Kumar Sinha, Vikrant Shah | -| 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, Milad Khoshdel | -| Portuguese | Ana Filipa Mota, Fernando Nogueira, Filipa Gomes, Luis Fontes, Sónia Dias| -| Russian | Gall Maxim, Eugen Martynov, Chelnokov Vladislav, Oprya Egor, Tereshin Dmitry | -| Spanish | Martin Marsicano, Carlos Holguera | -| Turkish | Anıl Baş, Haktan Emik | -| Greek | Panagiotis Yialouris | - -This document started as a fork of the OWASP Application Security Verification Standard written by Jim Manico. - -### Donators - -While both the MASVS and the MASTG are created and maintained by the community on a voluntary basis, sometimes a little bit of outside help is required. We therefore thank our donators for providing the funds to be able to hire technical editors. Note that their donation does not influence the content of the MASVS or MASTG in any way. The Donation Packages are described on the [OWASP Project Wiki](https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide#tab=Sponsorship_Packages "OWASP Mobile Application Security Testing Guide Donation Packages"). - - - -We would like to thank everybody that bought the book from [Leanpub](https://leanpub.com/mobile-security-testing-guide) and sponsored us that way. diff --git a/Document/0x03-Using_the_MASVS.md b/Document/0x03-Using_the_MASVS.md deleted file mode 100644 index 24d6c8c2f..000000000 --- a/Document/0x03-Using_the_MASVS.md +++ /dev/null @@ -1,93 +0,0 @@ -# The Mobile Application Security Verification Standard - -The MASVS can be used to establish a level of confidence in the security of mobile apps. The requirements were developed with the following objectives in mind: - -- Use as a metric - To provide a security standard against which existing mobile apps can be compared by developers and application owners; -- Use as guidance - To provide guidance during all phases of mobile app development and testing; -- Use during procurement - To provide a baseline for mobile app security verification. - -The MAS project has been traditionally focused on downloadable apps, and as such, all its resources refer to "apps". However, the project is also applicable to other areas of the business such as preloaded applications and SDKs. For both of these categories there are a few things to consider: - -**Preloads:** Preloaded apps are apps that are installed on a user's device at factory time and may have elevated privileges that leave users vulnerable to exploitative business practices. Given the large number of preloaded apps on an average user's device, it's important to measure their risk in a quantifiable way. - -There are hundreds of preloads that may ship on a device and as a result automation is critical, therefore a subset of MAS criteria that is automation friendly may be a good basis. - -**SDKs:** SDKs play a vital role in the mobile app value chain, supplying code developers need to build faster, smarter, and more profitably. Developers rely on them heavily with the average mobile app using 30 SDKs and 90% of code sourced from third parties. While this widespread use delivers significant benefits to developers, it also propagates safety and security issues. - -SDKs offer a variety of functionality and therefore not all MASVS categories apply to every single SDK type. As a result the SDK developer should evaluate which categories apply to their respective SDKs to ensure a lab can evaluate them properly. - -## Mobile AppSec Model - -The MASVS defines two security verification levels (MASVS-L1 and MASVS-L2), as well as a set of reverse engineering resiliency requirements (MASVS-R). MASVS-L1 contains generic security requirements that are recommended for all mobile apps, while MASVS-L2 should be applied to apps handling highly sensitive data. MASVS-R covers additional protective controls that can be applied if preventing client-side threats is a design goal. - -Fulfilling the requirements in MASVS-L1 results in a secure app that follows security best practices and doesn't suffer from common vulnerabilities. MASVS-L2 adds additional defense-in-depth controls such as SSL pinning, resulting in an app that is resilient against more sophisticated attacks - assuming the security controls of the mobile operating system are intact and the end user is not viewed as a potential adversary. Fulfilling all, or subsets of, the software protection requirements in MASVS-R helps impede specific client-side threats where the end user is malicious and/or the mobile OS is compromised. - -**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 Application 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.** - -![Verification Levels](images/masvs-levels-new.jpg) - -### 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 MASTG: - -- *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. - -###### 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. diff --git a/Document/0x06-V1-Architecture_design_and_threat_modelling_requireme.md b/Document/0x06-V1-Architecture_design_and_threat_modelling_requireme.md deleted file mode 100644 index 8969da159..000000000 --- a/Document/0x06-V1-Architecture_design_and_threat_modelling_requireme.md +++ /dev/null @@ -1,38 +0,0 @@ -# V1: Architecture, Design and Threat Modeling Requirements - -## Control Objective - -In a perfect world, security would be considered throughout all phases of development. In reality however, security is often only a consideration at a late stage in the SDLC. Besides the technical controls, the MASVS requires processes to be in place that ensure that the security has been explicitly addressed when planning the architecture of the mobile app, and that the functional and security roles of all components are known. Since most mobile applications act as clients to remote services, it must be ensured that appropriate security standards are also applied to those services - testing the mobile app in isolation is not sufficient. - -**The category “V1” lists requirements pertaining to architecture and design of the app. As such, this is the only category that does not map to technical test cases in the OWASP Mobile Application Security Testing Guide. To cover topics such as threat modelling, secure SDLC or key management, users of the MASVS should consult the respective OWASP projects and/or other standards such as the ones linked below.** - -## Security Verification Requirements - -The requirements for MASVS-L1 and MASVS-L2 are listed below. - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **1.1** | MSTG-ARCH-1 | All app components are identified and known to be needed. | x | x | -| **1.2** | MSTG-ARCH-2 | Security controls are never enforced only on the client side, but on the respective remote endpoints. | x | x | -| **1.3** | MSTG-ARCH-3 | A high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture. | x | x | -| **1.4** | MSTG-ARCH-4 | Data considered sensitive in the context of the mobile app is clearly identified. | x | x | -| **1.5** | MSTG-ARCH-5 | All app components are defined in terms of the business functions and/or security functions they provide. | | x | -| **1.6** | MSTG-ARCH-6 | A threat model for the mobile app and the associated remote services has been produced that identifies potential threats and countermeasures. | | x | -| **1.7** | MSTG-ARCH-7 | All security controls have a centralized implementation. | | x | -| **1.8** | MSTG-ARCH-8 | There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. | | x | -| **1.9** | MSTG-ARCH-9 | A mechanism for enforcing updates of the mobile app exists. | | x | -| **1.10** | MSTG-ARCH-10 | Security is addressed within all parts of the software development lifecycle. | | x | -| **1.11** | MSTG-ARCH-11 | A responsible disclosure policy is in place and effectively applied. | | x | -| **1.12** | MSTG-ARCH-12 | The app should comply with privacy laws and regulations. | x | x | - - -## References - -For more information, see also: - -- OWASP Mobile Top 10: M10 (Extraneous Functionality) - -- OWASP Threat modelling - -- OWASP Secure SDLC Cheat Sheet - -- Microsoft SDL - -- NIST SP 800-57 - -- security.txt - diff --git a/Document/0x07-V2-Data_Storage_and_Privacy_requirements.md b/Document/0x07-V2-Data_Storage_and_Privacy_requirements.md deleted file mode 100644 index 38f80cf92..000000000 --- a/Document/0x07-V2-Data_Storage_and_Privacy_requirements.md +++ /dev/null @@ -1,66 +0,0 @@ -# V2: Data Storage and Privacy Requirements - -## Control Objective - -The protection of sensitive data, such as user credentials and private information, is a key focus in mobile security. Firstly, sensitive data can be unintentionally exposed to other apps running on the same device if operating system mechanisms like IPC are used improperly. Data may also unintentionally leak to cloud storage, backups, or the keyboard cache. Additionally, mobile devices can be lost or stolen more easily compared to other types of devices, so an adversary gaining physical access is a more likely scenario. In that case, additional protections can be implemented to make retrieving the sensitive data more difficult. - -Note that, as the MASVS is app-centric, it does not cover device-level policies such as those enforced by MDM solutions. We encourage the use of such policies in an Enterprise context to further enhance data security. - -### Definition of Sensitive Data - -Sensitive data in the context of the MASVS pertains to both user credentials and any other data considered sensitive in the particular context, such as: - -- Personally identifiable information (PII) that can be abused for identity theft: Social security numbers, credit card numbers, bank account numbers, health information; -- Highly sensitive data that would lead to reputational harm and/or financial costs if compromised: Contractual information, information covered by non-disclosure agreements, management information; -- Any data that must be protected by law or for compliance reasons. - - -## Security Verification Requirements - -The vast majority of data disclosure issues can be prevented by following simple rules. Most of the controls listed in this chapter are mandatory for all verification levels. - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **2.1** | MSTG-STORAGE-1 | System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys. | x | x | -| **2.2** | MSTG-STORAGE-2 | No sensitive data should be stored outside of the app container or system credential storage facilities. | x | x | -| **2.3** | MSTG-STORAGE-3 | No sensitive data is written to application logs. | x | x | -| **2.4** | MSTG-STORAGE-4 | No sensitive data is shared with third parties unless it is a necessary part of the architecture. | x | x | -| **2.5** | MSTG-STORAGE-5 | The keyboard cache is disabled on text inputs that process sensitive data. | x | x | -| **2.6** | MSTG-STORAGE-6 | No sensitive data is exposed via IPC mechanisms. | x | x | -| **2.7** | MSTG-STORAGE-7 | No sensitive data, such as passwords or pins, is exposed through the user interface. | x | x | -| **2.8** | MSTG-STORAGE-8 | No sensitive data is included in backups generated by the mobile operating system. | | x | -| **2.9** | MSTG-STORAGE-9 | The app removes sensitive data from views when moved to the background. | | x | -| **2.10** | MSTG-STORAGE-10 | The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use. | | x | -| **2.11** | MSTG-STORAGE-11 | The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode. | | x | -| **2.12** | MSTG-STORAGE-12 | The app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app. | x | x | -| **2.13** | MSTG-STORAGE-13 | No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory. | | x | -| **2.14** | MSTG-STORAGE-14 | If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication. | | x | -| **2.15** | MSTG-STORAGE-15 | The app’s local storage should be wiped after an excessive number of failed authentication attempts. | | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed in this section. - -- Android: Testing Data Storage - -- iOS: Testing Data Storage - - -For more information, see also: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M2 (Insecure Data Storage) - -- CWE 117 (Improper Output Neutralization for Logs) - -- CWE 200 (Information Exposure) - -- CWE 276 (Incorrect Default Permissions) - -- CWE 311 (Missing Encryption of Sensitive Data) - -- CWE 312 (Cleartext Storage of Sensitive Information) - -- CWE 316 (Cleartext Storage of Sensitive Information in Memory) - -- CWE 359 (Exposure of Private Information ('Privacy Violation')) - -- CWE 522 (Insufficiently Protected Credentials) - -- CWE 524 (Information Exposure Through Caching) - -- CWE 530 (Exposure of Backup File to an Unauthorized Control Sphere) - -- CWE 532 (Information Exposure Through Log Files) - -- CWE 534 (Information Exposure Through Debug Log Files) - -- CWE 634 (Weaknesses that Affect System Processes) - -- CWE 798 (Use of Hard-coded Credentials) - -- CWE 921 (Storage of Sensitive Data in a Mechanism without Access Control) - -- CWE 922 (Insecure Storage of Sensitive Information) - diff --git a/Document/0x08-V3-Cryptography_Verification_Requirements.md b/Document/0x08-V3-Cryptography_Verification_Requirements.md deleted file mode 100644 index 95b87d926..000000000 --- a/Document/0x08-V3-Cryptography_Verification_Requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V3: Cryptography Requirements - -## Control Objective - -Cryptography is an essential ingredient when it comes to protecting data stored on a mobile device. It is also a category where things can go horribly wrong, especially when standard conventions are not followed. The purpose of the controls in this chapter is to ensure that the verified application uses cryptography according to industry best practices, including: - -- Use of proven cryptographic libraries; -- Proper choice and configuration of cryptographic primitives; -- A suitable random number generator wherever randomness is required. - -## Security Verification Requirements - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **3.1** | MSTG-CRYPTO-1 | The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.| x | x | -| **3.2** | MSTG-CRYPTO-2 | The app uses proven implementations of cryptographic primitives. | x | x | -| **3.3** | MSTG-CRYPTO-3 | The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices. | x | x | -| **3.4** | MSTG-CRYPTO-4 | The app does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes. | x | x | -| **3.5** | MSTG-CRYPTO-5 | The app doesn't re-use the same cryptographic key for multiple purposes. | x | x | -| **3.6** | MSTG-CRYPTO-6 | All random values are generated using a sufficiently secure random number generator. | x | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed in this section. - -- Android: Testing Cryptography - -- iOS: Testing Cryptography - - -For more information, see also: - -- OWASP Mobile Top 10: M5 (Insufficient Cryptography) - -- CWE 310 (Cryptographic Issues) - -- CWE 321 (Use of Hard-coded Cryptographic Key) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 329 (Not Using a Random IV with CBC Mode) - -- CWE 330 (Use of Insufficiently Random Values) - -- CWE 337 (Predictable Seed in PRNG) - -- CWE 338 (Use of Cryptographically Weak Pseudo Random Number Generator (PRNG)) - diff --git a/Document/0x09-V4-Authentication_and_Session_Management_Requirements.md b/Document/0x09-V4-Authentication_and_Session_Management_Requirements.md deleted file mode 100644 index 94beef7f8..000000000 --- a/Document/0x09-V4-Authentication_and_Session_Management_Requirements.md +++ /dev/null @@ -1,41 +0,0 @@ -# V4: Authentication and Session Management Requirements - -## Control Objective - -In most cases, users logging into a remote service is an integral part of the overall mobile app architecture. Even though most of the logic happens at the endpoint, MASVS defines some basic requirements regarding how user accounts and sessions are to be managed. - -## Security Verification Requirements - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **4.1** | MSTG-AUTH-1 | If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. | x | x | -| **4.2** | MSTG-AUTH-2 | If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. | x | x | -| **4.3** | MSTG-AUTH-3 | If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. | x | x | -| **4.4** | MSTG-AUTH-4 | The remote endpoint terminates the existing session when the user logs out. | x | x | -| **4.5** | MSTG-AUTH-5 | A password policy exists and is enforced at the remote endpoint. | x | x | -| **4.6** | MSTG-AUTH-6 | The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. | x | x | -| **4.7** | MSTG-AUTH-7 | Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire. | x | x | -| **4.8** | MSTG-AUTH-8 | Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore. | | x | -| **4.9** | MSTG-AUTH-9 | A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. | | x | -| **4.10** | MSTG-AUTH-10 | Sensitive transactions require step-up authentication. | | x | -| **4.11** | MSTG-AUTH-11 | The app informs the user of all sensitive activities with their account. Users are able to view a list of devices, view contextual information (IP address, location, etc.), and to block specific devices. | | x | -| **4.12** | MSTG-AUTH-12 | Authorization models should be defined and enforced at the remote endpoint. | x | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed above. - -- General: Authentication and Session Management - -- Android: Testing Local Authentication - -- iOS: Testing Local Authentication - - -For more information, see also: - -- OWASP Mobile Top 10: M4 (Insecure Authentication) - -- OWASP Mobile Top 10: M6 (Insecure Authorization) - -- CWE 287 (Improper Authentication) - -- CWE 307 (Improper Restriction of Excessive Authentication Attempts) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 521 (Weak Password Requirements) - -- CWE 604 (Use of Client-Side Authentication) - -- CWE 613 (Insufficient Session Expiration) - diff --git a/Document/0x10-V5-Network_communication_requirements.md b/Document/0x10-V5-Network_communication_requirements.md deleted file mode 100644 index 1609aa477..000000000 --- a/Document/0x10-V5-Network_communication_requirements.md +++ /dev/null @@ -1,39 +0,0 @@ -# V5: Network Communication Requirements - -## Control Objective - -The purpose of the controls listed in this section is to ensure the confidentiality and integrity of information exchanged between the mobile app and remote service endpoints. At the very least, a mobile app must set up a secure, encrypted channel for network communication using the TLS protocol with appropriate settings. Level 2 lists additional defense-in-depth measure such as SSL pinning. - -## Security Verification Requirements - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **5.1** | MSTG-NETWORK-1 | Data is encrypted on the network using TLS. The secure channel is used consistently throughout the app. | x | x | -| **5.2** | MSTG-NETWORK-2 | The TLS settings are in line with current best practices, or as close as possible if the mobile operating system does not support the recommended standards. | x | x | -| **5.3** | MSTG-NETWORK-3 | The app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a trusted CA are accepted. | x | x | -| **5.4** | MSTG-NETWORK-4 | The app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA. | | x | -| **5.5** | MSTG-NETWORK-5 | The app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery. | | x | -| **5.6** | MSTG-NETWORK-6 | The app only depends on up-to-date connectivity and security libraries. | | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed in this section. - -- General: Testing Network Communication - -- Android: Testing Network Communication - -- iOS: Testing Network Communication - - -For more information, see also: - -- OWASP Mobile Top 10: M3 (Insecure Communication) - -- CWE 295 (Improper Certificate Validation) - -- CWE 296 (Improper Following of a Certificate's Chain of Trust) - -- CWE 297 (Improper Validation of Certificate with Host Mismatch) - -- CWE 298 (Improper Validation of Certificate Expiration) - -- CWE 308 (Use of Single-factor Authentication) - -- CWE 319 (Cleartext Transmission of Sensitive Information) - -- CWE 326 (Inadequate Encryption Strength) - -- CWE 327 (Use of a Broken or Risky Cryptographic Algorithm) - -- CWE 780 (Use of RSA Algorithm without OAEP) - -- CWE 940 (Improper Verification of Source of a Communication Channel) - -- CWE 941 (Incorrectly Specified Destination in a Communication Channel) - diff --git a/Document/0x11-V6-Interaction_with_the_environment.md b/Document/0x11-V6-Interaction_with_the_environment.md deleted file mode 100644 index 77afb6da9..000000000 --- a/Document/0x11-V6-Interaction_with_the_environment.md +++ /dev/null @@ -1,45 +0,0 @@ -# V6: Platform Interaction Requirements - -## Control Objective - -The controls in this group ensure that the app uses platform APIs and standard components in a secure manner. Additionally, the controls cover communication between apps (IPC). - -## Security Verification Requirements - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **6.1** | MSTG-PLATFORM-1 | The app only requests the minimum set of permissions necessary. | x | x | -| **6.2** | MSTG-PLATFORM-2 | All inputs from external sources and the user are validated and if necessary sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources.| x | x | -| **6.3** | MSTG-PLATFORM-3 | The app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected. | x | x | -| **6.4** | MSTG-PLATFORM-4 | The app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected. | x | x | -| **6.5** | MSTG-PLATFORM-5 | JavaScript is disabled in WebViews unless explicitly required. | x | x | -| **6.6** | MSTG-PLATFORM-6 | WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https is supported). Potentially dangerous handlers, such as file, tel and app-id, are disabled. | x | x | -| **6.7** | MSTG-PLATFORM-7 | If native methods of the app are exposed to a WebView, verify that the WebView only renders JavaScript contained within the app package. | x | x | -| **6.8** | MSTG-PLATFORM-8 | Object deserialization, if any, is implemented using safe serialization APIs. | x | x | -| **6.9** | MSTG-PLATFORM-9 | The app protects itself against screen overlay attacks. (Android only) | | x | -| **6.10** | MSTG-PLATFORM-10 | A WebView's cache, storage, and loaded resources (JavaScript, etc.) should be cleared before the WebView is destroyed. | | x | -| **6.11** | MSTG-PLATFORM-11 | Verify that the app prevents usage of custom third-party keyboards whenever sensitive data is entered (iOS only). | | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed in this section. - -- Android: Testing Platform Interaction - -- iOS: Testing Platform Interaction - - -For more information, see also: - -- OWASP Mobile Top 10: M1 (Improper Platform Usage) - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 79 (Improper Neutralization of Input During Web Page Generation) - -- CWE 200 (Information Leak / Disclosure) - -- CWE 250 (Execution with Unnecessary Privileges) - -- CWE 672 (Operation on a Resource after Expiration or Release) - -- CWE 749 (Exposed Dangerous Method or Function) - -- CWE 772 (Missing Release of Resource after Effective Lifetime) - -- CWE 920 (Improper Restriction of Power Consumption) - -- CWE 925 (Improper Verification of Intent by Broadcast Receiver) - -- CWE 926 (Improper Export of Android Application Components) - -- CWE 927 (Use of Implicit Intent for Sensitive Communication) - -- CWE 939 (Improper Authorization in Handler for Custom URL Scheme) - diff --git a/Document/0x12-V7-Code_quality_and_build_setting_requirements.md b/Document/0x12-V7-Code_quality_and_build_setting_requirements.md deleted file mode 100644 index 784649ec4..000000000 --- a/Document/0x12-V7-Code_quality_and_build_setting_requirements.md +++ /dev/null @@ -1,42 +0,0 @@ -# V7: Code Quality and Build Setting Requirements - -## Control Objective - -The goal of this control is to ensure that basic security coding practices are followed in developing the app, and that "free" security features offered by the compiler are activated. - -## Security Verification Requirements - -| # | MSTG-ID | Description | L1 | L2 | -| -- | ---------- | ---------------------- | - | - | -| **7.1** | MSTG-CODE-1 | The app is signed and provisioned with a valid certificate, of which the private key is properly protected. | x | x | -| **7.2** | MSTG-CODE-2 | The app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable). | x | x | -| **7.3** | MSTG-CODE-3 | Debugging symbols have been removed from native binaries. | x | x | -| **7.4** | MSTG-CODE-4 | Debugging code and developer assistance code (e.g. test code, backdoors, hidden settings) have been removed. The app does not log verbose errors or debugging messages. | x | x | -| **7.5** | MSTG-CODE-5 | All third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities. | x | x | -| **7.6** | MSTG-CODE-6 | The app catches and handles possible exceptions.| x | x | -| **7.7** | MSTG-CODE-7 | Error handling logic in security controls denies access by default. | x | x | -| **7.8** | MSTG-CODE-8 | In unmanaged code, memory is allocated, freed and used securely. | x | x | -| **7.9** | MSTG-CODE-9 | Free security features offered by the toolchain, such as byte-code minification, stack protection, PIE support and automatic reference counting, are activated. | x | x | - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed above. - -- Android: Testing Code Quality and Build Settings - -- iOS: Testing Code Quality and Build Settings - - -For more information, see also: - -- OWASP Mobile Top 10: M7 (Poor Code Quality) - -- CWE 20 (Improper Input Validation) - -- CWE 89 (Improper Neutralization of Special Elements used in an SQL Command) - -- CWE 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) - -- CWE 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) - -- CWE 215 (Information Exposure through Debug Information) - -- CWE 388 (7PK - Errors) - -- CWE 489 (Leftover Debug Code) - -- CWE 502 (Deserialization of Untrusted Data) - -- CWE 511 (Logic/Time Bomb) - -- CWE 656 (Reliance on Security through Obscurity) - -- CWE 676 (Use of Potentially Dangerous Function) - -- CWE 937 (OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities) - diff --git a/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md b/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md deleted file mode 100644 index d4fbb1a9c..000000000 --- a/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md +++ /dev/null @@ -1,69 +0,0 @@ -# V8: Resilience Requirements - -## Control Objective - -This section covers defense-in-depth measures recommended for apps that process, or give access to, sensitive data or functionality. Lack of any of these controls does not cause a vulnerability - instead, they are meant to increase the app's resilience against reverse engineering and specific client-side attacks. - -The controls in this section should be applied as needed, based on an assessment of the risks caused by unauthorized tampering with the app and/or reverse engineering of the code. We suggest consulting the OWASP document "Technical Risks of Reverse Engineering and Unauthorized Code Modification Reverse Engineering and Code Modification Prevention" (see references below) for a list of business risks as well as associated technical threats. - -**Note that software protections must never be used as a replacement for security controls. The controls listed in MASVR-R are intended to add threat-specific, additional protective controls to apps that also fulfil the MASVS security requirements.** - -The following considerations apply: - -1. A threat model must be defined that clearly outlines the client-side threats that are to be defended. Additionally, the grade of protection the scheme is meant to provide must be specified. For example, a stated goal could be to force authors of targeted malware seeking to instrument the app to invest significant manual reverse engineering effort. - -2. The threat model must be credible and relevant. For example, hiding a cryptographic key in a white-box implementation might prove redundant if an attacker can simply code-lift the white-box as a whole. - -3. The effectiveness of the protection should always be verified by a human expert with experience in testing the particular types of anti-tampering and obfuscation used (see also the "reverse engineering" and "assessing software protections" chapters in the Mobile Application Security Testing Guide). - - - -### Impede Dynamic Analysis and Tampering - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.1** | MSTG-RESILIENCE-1 | The app detects, and responds to, the presence of a rooted or jailbroken device either by alerting the user or terminating the app. | x | -| **8.2** | MSTG-RESILIENCE-2 | The app prevents debugging and/or detects, and responds to, a debugger being attached. All available debugging protocols must be covered. | x | -| **8.3** | MSTG-RESILIENCE-3 | The app detects, and responds to, tampering with executable files and critical data within its own sandbox. | x | -| **8.4** | MSTG-RESILIENCE-4 | The app detects, and responds to, the presence of widely used reverse engineering tools and frameworks on the device.| x | -| **8.5** | MSTG-RESILIENCE-5 | The app detects, and responds to, being run in an emulator. | x | -| **8.6** | MSTG-RESILIENCE-6 | The app detects, and responds to, tampering the code and data in its own memory space. | x | -| **8.7** | MSTG-RESILIENCE-7 | The app implements multiple mechanisms in each defense category (8.1 to 8.6). Note that resiliency scales with the amount, diversity of the originality of the mechanisms used. | x | -| **8.8** | MSTG-RESILIENCE-8 | The detection mechanisms trigger responses of different types, including delayed and stealthy responses. | x | -| **8.9** | MSTG-RESILIENCE-9 | Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis. | x | - - -### Device Binding - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.10** | MSTG-RESILIENCE-10 | The app implements a 'device binding' functionality using a device fingerprint derived from multiple properties unique to the device. | x | - -### Impede Comprehension - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.11** | MSTG-RESILIENCE-11 |All executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis does not reveal important code or data. | x | -| **8.12** | MSTG-RESILIENCE-12 | If the goal of obfuscation is to protect sensitive computations, an obfuscation scheme is used that is both appropriate for the particular task and robust against manual and automated de-obfuscation methods, considering currently published research. The effectiveness of the obfuscation scheme must be verified through manual testing. Note that hardware-based isolation features are preferred over obfuscation whenever possible. | x | - -### Impede Eavesdropping - -| # | MSTG-ID | Description | R | -| -- | ----------- | ---------------------- | - | -| **8.13** | MSTG-RESILIENCE-13 | As a defense in depth, next to having solid hardening of the communicating parties, application level payload encryption can be applied to further impede eavesdropping. | x | - - - -## References - -The OWASP Mobile Application Security Testing Guide provides detailed instructions for verifying the requirements listed in this section. - -- Android: Testing Resiliency Against Reverse Engineering - -- iOS: Testing Resiliency Against Reverse Engineering - - -For more information, see also: - -- OWASP Mobile Top 10: M8 (Code Tampering) - -- OWASP Mobile Top 10: M9 (Reverse Engineering) - -- OWASP Reverse Engineering Threats - -- OWASP Reverse Engineering and Code Modification Prevention - diff --git a/Document/0x90-Appendix-A_Glossary.md b/Document/0x90-Appendix-A_Glossary.md deleted file mode 100644 index 960791f57..000000000 --- a/Document/0x90-Appendix-A_Glossary.md +++ /dev/null @@ -1,42 +0,0 @@ -# Appendix A: Glossary - -- **Address Space Layout Randomization (ASLR)** – A technique to make exploiting memory corruption bugs more difficult. -- **Application Security** – Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. -- **Application Security Verification** – The technical assessment of an application against the OWASP MASVS. -- **Application Security Verification Report** – A report that documents the overall results and supporting analysis produced by the verifier for a particular application. -- **Authentication** – The verification of the claimed identity of an application user. -- **Automated Verification** – The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems. -- **Black Box Testing** – It is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. -- **Component** – A self-contained unit of code, with associated disk and network interfaces that communicates with other components. -- **Cross-Site Scripting (XSS)** – A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. -- **Cryptographic Module** – Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. -- **CWE** – CWE is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. -- **Dynamic Application Security Testing (DAST)** – DAST technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. -- **Design Verification** – The technical assessment of the security architecture of an application. -- **Dynamic Verification** – The use of automated tools that use vulnerability signatures to find problems during the execution of an application. -- **Globally Unique Identifier (GUID)** – A unique reference number used as an identifier in software. -- **Hyper Text Transfer Protocol (HTTP)** – An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. -- **Hardcoded Keys** – Cryptographic keys which are stored in the device itself. -- **IPC** – Inter Process Communications,In IPC Processes communicate with each other and with the kernel to coordinate their activities. -- **Input Validation** – The canonicalization and validation of untrusted user input. -- **Java Bytecode** – Java bytecode is the instruction set of the Java virtual machine(JVM). Each bytecode is composed of one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters. -- **Malicious Code** – Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! -- **Malware** – Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. -- **Open Web Application Security Project (OWASP)** – The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: -- **Personally Identifiable Information (PII)** – PII is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. -- **Position-Independent Executable (PIE)** – A PIE is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. -- **Public Key Infrastructure (PKI)** – A PKI is an arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). -- **Static Application Security Testing (SAST)** – SAST is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. -- **SDLC** – Software development lifecycle. -- **Security Architecture** – An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. -- **Security Configuration** – The runtime configuration of an application that affects how security controls are used. -- **Security Control** – A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record). -- **SQL Injection (SQLi)** – A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. -- **SSO Authentication** – Single Sign On (SSO) occurs when a user logs in to one Client and is then signed in to other Clients automatically, regardless of the platform, technology, or domain the user is using. For example when you log in in google you automatically login in the youtube , docs and mail service. -- **Threat Modeling** – A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. -- **Transport Layer Security** – Cryptographic protocols that provide communication security over the Internet -- **URI and URL** – A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource. -- **User Acceptance Testing (UAT)** – Traditionally a test environment that behaves like the production environment where all software testing is performed before going live. -- **Verifier** – The person or team that is reviewing an application against the OWASP MASVS requirements. -- **Whitelist** – A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. -- **X.509 Certificate** – An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. diff --git a/Document/0x91-Appendix-B_References.md b/Document/0x91-Appendix-B_References.md deleted file mode 100644 index a4fa707eb..000000000 --- a/Document/0x91-Appendix-B_References.md +++ /dev/null @@ -1,14 +0,0 @@ -# Appendix B: References - -The following OWASP projects are most likely to be useful to users/adopters of this standard: - -- OWASP Mobile Security Project - [https://owasp.org/www-project-mobile-security/](https://owasp.org/www-project-mobile-security/) -- OWASP Mobile Application Security Testing Guide - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- OWASP Mobile Top 10 Risks - [https://owasp.org/www-project-mobile-top-10/](https://owasp.org/www-project-mobile-top-10/) -- OWASP Reverse Engineering and Code Modification Prevention - [https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project](https://wiki.owasp.org/index.php/OWASP_Reverse_Engineering_and_Code_Modification_Prevention_Project) - -Similarly, the following web sites are most likely to be useful to users/adopters of this standard: - -- MITRE Common Weakness Enumeration - [http://cwe.mitre.org/](http://cwe.mitre.org/) -- PCI Security Standards Council - [https://www.pcisecuritystandards.org](https://www.pcisecuritystandards.org) -- PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment Procedures - [https://www.pcisecuritystandards.org/documents/PCI\_DSS\_v3.pdf](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf) diff --git a/Document/10-MASVS-CODE.md b/Document/10-MASVS-CODE.md new file mode 100644 index 000000000..31ea53031 --- /dev/null +++ b/Document/10-MASVS-CODE.md @@ -0,0 +1,5 @@ +# MASVS-CODE: Code Quality + +Mobile apps have many data entry points, including the UI, IPC, network, and file system, which might receive data that has been inadvertently modified by untrusted actors. By treating this data as untrusted input and properly verifying and sanitizing it before use, developers can prevent classical injection attacks, such as SQL injection, XSS, or insecure deserialization. However, other common coding vulnerabilities, such as memory corruption flaws, are hard to detect in penetration testing but easy to prevent with secure architecture and coding practices. Developers should follow best practices such as the [OWASP Software Assurance Maturity Model (SAMM)](https://owaspsamm.org/model/) and [NIST.SP.800-218 Secure Software Development Framework (SSDF)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf) to avoid introducing these flaws in the first place. + +This category covers coding vulnerabilities that arise from external sources such as app data entry points, the OS, and third-party software components. Developers should verify and sanitize all incoming data to prevent injection attacks and bypass of security checks. They should also enforce app updates and ensure that the app runs up-to-date platforms to protect users from known vulnerabilities. diff --git a/Document/11-MASVS-RESILIENCE.md b/Document/11-MASVS-RESILIENCE.md new file mode 100644 index 000000000..1418fb055 --- /dev/null +++ b/Document/11-MASVS-RESILIENCE.md @@ -0,0 +1,12 @@ +# MASVS-RESILIENCE: Resilience Against Reverse Engineering and Tampering + +Defense-in-depth measures such as code obfuscation, anti-debugging, anti-tampering, etc. are important to increase app resilience against reverse engineering and specific client-side attacks. They add multiple layers of security controls to the app, making it more difficult for attackers to successfully reverse engineer and extract valuable intellectual property or sensitive data from it, which could result in: + +- The theft or compromise of valuable business assets such as proprietary algorithms, trade secrets, or customer data +- Significant financial losses due to loss of revenue or legal action +- Legal and reputational damage due to breach of contracts or regulations +- Damage to brand reputation due to negative publicity or customer dissatisfaction + +The controls in this category aim to ensure that the app is running on a trusted platform, prevent tampering at runtime and ensure the integrity of the app's intended functionality. Additionally, the controls impede comprehension by making it difficult to figure out how the app works using static analysis and prevent dynamic analysis and instrumentation that could allow an attacker to modify the code at runtime. + +However, note that the lack of any of these measures does not necessarily cause vulnerabilities - instead, they add threat-specific additional protection to apps which must also fulfil the rest of the OWASP MASVS security controls according to their specific threat models. diff --git a/Document/GLOSSARY.md b/Document/GLOSSARY.md deleted file mode 100644 index 2eace4c0b..000000000 --- a/Document/GLOSSARY.md +++ /dev/null @@ -1,161 +0,0 @@ -# Appendix A: Glossary - -## Address Space Layout Randomization (ASLR) - -A technique to make exploiting memory corruption bugs more difficult. - -## Application Security - -Application-level security focuses on the analysis of components that comprise the application layer of the Open Systems Interconnection Reference Model (OSI Model), rather than focusing on for example the underlying operating system or connected networks. - -## Application Security Verification - -The technical assessment of an application against the OWASP MASVS. - -## Application Security Verification Report - -A report that documents the overall results and supporting analysis produced by the verifier for a particular application. - -## Authentication - -The verification of the claimed identity of an application user. - -## Automated Verification - -The use of automated tools (either dynamic analysis tools, static analysis tools, or both) that use vulnerability signatures to find problems. - -## Black box testing - -It is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. - -## Component - -a self-contained unit of code, with associated disk and network interfaces that communicates with other components. - -## Cross-Site Scripting (XSS) - -A security vulnerability typically found in web applications allowing the injection of client-side scripts into content. - -## Cryptographic module - -Hardware, software, and/or firmware that implements cryptographic algorithms and/or generates cryptographic keys. - -## CWE - -CWE is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts. - -## DAST - -Dynamic application security testing (DAST) technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. - -## Design Verification - -The technical assessment of the security architecture of an application. - -## Dynamic Verification - -The use of automated tools that use vulnerability signatures to find problems during the execution of an application. - -## Globally Unique Identifier (GUID) - -a unique reference number used as an identifier in software. - -## Hyper Text Transfer Protocol (HTTP) - -An application protocol for distributed, collaborative, hypermedia information systems. It is the foundation of data communication for the World Wide Web. - -## Hardcoded keys - -Cryptographic keys which are stored in the device itself. - -## IPC - -Inter Process Communications,In IPC Processes communicate with each other and with the kernel to coordinate their activities. - -## Input Validation - -The canonicalization and validation of untrusted user input. - -## JAVA Bytecode - -Java bytecode is the instruction set of the Java virtual machine(JVM). Each bytecode is composed of one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters. - -## Malicious Code - -Code introduced into an application during its development unbeknownst to the application owner, which circumvents the application's intended security policy. Not the same as malware such as a virus or worm! - -## Malware - -Executable code that is introduced into an application during runtime without the knowledge of the application user or administrator. - -## Open Web Application Security Project (OWASP) - -The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. See: - -## Personally Identifiable Information (PII) - -PII is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. - -## PIE - -Position-independent executable (PIE) is a body of machine code that, being placed somewhere in the primary memory, executes properly regardless of its absolute address. - -## PKI - -A PKI is an arrangement that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). - -## SAST - -Static application security testing (SAST) is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the “inside out” in a nonrunning state. - -## SDLC - -Software development lifecycle. - -## Security Architecture - -An abstraction of an application's design that identifies and describes where and how security controls are used, and also identifies and describes the location and sensitivity of both user and application data. - -## Security Configuration - -The runtime configuration of an application that affects how security controls are used. - -## Security Control - -A function or component that performs a security check (e.g. an access control check) or when called results in a security effect (e.g. generating an audit record). - -## SQL Injection (SQLi) - -A code injection technique used to attack data driven applications, in which malicious SQL statements are inserted into an entry point. - -## SSO Authentication - -Single Sign On(SSO) occurs when a user logs in to one Client and is then signed in to other Clients automatically, regardless of the platform, technology, or domain the user is using. For example when you log in in google you automatically login in the youtube , docs and mail service. - -## Threat Modeling - -A technique consisting of developing increasingly refined security architectures to identify threat agents, security zones, security controls, and important technical and business assets. - -## Transport Layer Security - -Cryptographic protocols that provide communication security over the Internet - -## URI and URL - -A Uniform Resource Identifier is a string of characters used to identify a name or a web resource. A Uniform Resource Locator is often used as a reference to a resource. - -## User acceptance testing (UAT) - -Traditionally a test environment that behaves like the production environment where all software testing is performed before going live. - -## Verifier - -The person or team that is reviewing an application against the OWASP MASVS requirements. - -## Whitelist - -A list of permitted data or operations, for example a list of characters that are allowed to perform input validation. - -## X.509 Certificate - -An X.509 certificate is a digital certificate that uses the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. diff --git a/Document/SUMMARY.md b/Document/SUMMARY.md deleted file mode 100644 index 66a5024c1..000000000 --- a/Document/SUMMARY.md +++ /dev/null @@ -1,23 +0,0 @@ -# Table of Contents - -- [Changelog](CHANGELOG.md) -- [Foreword](0x01-Foreword.md) -- [Frontispiece](0x02-Frontispiece.md) -- [Using the MASVS](0x03-Using_the_MASVS.md) -- [Assessment and Certification](0x04-Assessment_and_Certification.md) - -## Security Requirements - -- [V1: Architecture, Design and Threat Modeling Requirements](0x06-V1-Architecture_design_and_threat_modelling_requireme.md) -- [V2: Data Storage and Privacy Requirements](0x07-V2-Data_Storage_and_Privacy_requirements.md) -- [V3: Cryptography Requirements](0x08-V3-Cryptography_Verification_Requirements.md) -- [V4: Authentication and Session Management Requirements](0x09-V4-Authentication_and_Session_Management_Requirements.md) -- [V5: Network Communication Requirements](0x10-V5-Network_communication_requirements.md) -- [V6: Platform Interaction Requirements](0x11-V6-Interaction_with_the_environment.md) -- [V7: Code Quality and Build Setting Requirements](0x12-V7-Code_quality_and_build_setting_requirements.md) -- [V8: Resilience Requirements](0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md) - -## Appendix - -- [Appendix A - Glossary](GLOSSARY.md) -- [Appendix B - References](0x91-Appendix-B_References.md) diff --git a/Document/images/GitHub_logo.png b/Document/images/GitHub_logo.png deleted file mode 100644 index ea6ff545a..000000000 Binary files a/Document/images/GitHub_logo.png and /dev/null differ diff --git a/Document/images/MASVS-levels.png b/Document/images/MASVS-levels.png deleted file mode 100644 index 62a601769..000000000 Binary files a/Document/images/MASVS-levels.png and /dev/null differ diff --git a/Document/images/OWASP_logo.png b/Document/images/OWASP_logo.png deleted file mode 100644 index 9baaef889..000000000 Binary files a/Document/images/OWASP_logo.png and /dev/null differ diff --git a/Document/images/donators.png b/Document/images/donators.png new file mode 100644 index 000000000..eccd9f192 Binary files /dev/null and b/Document/images/donators.png differ diff --git a/Document/images/license.png b/Document/images/license.png deleted file mode 100644 index 124d3ba4d..000000000 Binary files a/Document/images/license.png and /dev/null differ diff --git a/Document/images/masvs-mini-cover.png b/Document/images/masvs-mini-cover.png deleted file mode 100644 index c7985e14c..000000000 Binary files a/Document/images/masvs-mini-cover.png and /dev/null differ diff --git a/Document/images/masvs-progress.png b/Document/images/masvs-progress.png deleted file mode 100644 index 0d11cba63..000000000 Binary files a/Document/images/masvs-progress.png and /dev/null differ diff --git a/Document/images/owasp_mas_header.png b/Document/images/owasp_mas_header.png new file mode 100644 index 000000000..7f644b640 Binary files /dev/null and b/Document/images/owasp_mas_header.png differ diff --git a/Document/images/slack_logo.png b/Document/images/slack_logo.png deleted file mode 100644 index 6967050a0..000000000 Binary files a/Document/images/slack_logo.png and /dev/null differ diff --git a/Document/images/trusted-by-logos.png b/Document/images/trusted-by-logos.png new file mode 100644 index 000000000..28563a9f0 Binary files /dev/null and b/Document/images/trusted-by-logos.png differ diff --git a/Document/images/twitter_logo.png b/Document/images/twitter_logo.png deleted file mode 100644 index b52f15964..000000000 Binary files a/Document/images/twitter_logo.png and /dev/null differ diff --git a/Document/metadata.yml b/Document/metadata.yml deleted file mode 100644 index c7700ff67..000000000 --- a/Document/metadata.yml +++ /dev/null @@ -1,3 +0,0 @@ -language: 'en' -languagetext: '' -toc_title: 'Table of Contents' diff --git a/LANGS.md b/LANGS.md deleted file mode 100644 index 9ae4b7102..000000000 --- a/LANGS.md +++ /dev/null @@ -1,10 +0,0 @@ -# Languages - -- [English](Document/) -- [German](Document-de/) -- [Español](Document-es/) -- [French](Document-fr/) -- [Japanese](Document-ja/) -- [Korean](Document-ko/) -- [Russian](Document-ru/) -- [Traditional Chinese](Document-zhtw/) diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md index 30556311b..2f5dd0bb9 100644 --- a/PULL_REQUEST_TEMPLATE.md +++ b/PULL_REQUEST_TEMPLATE.md @@ -1,10 +1,5 @@ -Thank you for submitting a Pull Request to the Mobile Application Security Verification Standard. Please make sure that: - -- [ ] Your PR is linked to an issue. -- [ ] Your PR follows the [contribution guidelines](https://github.com/OWASP/owasp-masvs/blob/master/CONTRIBUTING.md "Contribution guidelines") -- [ ] All links are valid and use HTTPS and have been formatted as [TEXT](URL “NAME”) -- [ ] In case of a translation: have you made sure that the translation from EN is as close to the EN document as possible? - This PR covers issue #< insert number here >. -If your pull-request has a focus of rewriting a requirement and/or adding a new one, please make sure you have a backing issue in which your change has been discussed and agreed. If there is none, then your PR will be closed without further review. +--- + +> Note: Thank you for submitting a Pull Request to the OWASP MASVS repo! By opening a PR you're agreeing with our [contribution guidelines](https://github.com/OWASP/owasp-masvs/blob/master/CONTRIBUTING.md "Contribution guidelines"). diff --git a/README.md b/README.md index b0f058e1f..26b0fb157 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ - + # OWASP Mobile Application Security Verification Standard (MASVS) @@ -62,7 +62,7 @@ MAS Advocates are industry adopters of the OWASP MASVS and MASTG who have invest @@ -82,46 +82,4 @@ The MASVS is an open source effort and we welcome all kinds of contributions and - 💡 [Propose ideas or suggest improvements](https://github.com/OWASP/owasp-masvs/discussions/categories/ideas) (if it qualifies we'll promote it to an [Issue](https://github.com/OWASP/owasp-masvs/issues "Github issues")) - 📄 [Create a Pull Request](https://github.com/OWASP/owasp-masvs/pulls) for concrete fixes (e.g. grammar/typos) or content already approved by the core team. -Before you start contributing, please check our [contribution guide](https://github.com/OWASP/owasp-masvs/blob/master/CONTRIBUTING.md "Contribution Guide") which should get you started. If you have any doubts [please contact us](#connect-with-us). - -## MASVS Translations - -The MASVS is available in different languages: - -- [Chinese (Simplified) - ZHCN](https://github.com/OWASP/owasp-masvs/tree/master/Document-zhcn "Simplified Chinese (ZHCN)") -- [Chinese (Traditional) - ZHTW](https://github.com/OWASP/owasp-masvs/tree/master/Document-zhtw "Traditional Chinese (ZHTW)") -- [English](https://github.com/OWASP/owasp-masvs/tree/master/Document "English") -- [French](https://github.com/OWASP/owasp-masvs/tree/master/Document-fr "French") -- [German](https://github.com/OWASP/owasp-masvs/tree/master/Document-de "German") -- [Hindi](https://github.com/OWASP/owasp-masvs/tree/master/Document-hi "Hindi") -- [Japanese](https://github.com/OWASP/owasp-masvs/tree/master/Document-ja "Japanese") -- [Korean](https://github.com/OWASP/owasp-masvs/tree/master/Document-ko "Korean") -- [Persian](https://github.com/OWASP/owasp-masvs/tree/master/Document-fa "Persian") -- [Portuguese (Brazil)](https://github.com/OWASP/owasp-masvs/tree/master/Document-ptbr "Brazilian Portuguese") -- [Portuguese (Portugal)](https://github.com/OWASP/owasp-masvs/tree/master/Document-ptpt "Portuguese Portugal") -- [Russian](https://github.com/OWASP/owasp-masvs/tree/master/Document-ru "Russian") -- [Spanish](https://github.com/OWASP/owasp-masvs/tree/master/Document-es "Spanish") -- [Turkish](https://github.com/OWASP/owasp-masvs/tree/master/Document-tr "Turkish") -- [Greek](https://github.com/OWASP/owasp-masvs/tree/master/Document-gr "Greek") - -## Other Formats - -See the [latest release](https://github.com/OWASP/owasp-masvs/releases/latest). Else you can export it yourself in [other formats](tools/README.md#other-formats). - -## Table-of-Contents - -- [Foreword](https://mas.owasp.org/MASVS/Intro/0x01-Foreword) -- [Frontispiece](https://mas.owasp.org/MASVS/Intro/0x02-Frontispiece) -- [The Mobile Application Security Verification Standard](https://mas.owasp.org/MASVS/Intro/0x03-Using_the_MASVS) -- [Assessment and Verification](https://mas.owasp.org/MASVS/Intro/0x04-Assessment_and_Certification) -- [V1: Architecture, Design and Threat Modeling Requirements](https://mas.owasp.org/MASVS/Controls/0x06-V1-Architecture_design_and_threat_modelling_requireme) -- [V2: Data Storage and Privacy Requirements](https://mas.owasp.org/MASVS/Controls/0x07-V2-Data_Storage_and_Privacy_requirements) -- [V3: Cryptography Requirements](https://mas.owasp.org/MASVS/Controls/0x08-V3-Cryptography_Verification_Requirements) -- [V4: Authentication and Session Management Requirements](https://mas.owasp.org/MASVS/Controls/0x09-V4-Authentication_and_Session_Management_Requirements) -- [V5: Network Communication Requirements](https://mas.owasp.org/MASVS/Controls/0x10-V5-Network_communication_requirements) -- [V6: Environmental Interaction Requirements](https://mas.owasp.org/MASVS/Controls/0x11-V6-Interaction_with_the_environment) -- [V7: Code Quality and Build Setting Requirements](https://mas.owasp.org/MASVS/Controls/0x12-V7-Code_quality_and_build_setting_requirements) -- [V8: Resiliency Against Reverse Engineering Requirements](https://mas.owasp.org/MASVS/Controls/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements) -- [Appendix A: Glossary](https://mas.owasp.org/MASVS/Appendix/0x90-Appendix-A_Glossary) -- [Appendix B: References](https://mas.owasp.org/MASVS/Appendix/0x91-Appendix-B_References) -- [Release notes](CHANGELOG.md) +Before you start contributing, please check our [contribution guide](https://mas.owasp.org/contributing/) which should get you started. If you have any doubts [please contact us](#connect-with-us). diff --git a/controls/MASVS-AUTH-1.md b/controls/MASVS-AUTH-1.md new file mode 100644 index 000000000..bdca12fbe --- /dev/null +++ b/controls/MASVS-AUTH-1.md @@ -0,0 +1,9 @@ +# MASVS-AUTH-1 + +## Control + +The app uses secure authentication and authorization protocols and follows the relevant best practices. + +## Description + +Most apps connecting to a remote endpoint require user authentication and also enforce some kind of authorization. While the enforcement of these mechanisms must be on the remote endpoint, the apps also have to ensure that it follows all the relevant best practices to ensure a secure use of the involved protocols. diff --git a/controls/MASVS-AUTH-2.md b/controls/MASVS-AUTH-2.md new file mode 100644 index 000000000..1a7d6a671 --- /dev/null +++ b/controls/MASVS-AUTH-2.md @@ -0,0 +1,9 @@ +# MASVS-AUTH-2 + +## Control + +The app performs local authentication securely according to the platform best practices. + +## Description + +Many apps allow users to authenticate via biometrics or a local PIN code. These authentication mechanisms need to be correctly implemented. Additionally, some apps might not have a remote endpoint, and rely fully on local app authentication. diff --git a/controls/MASVS-AUTH-3.md b/controls/MASVS-AUTH-3.md new file mode 100644 index 000000000..480a05bea --- /dev/null +++ b/controls/MASVS-AUTH-3.md @@ -0,0 +1,9 @@ +# MASVS-AUTH-3 + +## Control + +The app secures sensitive operations with additional authentication. + +## Description + +Some additional form of authentication is often desirable for sensitive actions inside the app. This can be done in different ways (biometric, pin, MFA code generator, email, deep links, etc) and they all need to be implemented securely. diff --git a/controls/MASVS-CODE-1.md b/controls/MASVS-CODE-1.md new file mode 100644 index 000000000..f4484bedd --- /dev/null +++ b/controls/MASVS-CODE-1.md @@ -0,0 +1,9 @@ +# MASVS-CODE-1 + +## Control + +The app requires an up-to-date platform version. + +## Description + +Every release of the mobile OS includes security patches and new security features. By supporting older versions, apps stay vulnerable to well-known threats. This control ensures that the app is running on an up-to-date platform version so that users have the latest security protections. diff --git a/controls/MASVS-CODE-2.md b/controls/MASVS-CODE-2.md new file mode 100644 index 000000000..e7fa97b3b --- /dev/null +++ b/controls/MASVS-CODE-2.md @@ -0,0 +1,9 @@ +# MASVS-CODE-2 + +## Control + +The app has a mechanism for enforcing app updates. + +## Description + +Sometimes critical vulnerabilities are discovered in the app when it is already in production. This control ensures that there is a mechanism to force the users to update the app before they can continue using it. diff --git a/controls/MASVS-CODE-3.md b/controls/MASVS-CODE-3.md new file mode 100644 index 000000000..920ad7a92 --- /dev/null +++ b/controls/MASVS-CODE-3.md @@ -0,0 +1,9 @@ +# MASVS-CODE-3 + +## Control + +The app only uses software components without known vulnerabilities. + +## Description + +To be truly secure, a full whitebox assessment should have been performed on all app components. However, as it usually happens with e.g. for third-party components this is not always feasible and not typically part of a penetration test. This control covers "low-hanging fruit" cases, such as those that can be detected just by scanning libraries for known vulnerabilities. diff --git a/controls/MASVS-CODE-4.md b/controls/MASVS-CODE-4.md new file mode 100644 index 000000000..463f1c165 --- /dev/null +++ b/controls/MASVS-CODE-4.md @@ -0,0 +1,9 @@ +# MASVS-CODE-4 + +## Control + +The app validates and sanitizes all untrusted inputs. + +## Description + +Apps have many data entry points including the UI, IPC, the network, the file system, etc. This incoming data might have been inadvertently modified by untrusted actors and may lead to bypass of critical security checks as well as classical injection attacks such as SQL injection, XSS or insecure deserialization. This control ensures that this data is treated as untrusted input and is properly verified and sanitized before it's used. diff --git a/controls/MASVS-CRYPTO-1.md b/controls/MASVS-CRYPTO-1.md new file mode 100644 index 000000000..9f361a0ba --- /dev/null +++ b/controls/MASVS-CRYPTO-1.md @@ -0,0 +1,9 @@ +# MASVS-CRYPTO-1 + +## Control + +The app employs current strong cryptography and uses it according to industry best practices. + +## Description + +Cryptography plays an especially important role in securing the user's data - even more so in a mobile environment, where attackers having physical access to the user's device is a likely scenario. This control covers general cryptography best practices, which are typically defined in external standards. diff --git a/controls/MASVS-CRYPTO-2.md b/controls/MASVS-CRYPTO-2.md new file mode 100644 index 000000000..49e47b17a --- /dev/null +++ b/controls/MASVS-CRYPTO-2.md @@ -0,0 +1,9 @@ +# MASVS-CRYPTO-2 + +## Control + +The app performs key management according to industry best practices. + +## Description + +Even the strongest cryptography would be compromised by poor key management. This control covers the management of cryptographic keys throughout their lifecycle, including key generation, storage and protection. diff --git a/controls/MASVS-NETWORK-1.md b/controls/MASVS-NETWORK-1.md new file mode 100644 index 000000000..84841ebe5 --- /dev/null +++ b/controls/MASVS-NETWORK-1.md @@ -0,0 +1,9 @@ +# MASVS-NETWORK-1 + +## Control + +The app secures all network traffic according to the current best practices. + +## Description + +Ensuring data privacy and integrity of any data in transit is critical for any app that communicates over the network. This is typically done by encrypting data and authenticating the remote endpoint, as TLS does. However, there are many ways for a developer to disable the platform secure defaults, or bypass them completely by using low-level APIs or third-party libraries. This control ensures that the app is in fact setting up secure connections in any situation. diff --git a/controls/MASVS-NETWORK-2.md b/controls/MASVS-NETWORK-2.md new file mode 100644 index 000000000..02c2e1da5 --- /dev/null +++ b/controls/MASVS-NETWORK-2.md @@ -0,0 +1,9 @@ +# MASVS-NETWORK-2 + +## Control + +The app performs identity pinning for all remote endpoints under the developer's control. + +## Description + +Instead of trusting all the default root CAs of the framework or device, this control will make sure that only very specific CAs are trusted. This practice is typically called certificate pinning or public key pinning. diff --git a/controls/MASVS-PLATFORM-1.md b/controls/MASVS-PLATFORM-1.md new file mode 100644 index 000000000..27769eff7 --- /dev/null +++ b/controls/MASVS-PLATFORM-1.md @@ -0,0 +1,9 @@ +# MASVS-PLATFORM-1 + +## Control + +The app uses IPC mechanisms securely. + +## Description + +Apps typically use platform provided IPC mechanisms to intentionally expose data or functionality. Both installed apps and the user are able to interact with the app in many different ways. This control ensures that all interactions involving IPC mechanisms happen securely. diff --git a/controls/MASVS-PLATFORM-2.md b/controls/MASVS-PLATFORM-2.md new file mode 100644 index 000000000..ed37e4df5 --- /dev/null +++ b/controls/MASVS-PLATFORM-2.md @@ -0,0 +1,9 @@ +# MASVS-PLATFORM-2 + +## Control + +The app uses WebViews securely. + +## Description + +WebViews are typically used by apps that have a need for increased control over the UI. This control ensures that WebViews are configured securely to prevent sensitive data leakage as well as sensitive functionality exposure (e.g. via JavaScript bridges to native code). diff --git a/controls/MASVS-PLATFORM-3.md b/controls/MASVS-PLATFORM-3.md new file mode 100644 index 000000000..47579d788 --- /dev/null +++ b/controls/MASVS-PLATFORM-3.md @@ -0,0 +1,9 @@ +# MASVS-PLATFORM-3 + +## Control + +The app uses the user interface securely. + +## Description + +Sensitive data has to be displayed in the UI in many situations (e.g. passwords, credit card details, OTP codes in notifications). This control ensures that this data doesn't end up being unintentionally leaked due to platform mechanisms such as auto-generated screenshots or accidentally disclosed via e.g. shoulder surfing or sharing the device with another person. diff --git a/controls/MASVS-RESILIENCE-1.md b/controls/MASVS-RESILIENCE-1.md new file mode 100644 index 000000000..0306619cb --- /dev/null +++ b/controls/MASVS-RESILIENCE-1.md @@ -0,0 +1,9 @@ +# MASVS-RESILIENCE-1 + +## Control + +The app validates the integrity of the platform. + +## Description + +Running on a platform that has been tampered with can be very dangerous for apps, as this may disable certain security features, putting the data of the app at risk. Trusting the platform is essential for many of the MASVS controls relying on the platform being secure (e.g. secure storage, biometrics, sandboxing, etc.). This control tries to validate that the OS has not been compromised and its security features can thus be trusted. diff --git a/controls/MASVS-RESILIENCE-2.md b/controls/MASVS-RESILIENCE-2.md new file mode 100644 index 000000000..2048f2590 --- /dev/null +++ b/controls/MASVS-RESILIENCE-2.md @@ -0,0 +1,9 @@ +# MASVS-RESILIENCE-2 + +## Control + +The app implements anti-tampering mechanisms. + +## Description + +Apps run on a user-controlled device, and without proper protections it's relatively easy to run a modified version locally (e.g. to cheat in a game, or enable premium features without paying), or upload a backdoored version of it to third-party app stores. This control tries to ensure the integrity of the app's intended functionality by preventing modifications to the original code and resources. diff --git a/controls/MASVS-RESILIENCE-3.md b/controls/MASVS-RESILIENCE-3.md new file mode 100644 index 000000000..cdce9a149 --- /dev/null +++ b/controls/MASVS-RESILIENCE-3.md @@ -0,0 +1,9 @@ +# MASVS-RESILIENCE-3 + +## Control + +The app implements anti-static analysis mechanisms. + +## Description + +Understanding the internals of an app is typically the first step towards tampering with it (either dynamically, or statically). This control tries to impede comprehension by making it as difficult as possible to figure out how an app works using static analysis. diff --git a/controls/MASVS-RESILIENCE-4.md b/controls/MASVS-RESILIENCE-4.md new file mode 100644 index 000000000..3a0d3329e --- /dev/null +++ b/controls/MASVS-RESILIENCE-4.md @@ -0,0 +1,9 @@ +# MASVS-RESILIENCE-4 + +## Control + +The app implements anti-dynamic analysis techniques. + +## Description + +Sometimes pure static analysis is very difficult and time consuming so it typically goes hand in hand with dynamic analysis. Observing and manipulating an app during runtime makes it much easier to decipher its behavior. This control aims to make it as difficult as possible to perform dynamic analysis, as well as prevent dynamic instrumentation which could allow an attacker to modify the code at runtime. diff --git a/controls/MASVS-STORAGE-1.md b/controls/MASVS-STORAGE-1.md new file mode 100644 index 000000000..de44ce4e2 --- /dev/null +++ b/controls/MASVS-STORAGE-1.md @@ -0,0 +1,9 @@ +# MASVS-STORAGE-1 + +## Control + +The app securely stores sensitive data. + +## Description + +Apps handle sensitive data coming from many sources such as the user, the backend, system services or other apps on the device and usually need to store it locally. The storage locations may be private to the app (e.g. its internal storage) or be public and therefore accessible by the user or other installed apps (e.g. public folders such as Downloads). This control ensures that any sensitive data that is intentionally stored by the app is properly protected independently of the target location. diff --git a/controls/MASVS-STORAGE-2.md b/controls/MASVS-STORAGE-2.md new file mode 100644 index 000000000..900306f6c --- /dev/null +++ b/controls/MASVS-STORAGE-2.md @@ -0,0 +1,9 @@ +# MASVS-STORAGE-2 + +## Control + +The app prevents leakage of sensitive data. + +## Description + +There are cases when sensitive data is unintentionally stored or exposed to publicly accessible locations; typically as a side-effect of using certain APIs, system capabilities such as backups or logs. This control covers this kind of unintentional leaks where the developer actually has a way to prevent it. diff --git a/cover.jpg b/cover.jpg deleted file mode 100644 index 5ecb32f4c..000000000 Binary files a/cover.jpg and /dev/null differ diff --git a/cover.pdf b/cover.pdf new file mode 100644 index 000000000..4c29bcefe Binary files /dev/null and b/cover.pdf differ diff --git a/cover.png b/cover.png new file mode 100644 index 000000000..0204640fc Binary files /dev/null and b/cover.png differ diff --git a/missfont.log b/missfont.log deleted file mode 100644 index c7ea7fcf3..000000000 --- a/missfont.log +++ /dev/null @@ -1,7 +0,0 @@ -mktextfm NotoSans -mktextfm NotoSans -mktextfm Nazli -mktextfm Nazli -mktextfm Nazli -mktextfm Nazli -mktextfm Nazli diff --git a/tools/Apply_Link_Check.sh b/tools/Apply_Link_Check.sh deleted file mode 100755 index 3b0575122..000000000 --- a/tools/Apply_Link_Check.sh +++ /dev/null @@ -1,73 +0,0 @@ -#!/bin/bash -# Script taken and adapted from https://github.com/OWASP/CheatSheetSeries/blob/master/scripts/Apply_Link_Check.sh and adapted for multi-lingual processing -# Script in charge of auditing the released MD files in order to detect dead links - - - -apply_link_check_lang() { - echo "Checking links for language $1" - if test -f "../link-check-result-$1.out"; then - rm ../link-check-result-$1.out - fi - cd ../Document-$1 - find . -name \*.md -exec markdown-link-check -q -c ../.markdownlinkcheck.json {} \; 1>../link-check-result-$1.out 2>&1 - - errors=`grep -c "ERROR:" ../link-check-result-$1.out` - content=`cat ../link-check-result-$1.out` - if [[ $errors != "0" ]] - then - echo "[!] Error(s) found by the Links validator for $1: $errors pages have dead links! Verbose output in /link-check-result-$1.out" - else - echo "[+] No error found by the Links validator for $1." - rm ../link-check-result-$1.out - fi -} - -apply_link_check_en() { - echo "Checking links for language EN" - if test -f "../link-check-result.out"; then - rm ../link-check-result.out - fi - cd ../Document - find . -name \*.md -exec markdown-link-check -q -c ../.markdownlinkcheck.json {} \; 1>../link-check-result.out 2>&1 - errors=`grep -c "ERROR:" ../link-check-result.out` - content=`cat ../link-check-result.out` - if [[ $errors != "0" ]] - then - echo "[!] Error(s) found by the Links validator for EN: $errors pages have dead links! Verbose output in /link-check-result.out" - else - echo "[+] No error found by the Links validator for EN." - rm ../link-check-result.out - fi -} - -finalize () { - #getlink-result-total - if test -f "../link-check-result-all-lang.out"; then - rm ../lint-check-result-all-lang.out - fi - cd .. - cat link-check-result.out link-check-result-de.out link-check-result-es.out link-check-result-fr.out link-check-result-ja.out link-check-result-ru.out link-check-result-zhtw.out > link-check-result-all-lang.out - - errors_total=`grep -c "ERROR:" link-check-result-all-lang.out` - echo "Errors total: $errors_total" - if [[ $errors_total != "0" ]] - then - exit $errors_total - fi -} - -npm install -g markdown-link-check - -apply_link_check_en -apply_link_check_lang de -apply_link_check_lang es -apply_link_check_lang fa -apply_link_check_lang fr -apply_link_check_lang hi -apply_link_check_lang ja -apply_link_check_lang ko -apply_link_check_lang ru -apply_link_check_lang zhtw -apply_link_check_lang zhcn -finalize diff --git a/tools/Apply_Linter_Check.sh b/tools/Apply_Linter_Check.sh deleted file mode 100755 index 3472391c2..000000000 --- a/tools/Apply_Linter_Check.sh +++ /dev/null @@ -1,75 +0,0 @@ -#!/bin/bash -# Script taken from https://github.com/OWASP/CheatSheetSeries/blob/master/scripts/Apply_Linter_Check.sh and adapted for multi-langual processing -# Script in charge of auditing the released MD files with the linter policy defined at project level - -cd .. - -newline_at_eof() -{ - if [ -z "$(tail -c 1 "$1")" ] - then - echo "all good" - else - echo "No newline at end of file!" - sed -i '' -e '$a\' $1 - fi -} - -apply_lint_check_en(){ - rm linter-result.out - markdownlint -c .markdownlint.json -o linter-result.out Document - errors=`wc -m linter-result.out | cut -d' ' -f1` - content=`cat linter-result.out` - if [[ $errors != "0" ]] - then - echo "[!] $errors Error(s) found by the Linter for language en: $content" - newline_at_eof linter-result.out - else - echo "[+] No error found by the Linter for language en." - rm linter-result.out - fi -} - -apply_lint_check_lang(){ - rm linter-result-$1.out - markdownlint -c .markdownlint.json -o linter-result-$1.out Document-$1 - errors=`wc -m linter-result-$1.out | cut -d' ' -f1` - content=`cat linter-result-$1.out` - if [[ $errors != "0" ]] - then - echo "[!] $errors Error(s) found by the Linter for language $1: $content" - newline_at_eof linter-result-$1.out - else - echo "[+] No error found by the Linter for language $1." - rm linter-result-$1.out - fi -} - -finalize() { - #getlint-result-total - if test -f "lint-check-result-all-lang.out"; then - rm lint-check-result-all-lang.out - fi - cat linter-result.out linter-result-de.out linter-result-es.out linter-result-fa.out linter-result-fr.out linter-result-ja.out linter-result-ru.out linter-result-zhtw.out > lint-check-result-all-lang.out - errors_total=$(wc -l lint-check-result-all-lang.out) - errors_total_number=$(echo $errors_total| cut -d' ' -f 1) - echo "Errors total: $errors_total_number" - if [[ $errors_total_number != "0" ]] - then - exit $(($errors_total_number)) - fi -} - -npm install -g markdownlint -apply_lint_check_en -apply_lint_check_lang de -apply_lint_check_lang es -apply_lint_check_lang fa -apply_lint_check_lang fr -apply_lint_check_lang hi -apply_lint_check_lang ja -apply_lint_check_lang ko -apply_lint_check_lang ru -apply_lint_check_lang zhtw -apply_lint_check_lang zhcn -finalize diff --git a/tools/README.md b/tools/README.md deleted file mode 100644 index 806cef48d..000000000 --- a/tools/README.md +++ /dev/null @@ -1,111 +0,0 @@ -# Tools - -## Overview - -This directory is for tools that are used to generate the necessary files for our release-channels. - -Channels: - -- Gitbook: currenlty using @sushi2k's repository (https://github.com/sushi2k/owasp-masvs which is synced automatically via https://github.com/apps/pull. -- Github actions & Github releases: We use Github actions to build and verify the documents in an automated fashion as well as build releases. - -Files: - -- Apply_Link_Check.sh: Tool to inspect the links in the document folders for every language. -- Apply_Lint_Check.sh: Tool to inspect the markdown files their markup in the document folders for every language. -- export.py: Python script to generate a CSV, JSON or XML version of the MASVS. -- masvs.py: Python script used by export.py -- reference.docx: Template file used for generating the word doc using `generate_document.sh`. - -## Release process - -1. Update the CHANGELOG.md in each language directory and add a release statement and summary of the changes since the last release. Update the RECENT_CHANGES.txt in the tools folder. Add it also to the CHANGELOG.md in the root directory. -2. Commit the changes (with message `Release `) -3. Merge the PR into master -4. Checkout master and pull changes: - - ```bash - $ git checkout master - $ git pull - ``` - -5. Push a tag with the new version: - - ```bash - $ git tag -a v -m "Release message" - $ git push origin v - ``` - - > The letter `v` need to be part of the tag name to trigger the release Github action. The tag name will become the version title of the release. The content of the RECENT_CHANGES file will become the body text of the release (be sure it includes the actual title of the release). - -6. Verify that Github Action was triggered. The Github action "Upload Release Asset" need to be triggered. This might take 5-10 minutes. -7. Update OWASP Wiki if necessary -8. Tweet about it with @OWASP_MAS, Linkedin and OWASP Slack - -In case something went wrong and we need to remove the release: - -1. Delete the tag locally and remotely: - - ```bash - $ git tag -d # delete the tag locally - $ git push origin :refs/tags/ # delete the tag remotely - ``` - -2. Go to Github release page . The release you removed is now in "draft". Click on edit and discard/delete the release. - -## Adding another language - -When you want to add another language: - -1. Create a folder with the language of choice. -2. Extend `Apply_Link_Check.sh` and `Apply_Linter_Check.sh` with the new folder and make sure you do not end up with dead links or Markdown errors. -3. Update `.github/workflows/checkLint.yml` and add the new folder to the lint checker. -4. Add the `LANGUAGE-METADATA` to the folder. -5. Test the generation of the document by running `tools/docker/run_docker_masvs_generation_on_local.sh` and update `tools/docker/pandoc_makedocs.sh` wherever necessary. See [the docker README.MD for more details on any necessary update processes](docker/README.md). -6. Add the language to the list of languages in `export.py` -7. Update `.github/workflows/docgenerator.yml` and add the action steps for the new language. -8. Update `../LANGS.md` to include the new language. -9. Extend the `../README.md` with the newly available language. - - -## Other Formats - -### Create new PDF, EPUB and Word document - -> These steps were tested on macOS, Kali and Ubuntu 18 - -You can find the documents on the [release page](https://github.com/OWASP/owasp-masvs/releases). If you want to generate the documents yourself, execute the following steps: - -- The document creation uses a Docker container, so make sure that you have [Docker installed](https://www.docker.com/products/docker-desktop). - -- Clone the MASVS repository: - -```shell -$ git clone https://github.com/OWASP/owasp-masvs/ -$ cd owasp-masvs/ -``` - -- Run the document generation script for the chosen language with latin-fonts: - -```shell -$ ./tools/docker/pandoc_makedocs.sh Document-de LATEST -``` - -- "Document-de" specifies the folder of the language that is used to generate the documents. Simply replace it with the language you want to use. -- "LATEST" is the string that will be printed on the cover. - -- For languages that require non-latin fonts (Chinese, Farsi, Hindi, Japanese, Korean, Russian etc.) the `stable-full` version of Pandocker is required. You can activate it with the `TAG` environment variable, like this: - -```shell -$ TAG=stable-full ./tools/docker/pandoc_makedocs.sh Document-hi LATEST -``` - -This produces PDF, EPUB and DOCX files in the root of the project. - -### Exporting to JSON, XML and CSV - -The repository contains a Python tool for converting the requirements into various formats. Clone the repo and run `export.py` from the tools folder. - -```shell -export.py [-h] [--format {json,xml,csv}] [--lang {es/ru/en/fr/de/zhtw/ja}] -``` diff --git a/tools/cover.xcf b/tools/cover.xcf deleted file mode 100644 index 5009b0037..000000000 Binary files a/tools/cover.xcf and /dev/null differ diff --git a/tools/custom-reference.docx b/tools/custom-reference.docx deleted file mode 100644 index be71cc12a..000000000 Binary files a/tools/custom-reference.docx and /dev/null differ diff --git a/tools/docker/cover.tex b/tools/docker/cover.tex index 037a3247b..b63c80c1c 100644 --- a/tools/docker/cover.tex +++ b/tools/docker/cover.tex @@ -1,15 +1,20 @@ % IMPORTANT NOTE this file requires latex-header.tex -% cover.jpg is in the root folder (owasp-masvs/) -% Version text is written at (X,Y), where (0, 0) is the lower left corner of the page. -% This file requires the following pandoc metadata variables: -% * $languagetext$ -% * $version$ -% * $a$ +% The cover is created first using Google Drawings: https://docs.google.com/drawings/d/1i0NIJq3ChVrdQ-0YdqcYGeWUw9QCzd61gDBp05dP7b8/edit?usp=sharing +% To best fit the PDF, in Google Drawings we go to "File > Page Setup" and set Width = 2480px and Height = 3508px. +% It is exported as cover.pdf and lives in the root folder (owasp-mastg/) + +% The version text is written dynamically using the code in this file +% The used latex overlay uses the coordinates (X,Y), where (0, 0) is the lower left corner of the page. + +% NOTE: For non-release versions e.g. v1.4.1-70281c8 it might look like the version string is not correctly located but it is for release versions e.g. v1.5.0. +% The coordinates given below are for the release version and are correct. + +% This file requires the following pandoc metadata variable: $masvs_version$ \thispagestyle{empty} % remove page numbers % https://tex.stackexchange.com/questions/136900/insert-a-full-page-image \incgraph[documentpaper, - overlay={\node[white] at (page.center) {\huge $languagetext$};\node[white] at (17.7,11.7) {\Huge Version $version$};}] - [width=\paperwidth,height=\paperheight]{cover.jpg} + overlay={\node[white] at (4.0,18.0) {\Large Version $masvs_version$};}] + [width=\paperwidth,height=\paperheight]{cover.pdf} \ No newline at end of file diff --git a/tools/docker/first_page.tex b/tools/docker/first_page.tex index fdc860f47..767b1d58f 100644 --- a/tools/docker/first_page.tex +++ b/tools/docker/first_page.tex @@ -1,6 +1,28 @@ \thispagestyle{empty} % remove page numbers -OWASP Mobile Application Security Verification Standard +\textbf{OWASP Mobile Application Security Verification Standard (MASVS)} +$mastg_version$ released \today \\ -Version $version$ \today +Release Notes: \url{https://github.com/OWASP/owasp-masvs/releases/tag/$masvs_version$} \\ + +Online version available at \url{https://github.com/OWASP/owasp-masvs/releases/tag/$masvs_version$} \\ \\ \\ + + +Supported by the OWASP Mobile Application Security Testing Guide (MASTG) $mastg_version$ \\ + +Online version available at \url{https://github.com/OWASP/owasp-masvs/releases/tag/$masvs_version$} \\ \\ \\ \\ \\ + + + +The OWASP MASTG and the MASVS are part of the OWASP Mobile Application Security (MAS) Project. \\ +\url{https://mas.owasp.org} \\ \\ + +Copyright © The OWASP Foundation. \\ + +License: Creative Commons Attribution-ShareAlike 4.0 International. +For any reuse or distribution, you must make clear to others the license terms of this work. \\ +\url{https://creativecommons.org/licenses/by-sa/4.0/} \\ \\ + + +\emph{Cover design by Carlos Holguera} \ No newline at end of file diff --git a/tools/docker/imagereplace.sed b/tools/docker/imagereplace.sed index 9a9e03993..61f82b811 100644 --- a/tools/docker/imagereplace.sed +++ b/tools/docker/imagereplace.sed @@ -1,3 +1,8 @@ -s//\![\2](\1){ width=\3 height=\4}/g -s//\![\2](\1){ width=\3}/g -s//\![\2](\1)/g \ No newline at end of file +s//\![\2](\1){width=\3 height=\4}/g +s//\![\2](\1){width=\3 height=\4}/g +s//\![\2](\1){width=\3}/g +s//\![\2](\1){width=\3}/g +s//\![\1](\1){width=\2}/g +s//\![\2](\1)/g +s//\![\2](\1)/g +s//\![\1](\1)/g \ No newline at end of file diff --git a/tools/docker/latex-header.tex b/tools/docker/latex-header.tex index 63d536445..4eec349ff 100644 --- a/tools/docker/latex-header.tex +++ b/tools/docker/latex-header.tex @@ -5,7 +5,7 @@ \hypersetup{ pdftitle={OWASP Mobile Application Security Verification Standard}, - pdfauthor={Sven Schleier, Jeroen Willemsen and Carlos Holguera}, + pdfauthor={Bernhard Mueller, Sven Schleier, Jeroen Willemsen, Carlos Holguera and Jeroen Beckers}, pdfsubject={The Mobile Application Security Verification Standard (MASVS) is a standard for mobile app security.}, pdfkeywords={Mobile Security,iOS,Android,OWASP} } @@ -42,6 +42,32 @@ %%\setCJKmainfont{Noto Sans CJK {{CJK-LANG}}} %JP,SC,TC,KR %%\renewcommand\CJKglue{}% get proper linebreaking if spaces are provided +\usepackage{underscore} % Solves breaking line for **Protocol_KeyExchangeAlgorithm_WITH_BlockCipher_IntegrityCheckAlgorithm** + +% The next 2 block fix several issues with non-breaking texttt environments: +% "The module app.package.attacksurface" +% "in clear text in /data/data//shared_-" +% "For example, \e search.quiet=true;" + +\newcommand*\justify{% + \fontdimen2\font=0.4em% interword space + \fontdimen3\font=0.2em% interword stretch + \fontdimen4\font=0.1em% interword shrink + \fontdimen7\font=0.1em% extra space + \hyphenchar\font=`\-% allowing hyphenation +} + +\renewcommand{\texttt}[1]{% + \begingroup + \ttfamily + \begingroup\lccode`~=`/\lowercase{\endgroup\def~}{/\discretionary{}{}{}}% + \begingroup\lccode`~=`[\lowercase{\endgroup\def~}{[\discretionary{}{}{}}% + \begingroup\lccode`~=`.\lowercase{\endgroup\def~}{.\discretionary{}{}{}}% + \catcode`/=\active\catcode`[=\active\catcode`.=\active + \justify\scantokens{#1\noexpand}% + \endgroup +} + %% Workaround for pandoc bug #8460 %% https://github.com/jgm/pandoc/issues/8460 \newenvironment{RTL}{\beginR}{\endR} diff --git a/tools/docker/pandoc_makedocs.sh b/tools/docker/pandoc_makedocs.sh index 82f754898..af94ef6b9 100755 --- a/tools/docker/pandoc_makedocs.sh +++ b/tools/docker/pandoc_makedocs.sh @@ -4,38 +4,41 @@ set -eo pipefail # Input variables FOLDER=${1:-Document} -VERSION=${2:-SNAPSHOT} +MASVS_VERSION=${2:-SNAPSHOT} # You can also use the environment variables below to adapt the build process IMG=${IMG:-dalibo/pandocker} TAG=${TAG:-stable} # /!\ use stable-full for non-european languages LATEX_TEMPLATE=${LATEX_TEMPLATE:-eisvogel} -TITLE=${TITLE:-OWASP Mobile Application Security Verification Standard ${VERSION}} +TITLE=${TITLE:-OWASP Mobile Application Security Verification Standard ${MASVS_VERSION}} PANDOC_PARAMS=${PANDOC_PARAMS:-} PANDOC_PARAMS+="--resource-path=.:${FOLDER} " -PANDOC_PARAMS+="--metadata version=${VERSION} " +PANDOC_PARAMS+="--metadata masvs_version=${MASVS_VERSION} " + +# disable captions for images in pandoc +PANDOC_PARAMS+="-fmarkdown-implicit_figures" + + [ ! -z "${VERBOSE}" ] && PANDOC_PARAMS+="--verbose " PANDOCKER="docker run --rm --volume `pwd`:/pandoc ${IMG}:${TAG} ${PANDOC_PARAMS}" # remove the HTML comment from \pagebreak -docker run --rm --entrypoint '/bin/sh' --volume `pwd`:/pandoc ${IMG}:${TAG} -c 'sed -i "s##\1#g" Document/*.md' +docker run --rm --entrypoint '/bin/sh' --volume `pwd`:/pandoc ${IMG}:${TAG} -c "sed -i 's##\1#g' ${FOLDER}/[0-9][0-9]-*.md" + +# convert HTML images to pandoc markdown images +docker run --rm --entrypoint '/bin/sh' --volume `pwd`:/pandoc ${IMG}:${TAG} -c "sed -i -f tools/docker/imagereplace.sed ${FOLDER}/[0-9][0-9]-*.md" # Use pandocker PANDOCKER by default, unless `export PANDOC=pandoc` # this is useful for CI, because we can run the script directly inside the container PANDOC=${PANDOC:-${PANDOCKER}} -if [ ${FOLDER} == "Document" ]; then - LANGUAGE='en' -else - LANGUAGE=$(echo ${FOLDER} | cut -d '-' -f 2) -fi - -METADATA="Document/metadata.md ${FOLDER}/metadata.md" -CHAPTERS="${FOLDER}/0x*.md ${FOLDER}/CHANGELOG.md" -OUTPUT_BASE_NAME="OWASP_MASVS-${VERSION}-${LANGUAGE}" +METADATA="${FOLDER}/metadata.md" +# Note: chapters for MASVS categories are generated by tools/generate_masvs_md.py using masvs.yaml +CHAPTERS="${FOLDER}/[0-9][0-9]-*.md" +OUTPUT_BASE_NAME="OWASP_MASVS" [ ! -z "${VERBOSE}" ] && echo "Create PDF" @@ -74,29 +77,11 @@ ${PANDOC} \ # EPUB ${PANDOC} \ --metadata title="${TITLE}" \ - --metadata author="Bernhard Mueller, Sven Schleier, Jeroen Willemsen, and Carlos Holguera" \ - --epub-cover-image=cover.jpg \ + --metadata author="Bernhard Mueller, Sven Schleier, Jeroen Willemsen, Carlos Holguera and Jeroen Beckers" \ + --epub-cover-image=cover.png \ -o ${OUTPUT_BASE_NAME}.epub \ ${METADATA} \ ${CHAPTERS} -# MOBI -# kindlegen is deprecated -#kindlegen ${OUTPUT_BASE_NAME}.epub - -# DOCX -${PANDOC} \ - --metadata title="${TITLE}" \ - --toc \ - --number-sections \ - --columns 10000 \ - --self-contained \ - --standalone \ - --reference-doc tools/custom-reference.docx \ - -o ${OUTPUT_BASE_NAME}_WIP_.docx \ - ${METADATA} \ - ${CHAPTERS} - - # clean temp files rm -f tmp_latex-header.latex tmp_cover.latex tmp_first_page.latex diff --git a/tools/export.py b/tools/export.py deleted file mode 100755 index ea765e1f3..000000000 --- a/tools/export.py +++ /dev/null @@ -1,49 +0,0 @@ -#!/usr/bin/env python - -''' Tool for converting the MASVS requirements to various formats. - - Usage: ./export.py [--format ] [--lang ] - - By Bernhard Mueller, updated by Jeroen Beckers and Carlos Holguera - - Copyright (c) OWASP Foundation - - Permission is hereby granted, free of charge, to any person obtaining a copy - of this software and associated documentation files (the "Software"), to deal - in the Software without restriction, including without limitation the rights - to use, copy, modify, merge, publish, distribute, sublicense, and/or sell - copies of the Software, and to permit persons to whom the Software is - furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice shall be included in all - copies or substantial portions of the Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, - OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - SOFTWARE. - - ''' - -import argparse -from masvs import MASVS - -parser = argparse.ArgumentParser(description='Export the MASVS requirements. Default language is en.') -parser.add_argument('-f', '--format', choices=['json', 'xml', 'csv', 'yaml'], required=True) -parser.add_argument('-l', '--lang', default='en') - -args = parser.parse_args() - -m = MASVS(args.lang) - -if args.format == "csv": - print(m.to_csv()) -elif args.format == "xml": - print(m.to_xml()) -elif args.format == "json": - print(m.to_json()) -else: - print(m.to_yaml()) diff --git a/tools/generate-csv.py b/tools/generate-csv.py deleted file mode 100755 index 82413fcb1..000000000 --- a/tools/generate-csv.py +++ /dev/null @@ -1,44 +0,0 @@ -#!/usr/bin/python - -""" Quick and Dirty Roberto Martelloni's script to generate a CSV """ - -import os - - -def fromFilenameToArea(filename): - splittedFilename = filename.split("-") - id = splittedFilename[1] - name = splittedFilename[2].split(".") - name = name[0].replace("_", " ") - - return id, name - - - -def parsemd(filename): - - for line in open(filename): - if line.startswith("|"): - if line.find("| --- |") == 0: continue - if line.find("| # |") == 0: continue - if line.find("| #") == 0: continue - - start = fromFilenameToArea(filename) - line = line.replace("*", "") - line = line.split("|") - print start[0] + "|", - print start[1] + "|", - print line[1] + "|", - print line[2] + "|", - print line[3] + "|", - print line[4] + "|" - - -def main(): - for file in os.listdir("./Document"): - if file.find("-V") != -1: - parsemd("./Document/" + file) - - -if __name__ == '__main__': - main() diff --git a/tools/generate_masvs_yaml.py b/tools/generate_masvs_yaml.py new file mode 100644 index 000000000..98fc048ed --- /dev/null +++ b/tools/generate_masvs_yaml.py @@ -0,0 +1,80 @@ +import os +import yaml +import re +import argparse + +masvs = { + "metadata": { + "title": "Mobile Application Security Verification Standard (MASVS)", + "remarks": "The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security. It can be used by mobile software architects and developers seeking to develop secure mobile apps, as well as security testers to ensure completeness and consistency of test results." + }, + "groups": [] +} + +MASVS_VERSION = "" + +def read_md_sections(input_text): + + sections_dict = {} + + sections = re.split(r'^##\s(.+)', input_text, flags=re.MULTILINE) + sections.pop(0) # Remove the initial empty string + + # Loop over the sections and write each one to a separate file + for i in range(0, len(sections), 2): + section_title = sections[i].strip() + section_content = sections[i+1].strip() + + if section_title == "Control": + sections_dict["statement"] = section_content + elif section_title == "Description": + sections_dict["description"] = section_content + + return sections_dict + +def get_masvs_dict(): + index = 1 + + for file in sorted(os.listdir("Document")): + if "-MASVS-" in file: + with open(os.path.join("Document", file), "r") as f: + header = f.readline().replace("# ", "").strip() + description = f.read() + category_id = header.split(":")[0].strip() + title = header.split(":")[1].strip() + group = { + "id": category_id, + "index": index, + "title": title, + "description": description, + "controls": [] + } + + for control_file in os.listdir("controls"): + if control_file.startswith(category_id): + with open(os.path.join("controls", control_file), "r") as cf: + control_id = cf.readline().replace("# ", "").strip() + control_content = cf.read() + control_sections = read_md_sections(control_content) + control = {"id": control_id} | control_sections + group["controls"].append(control) + group["controls"] = sorted(group["controls"], key=lambda k: k["id"]) + masvs["groups"].append(group) + index += 1 + # sort masvs dict by index + masvs["groups"] = sorted(masvs["groups"], key=lambda k: k["index"]) + + masvs["metadata"]["version"] = MASVS_VERSION + return masvs + +# get input arguments +parser = argparse.ArgumentParser() +parser.add_argument("-v", "--version", help="MASVS version", required=False, default="vx.x.x") +args = parser.parse_args() + +MASVS_VERSION = args.version + +masvs = get_masvs_dict() + +with open("masvs.yaml", "w") as f: + yaml.dump(masvs, f, default_flow_style=False, sort_keys=False, allow_unicode=True, width=float("inf")) diff --git a/tools/masvs.py b/tools/masvs.py deleted file mode 100644 index e3e2c0690..000000000 --- a/tools/masvs.py +++ /dev/null @@ -1,115 +0,0 @@ -#!/usr/bin/env python - -''' MASVS document parser and converter class. - - By Bernhard Mueller, updated by Jeroen Beckers and Carlos Holguera - - Copyright (c) OWASP Foundation - - Permission is hereby granted, free of charge, to any person obtaining a copy - of this software and associated documentation files (the "Software"), to deal - in the Software without restriction, including without limitation the rights - to use, copy, modify, merge, publish, distribute, sublicense, and/or sell - copies of the Software, and to permit persons to whom the Software is - furnished to do so, subject to the following conditions: - - The above copyright notice and this permission notice shall be included in all - copies or substantial portions of the Software. - - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE - AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, - OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE - SOFTWARE. - - ''' - -import os -import re -import json -import yaml -from xml.sax.saxutils import escape -import csv -from pathlib import Path - -try: - from StringIO import StringIO -except ImportError: - from io import StringIO - -def order_filenames(target): - if Path(target).exists(): - keys = [f"-V{k}-" for k in range(1,9)] - l = [file.name for file in Path(target).glob("0x*-V*.md")] - ret_l = [] - for k in keys: - for name in l: - if k in name: - ret_l.append(name) - return ret_l - raise Exception(f"The provided path ({target}) does not exist. Does the corresponding language supported in the MASVS?") - -class MASVS: - ''' Creates requirements list out of markdown files. ''' - requirements = {} - - def __init__(self, lang): - - if lang == "en": - target = "../Document" - else: - target = "../Document-{}".format(lang) - - for file in order_filenames(target): - for line in open(os.path.join(target, file)): - regex = re.compile(r'\*\*(\d\.\d+)\*\*\s\|\s{0,1}(.*?)\s{0,1}\|\s{0,1}(.*?)\s{0,1}\|\s{0,1}(.*?)\s{0,1}\|(\s{0,1}(.*?)\s{0,1}\|)?') - m = re.search(regex, line) - - if m: - req = {} - num_id = m.group(1).strip() - mstg_id = m.group(2).replace(u"\u2011", "-") - req['id'] = num_id - req['category'] = mstg_id - req['text'] = m.group(3).strip() - if m.group(5): - req['L1'] = len(m.group(4).strip()) > 0 - req['L2'] = len(m.group(5).strip()) > 0 - req['R'] = False - else: - req['R'] = True - req['L1'] = False - req['L2'] = False - - self.requirements[mstg_id] = req - - def to_json(self): - ''' Returns a JSON-formatted string ''' - return json.dumps(self.requirements) - - def to_yaml(self): - ''' Returns a YAML-formatted string ''' - return yaml.dump(self.requirements, allow_unicode=True, indent=4, default_flow_style=False, sort_keys=False) - - def to_xml(self): - ''' Returns XML ''' - xml = '\n' - - for id, r in self.requirements.items(): - xml += f"\t\n\t\t{escape(r['text'])}\n\t\n" - - xml += '' - return xml - - def to_csv(self): - ''' Returns CSV ''' - si = StringIO() - - writer = csv.DictWriter(si, ['id', 'category', 'text', 'L1', 'L2', 'R'], extrasaction='ignore') - writer.writeheader() - rows = [r for id, r in self.requirements.items()] - writer.writerows(rows) - - return si.getvalue() diff --git a/tools/owasp_logo_mobile.xcf b/tools/owasp_logo_mobile.xcf deleted file mode 100644 index 504262ecf..000000000 Binary files a/tools/owasp_logo_mobile.xcf and /dev/null differ diff --git a/tools/populate_masvs_categories_md.py b/tools/populate_masvs_categories_md.py new file mode 100644 index 000000000..74344268a --- /dev/null +++ b/tools/populate_masvs_categories_md.py @@ -0,0 +1,61 @@ +import os +import yaml +import argparse + +def write_controls_content(control, cf): + h1 = '##' + h2 = '###' + final_newline = '\n' + + cf.write(f'{h1} {control["id"]}\n\n') + cf.write(f'{h2} Control\n\n') + cf.write(f'{control["statement"]}\n\n') + cf.write(f'{h2} Description\n\n') + cf.write(f'{control["description"]}\n{final_newline}') + + +def yaml_to_md(input_file, for_website): + + with open(input_file, 'r') as f: + data = yaml.safe_load(f) + + for group in data['groups']: + group_id = group['id'] + controls = group['controls'] + + for file in sorted(os.listdir("Document")): + if "-MASVS-" in file: + # group_id_in_file is the part of the filename after the first dash and without the extension + group_id_in_file = file.split("-")[1] + "-" + file.split("-")[2].split(".")[0] + + if group_id_in_file == group_id: + with open(os.path.join("Document", file), "a") as f: + f.write('\n') + f.write('| ID | Control |\n') + f.write('|----|-----------|\n') + for control in controls: + if for_website == True: + control_id = f'[{control["id"]}](controls/{control["id"]})' + else: + control_id = control["id"] + + f.write(f'| {control_id} | {control["statement"]} |\n') + + f.write('\n') + f.write('\n\n') + + if for_website == False: + for control in controls: + write_controls_content(control, f) + print(f'Successfully wrote to {file}') + +# get input arguments +parser = argparse.ArgumentParser() +parser.add_argument("-i", "--input", help="Input file", required=False, default="masvs.yaml") +parser.add_argument("-w", "--website", help="Generate for website", action='store_true', required=False, default=False) +args = parser.parse_args() + +input_file = args.input +for_website = args.website + +yaml_to_md(input_file, for_website) diff --git a/tools/template.tex b/tools/template.tex deleted file mode 100644 index c9fcb5f0d..000000000 --- a/tools/template.tex +++ /dev/null @@ -1,1014 +0,0 @@ -%% -% Copyright (c) 2017 - 2019, Pascal Wagler; -% Copyright (c) 2014 - 2019, John MacFarlane -% -% All rights reserved. -% -% Redistribution and use in source and binary forms, with or without -% modification, are permitted provided that the following conditions -% are met: -% -% - Redistributions of source code must retain the above copyright -% notice, this list of conditions and the following disclaimer. -% -% - Redistributions in binary form must reproduce the above copyright -% notice, this list of conditions and the following disclaimer in the -% documentation and/or other materials provided with the distribution. -% -% - Neither the name of John MacFarlane nor the names of other -% contributors may be used to endorse or promote products derived -% from this software without specific prior written permission. -% -% THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -% "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -% LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS -% FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE -% COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, -% INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, -% BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; -% LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER -% CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN -% ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -% POSSIBILITY OF SUCH DAMAGE. -%% - -%% -% This is the Eisvogel pandoc LaTeX template. -% -% For usage information and examples visit the official GitHub page: -% https://github.com/Wandmalfarbe/pandoc-latex-template -%% - -% Options for packages loaded elsewhere -\PassOptionsToPackage{unicode$for(hyperrefoptions)$,$hyperrefoptions$$endfor$}{hyperref} -\PassOptionsToPackage{hyphens}{url} -\PassOptionsToPackage{dvipsnames,svgnames*,x11names*,table}{xcolor} -$if(dir)$ -$if(latex-dir-rtl)$ -\PassOptionsToPackage{RTLdocument}{bidi} -$endif$ -$endif$ -% -\documentclass[ -$if(fontsize)$ - $fontsize$, -$endif$ -$if(lang)$ - $babel-lang$, -$endif$ -$if(papersize)$ - $papersize$paper, -$else$ - a4paper, -$endif$ -$if(beamer)$ - ignorenonframetext, -$if(handout)$ - handout, -$endif$ -$if(aspectratio)$ - aspectratio=$aspectratio$, -$endif$ -$endif$ -$for(classoption)$ - $classoption$$sep$, -$endfor$ -,tablecaptionabove -]{$if(beamer)$$documentclass$$else$$if(book)$scrbook$else$scrartcl$endif$$endif$} -$if(beamer)$ -$if(background-image)$ -\usebackgroundtemplate{% - \includegraphics[width=\paperwidth]{$background-image$}% -} -$endif$ -\usepackage{pgfpages} -\setbeamertemplate{caption}[numbered] -\setbeamertemplate{caption label separator}{: } -\setbeamercolor{caption name}{fg=normal text.fg} -\beamertemplatenavigationsymbols$if(navigation)$$navigation$$else$empty$endif$ -$for(beameroption)$ -\setbeameroption{$beameroption$} -$endfor$ -% Prevent slide breaks in the middle of a paragraph -\widowpenalties 1 10000 -\raggedbottom -$if(section-titles)$ -\setbeamertemplate{part page}{ - \centering - \begin{beamercolorbox}[sep=16pt,center]{part title} - \usebeamerfont{part title}\insertpart\par - \end{beamercolorbox} -} -\setbeamertemplate{section page}{ - \centering - \begin{beamercolorbox}[sep=12pt,center]{part title} - \usebeamerfont{section title}\insertsection\par - \end{beamercolorbox} -} -\setbeamertemplate{subsection page}{ - \centering - \begin{beamercolorbox}[sep=8pt,center]{part title} - \usebeamerfont{subsection title}\insertsubsection\par - \end{beamercolorbox} -} -\AtBeginPart{ - \frame{\partpage} -} -\AtBeginSection{ - \ifbibliography - \else - \frame{\sectionpage} - \fi -} -\AtBeginSubsection{ - \frame{\subsectionpage} -} -$endif$ -$endif$ -$if(beamerarticle)$ -\usepackage{beamerarticle} % needs to be loaded first -$endif$ -$if(fontfamily)$ -\usepackage[$for(fontfamilyoptions)$$fontfamilyoptions$$sep$,$endfor$]{$fontfamily$} -$else$ -\usepackage{lmodern} -$endif$ -$if(linestretch)$ -\usepackage{setspace} -\setstretch{$linestretch$} -$else$ -\usepackage{setspace} -\setstretch{1.2} -$endif$ -\usepackage{amssymb,amsmath} -\usepackage{ifxetex,ifluatex} -\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex - \usepackage[$if(fontenc)$$fontenc$$else$T1$endif$]{fontenc} - \usepackage[utf8]{inputenc} - \usepackage{textcomp} % provide euro and other symbols -\else % if luatex or xetex -$if(mathspec)$ - \ifxetex - \usepackage{mathspec} - \else - \usepackage{unicode-math} - \fi -$else$ - \usepackage{unicode-math} -$endif$ - \defaultfontfeatures{Scale=MatchLowercase} - \defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1} -$if(mainfont)$ - \setmainfont[$for(mainfontoptions)$$mainfontoptions$$sep$,$endfor$]{$mainfont$} -$endif$ -$if(sansfont)$ - \setsansfont[$for(sansfontoptions)$$sansfontoptions$$sep$,$endfor$]{$sansfont$} -$endif$ -$if(monofont)$ - \setmonofont[$for(monofontoptions)$$monofontoptions$$sep$,$endfor$]{$monofont$} -$endif$ -$for(fontfamilies)$ - \newfontfamily{$fontfamilies.name$}[$for(fontfamilies.options)$$fontfamilies.options$$sep$,$endfor$]{$fontfamilies.font$} -$endfor$ -$if(mathfont)$ -$if(mathspec)$ - \ifxetex - \setmathfont(Digits,Latin,Greek)[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} - \else - \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} - \fi -$else$ - \setmathfont[$for(mathfontoptions)$$mathfontoptions$$sep$,$endfor$]{$mathfont$} -$endif$ -$endif$ -$if(CJKmainfont)$ - \ifxetex - \usepackage{xeCJK} - \setCJKmainfont[$for(CJKoptions)$$CJKoptions$$sep$,$endfor$]{$CJKmainfont$} - \fi -$endif$ -$if(luatexjapresetoptions)$ - \ifluatex - \usepackage[$for(luatexjapresetoptions)$$luatexjapresetoptions$$sep$,$endfor$]{luatexja-preset} - \fi -$endif$ -$if(CJKmainfont)$ - \ifluatex - \usepackage[$for(luatexjafontspecoptions)$$luatexjafontspecoptions$$sep$,$endfor$]{luatexja-fontspec} - \setmainjfont[$for(CJKoptions)$$CJKoptions$$sep$,$endfor$]{$CJKmainfont$} - \fi -$endif$ -\fi -$if(beamer)$ -$if(theme)$ -\usetheme[$for(themeoptions)$$themeoptions$$sep$,$endfor$]{$theme$} -$endif$ -$if(colortheme)$ -\usecolortheme{$colortheme$} -$endif$ -$if(fonttheme)$ -\usefonttheme{$fonttheme$} -$endif$ -$if(mainfont)$ -\usefonttheme{serif} % use mainfont rather than sansfont for slide text -$endif$ -$if(innertheme)$ -\useinnertheme{$innertheme$} -$endif$ -$if(outertheme)$ -\useoutertheme{$outertheme$} -$endif$ -$endif$ -% Use upquote if available, for straight quotes in verbatim environments -\IfFileExists{upquote.sty}{\usepackage{upquote}}{} -\IfFileExists{microtype.sty}{% use microtype if available - \usepackage[$for(microtypeoptions)$$microtypeoptions$$sep$,$endfor$]{microtype} - \UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts -}{} -$if(indent)$ -$else$ -\makeatletter -\@ifundefined{KOMAClassName}{% if non-KOMA class - \IfFileExists{parskip.sty}{% - \usepackage{parskip} - }{% else - \setlength{\parindent}{0pt} - \setlength{\parskip}{6pt plus 2pt minus 1pt}} -}{% if KOMA class - \KOMAoptions{parskip=half}} -\makeatother -$endif$ -$if(verbatim-in-note)$ -\usepackage{fancyvrb} -$endif$ -\usepackage{xcolor} -\definecolor{default-linkcolor}{HTML}{A50000} -\definecolor{default-filecolor}{HTML}{A50000} -\definecolor{default-citecolor}{HTML}{4077C0} -\definecolor{default-urlcolor}{HTML}{4077C0} -\IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available -$if(footnotes-pretty)$ -% load footmisc in order to customize footnotes (footmisc has to be loaded before hyperref, cf. https://tex.stackexchange.com/a/169124/144087) -\usepackage[hang,flushmargin,bottom,multiple]{footmisc} -\setlength{\footnotemargin}{0.8em} % set space between footnote nr and text -\setlength{\footnotesep}{\baselineskip} % set space between multiple footnotes -\setlength{\skip\footins}{0.3cm} % set space between page content and footnote -\setlength{\footskip}{0.9cm} % set space between footnote and page bottom -$endif$ -\IfFileExists{bookmark.sty}{\usepackage{bookmark}}{\usepackage{hyperref}} -\hypersetup{ -$if(title-meta)$ - pdftitle={$title-meta$}, -$endif$ -$if(author-meta)$ - pdfauthor={$author-meta$}, -$endif$ -$if(lang)$ - pdflang={$lang$}, -$endif$ -$if(subject)$ - pdfsubject={$subject$}, -$endif$ -$if(keywords)$ - pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$}, -$endif$ -$if(colorlinks)$ - colorlinks=true, - linkcolor=$if(linkcolor)$$linkcolor$$else$default-linkcolor$endif$, - filecolor=$if(filecolor)$$filecolor$$else$default-filecolor$endif$, - citecolor=$if(citecolor)$$citecolor$$else$default-citecolor$endif$, - urlcolor=$if(urlcolor)$$urlcolor$$else$default-urlcolor$endif$, -$else$ - hidelinks, -$endif$ - breaklinks=true, - pdfcreator={LaTeX via pandoc with the Eisvogel template}} -\urlstyle{same} % disable monospaced font for URLs -$if(verbatim-in-note)$ -\VerbatimFootnotes % allow verbatim text in footnotes -$endif$ -$if(geometry)$ -$if(beamer)$ -\geometry{margin=2.5cm,includehead=true,includefoot=true,centering,$for(geometry)$$geometry$$sep$,$endfor$} -$else$ -\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering,$for(geometry)$$geometry$$sep$,$endfor$]{geometry} -$endif$ -$endif$ -$if(logo)$ -\usepackage[export]{adjustbox} -\usepackage{graphicx} -$endif$ -$if(beamer)$ -\newif\ifbibliography -$endif$ -$if(listings)$ -\usepackage{listings} -\newcommand{\passthrough}[1]{#1} -\lstset{defaultdialect=[5.3]Lua} -\lstset{defaultdialect=[x86masm]Assembler} -$endif$ -$if(listings-no-page-break)$ -\usepackage{etoolbox} -\BeforeBeginEnvironment{lstlisting}{\par\noindent\begin{minipage}{\linewidth}} -\AfterEndEnvironment{lstlisting}{\end{minipage}\par\addvspace{\topskip}} -$endif$ -$if(lhs)$ -\lstnewenvironment{code}{\lstset{language=Haskell,basicstyle=\small\ttfamily}}{} -$endif$ -$if(highlighting-macros)$ -$highlighting-macros$ - -% Workaround/bugfix from jannick0. -% See https://github.com/jgm/pandoc/issues/4302#issuecomment-360669013) -% or https://github.com/Wandmalfarbe/pandoc-latex-template/issues/2 -% -% Redefine the verbatim environment 'Highlighting' to break long lines (with -% the help of fvextra). Redefinition is necessary because it is unlikely that -% pandoc includes fvextra in the default template. -\usepackage{fvextra} -\DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines,fontsize=$if(code-block-font-size)$$code-block-font-size$$else$\small$endif$,commandchars=\\\{\}} - -$endif$ -$if(tables)$ -\usepackage{longtable,booktabs} -$if(beamer)$ -\usepackage{caption} -% Make caption package work with longtable -\makeatletter -\def\fnum@table{\tablename~\thetable} -\makeatother -$else$ -% Correct order of tables after \paragraph or \subparagraph -\usepackage{etoolbox} -\makeatletter -\patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{} -\makeatother -% Allow footnotes in longtable head/foot -\IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}} -\makesavenoteenv{longtable} -$endif$ -$endif$ -% add backlinks to footnote references, cf. https://tex.stackexchange.com/questions/302266/make-footnote-clickable-both-ways -$if(footnotes-disable-backlinks)$ -$else$ -\usepackage{footnotebackref} -$endif$ -$if(graphics)$ -\usepackage{graphicx,grffile} -\makeatletter -\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi} -\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi} -\makeatother -% Scale images if necessary, so that they will not overflow the page -% margins by default, and it is still possible to overwrite the defaults -% using explicit options in \includegraphics[width, height, ...]{} -\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio} -$endif$ -$if(links-as-notes)$ -% Make links footnotes instead of hotlinks: -\DeclareRobustCommand{\href}[2]{#2\footnote{\url{#1}}} -$endif$ -$if(strikeout)$ -\usepackage[normalem]{ulem} -% Avoid problems with \sout in headers with hyperref -\pdfstringdefDisableCommands{\renewcommand{\sout}{}} -$endif$ -\setlength{\emergencystretch}{3em} % prevent overfull lines -\providecommand{\tightlist}{% - \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}} -$if(numbersections)$ -\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$3$endif$} -$else$ -\setcounter{secnumdepth}{-\maxdimen} % remove section numbering -$endif$ -$if(beamer)$ -$else$ -$if(block-headings)$ -% Make \paragraph and \subparagraph free-standing -\ifx\paragraph\undefined\else - \let\oldparagraph\paragraph - \renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}} -\fi -\ifx\subparagraph\undefined\else - \let\oldsubparagraph\subparagraph - \renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}} -\fi -$endif$ -$endif$ -$if(pagestyle)$ -\pagestyle{$pagestyle$} -$endif$ - -% Make use of float-package and set default placement for figures to H. -% The option H means 'PUT IT HERE' (as opposed to the standard h option which means 'You may put it here if you like'). -\usepackage{float} -\floatplacement{figure}{$if(float-placement-figure)$$float-placement-figure$$else$H$endif$} - -$for(header-includes)$ -$header-includes$ -$endfor$ -$if(lang)$ -\ifxetex - $if(mainfont)$ - $else$ - % See issue https://github.com/reutenauer/polyglossia/issues/127 - \renewcommand*\familydefault{\sfdefault} - $endif$ - % Load polyglossia as late as possible: uses bidi with RTL langages (e.g. Hebrew, Arabic) - \usepackage{polyglossia} - \setmainlanguage[$polyglossia-lang.options$]{$polyglossia-lang.name$} -$for(polyglossia-otherlangs)$ - \setotherlanguage[$polyglossia-otherlangs.options$]{$polyglossia-otherlangs.name$} -$endfor$ -\else - \usepackage[shorthands=off,$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=$babel-lang$]{babel} -$if(babel-newcommands)$ - $babel-newcommands$ -$endif$ -\fi -$endif$ -$if(dir)$ -\ifxetex - % Load bidi as late as possible as it modifies e.g. graphicx - \usepackage{bidi} -\fi -\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex - \TeXXeTstate=1 - \newcommand{\RL}[1]{\beginR #1\endR} - \newcommand{\LR}[1]{\beginL #1\endL} - \newenvironment{RTL}{\beginR}{\endR} - \newenvironment{LTR}{\beginL}{\endL} -\fi -$endif$ -$if(natbib)$ -\usepackage[$natbiboptions$]{natbib} -\bibliographystyle{$if(biblio-style)$$biblio-style$$else$plainnat$endif$} -$endif$ -$if(biblatex)$ -\usepackage[$if(biblio-style)$style=$biblio-style$,$endif$$for(biblatexoptions)$$biblatexoptions$$sep$,$endfor$]{biblatex} -$for(bibliography)$ -\addbibresource{$bibliography$} -$endfor$ -$endif$ -$if(csl-refs)$ -\newlength{\cslhangindent} -\setlength{\cslhangindent}{1.5em} -\newenvironment{cslreferences}% - {$if(csl-hanging-indent)$\setlength{\parindent}{0pt}% - \everypar{\setlength{\hangindent}{\cslhangindent}}\ignorespaces$endif$}% - {\par} -$endif$ - -$if(title)$ -\title{$title$$if(thanks)$\thanks{$thanks$}$endif$} -$endif$ -$if(subtitle)$ -$if(beamer)$ -$else$ -\usepackage{etoolbox} -\makeatletter -\providecommand{\subtitle}[1]{% add subtitle to \maketitle - \apptocmd{\@title}{\par {\large #1 \par}}{}{} -} -\makeatother -$endif$ -\subtitle{$subtitle$} -$endif$ -$if(author)$ -\author{$for(author)$$author$$sep$ \and $endfor$} -$endif$ -\date{$date$} -$if(beamer)$ -$if(institute)$ -\institute{$for(institute)$$institute$$sep$ \and $endfor$} -$endif$ -$if(titlegraphic)$ -\titlegraphic{\includegraphics{$titlegraphic$}} -$endif$ -$if(logo)$ -\logo{\includegraphics{$logo$}} -$endif$ -$endif$ - - - -%% -%% added -%% - -% -% language specification -% -% If no language is specified, use English as the default main document language. -% -$if(lang)$$else$ -\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex - \usepackage[shorthands=off,$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=english]{babel} -$if(babel-newcommands)$ - $babel-newcommands$ -$endif$ -\else - $if(mainfont)$ - $else$ - % Workaround for bug in Polyglossia that breaks `\familydefault` when `\setmainlanguage` is used. - % See https://github.com/Wandmalfarbe/pandoc-latex-template/issues/8 - % See https://github.com/reutenauer/polyglossia/issues/186 - % See https://github.com/reutenauer/polyglossia/issues/127 - \renewcommand*\familydefault{\sfdefault} - $endif$ - % load polyglossia as late as possible as it *could* call bidi if RTL lang (e.g. Hebrew or Arabic) - \usepackage{polyglossia} - \setmainlanguage[]{english} -$for(polyglossia-otherlangs)$ - \setotherlanguage[$polyglossia-otherlangs.options$]{$polyglossia-otherlangs.name$} -$endfor$ -\fi -$endif$ - -% -% for the background color of the title page -% -$if(titlepage)$ -\usepackage{pagecolor} -\usepackage{afterpage} -$if(titlepage-background)$ -\usepackage{tikz} -$endif$ -$if(geometry)$ -$else$ -\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering]{geometry} -$endif$ -$endif$ - -% -% break urls -% -\PassOptionsToPackage{hyphens}{url} - -% -% When using babel or polyglossia with biblatex, loading csquotes is recommended -% to ensure that quoted texts are typeset according to the rules of your main language. -% -\usepackage{csquotes} - -% -% captions -% -\definecolor{caption-color}{HTML}{777777} -$if(beamer)$ -$else$ -\usepackage[font={stretch=1.2}, textfont={color=caption-color}, position=top, skip=4mm, labelfont=bf, singlelinecheck=false, justification=$if(caption-justification)$$caption-justification$$else$raggedright$endif$]{caption} -\setcapindent{0em} -$endif$ - -% -% blockquote -% -\definecolor{blockquote-border}{RGB}{221,221,221} -\definecolor{blockquote-text}{RGB}{119,119,119} -\usepackage{mdframed} -\newmdenv[rightline=false,bottomline=false,topline=false,linewidth=3pt,linecolor=blockquote-border,skipabove=\parskip]{customblockquote} -\renewenvironment{quote}{\begin{customblockquote}\list{}{\rightmargin=0em\leftmargin=0em}% -\item\relax\color{blockquote-text}\ignorespaces}{\unskip\unskip\endlist\end{customblockquote}} - -% -% Source Sans Pro as the de­fault font fam­ily -% Source Code Pro for monospace text -% -% 'default' option sets the default -% font family to Source Sans Pro, not \sfdefault. -% -\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex - $if(fontfamily)$ - $else$ - \usepackage[default]{sourcesanspro} - \usepackage{sourcecodepro} - $endif$ -\else % if not pdftex - $if(mainfont)$ - $else$ - \usepackage[default]{sourcesanspro} - \usepackage{sourcecodepro} - - % XeLaTeX specific adjustments for straight quotes: https://tex.stackexchange.com/a/354887 - % This issue is already fixed (see https://github.com/silkeh/latex-sourcecodepro/pull/5) but the - % fix is still unreleased. - % TODO: Remove this workaround when the new version of sourcecodepro is released on CTAN. - \ifxetex - \makeatletter - \defaultfontfeatures[\ttfamily] - { Numbers = \sourcecodepro@figurestyle, - Scale = \SourceCodePro@scale, - Extension = .otf } - \setmonofont - [ UprightFont = *-\sourcecodepro@regstyle, - ItalicFont = *-\sourcecodepro@regstyle It, - BoldFont = *-\sourcecodepro@boldstyle, - BoldItalicFont = *-\sourcecodepro@boldstyle It ] - {SourceCodePro} - \makeatother - \fi - $endif$ -\fi - -% -% heading color -% -\definecolor{heading-color}{RGB}{40,40,40} -$if(beamer)$ -$else$ -\addtokomafont{section}{\color{heading-color}} -$endif$ -% When using the classes report, scrreprt, book, -% scrbook or memoir, uncomment the following line. -%\addtokomafont{chapter}{\color{heading-color}} - -% -% variables for title and author -% -$if(beamer)$ -$else$ -\usepackage{titling} -\title{$title$} -\author{$for(author)$$author$$sep$, $endfor$} -$endif$ - -% -% tables -% -$if(tables)$ - -\definecolor{table-row-color}{HTML}{F5F5F5} -\definecolor{table-rule-color}{HTML}{999999} - -%\arrayrulecolor{black!40} -\arrayrulecolor{table-rule-color} % color of \toprule, \midrule, \bottomrule -\setlength\heavyrulewidth{0.3ex} % thickness of \toprule, \bottomrule -\renewcommand{\arraystretch}{1.3} % spacing (padding) - -$if(table-use-row-colors)$ -% TODO: This doesn't work anymore. I don't know why. -% Reset rownum counter so that each table -% starts with the same row colors. -% https://tex.stackexchange.com/questions/170637/restarting-rowcolors -% -% Unfortunately the colored cells extend beyond the edge of the -% table because pandoc uses @-expressions (@{}) like so: -% -% \begin{longtable}[]{@{}ll@{}} -% \end{longtable} -% -% https://en.wikibooks.org/wiki/LaTeX/Tables#.40-expressions -\let\oldlongtable\longtable -\let\endoldlongtable\endlongtable -\renewenvironment{longtable}{ -\rowcolors{3}{}{table-row-color!100} % row color -\oldlongtable} { -\endoldlongtable -\global\rownum=0\relax} -$endif$ -$endif$ - -% -% remove paragraph indention -% -\setlength{\parindent}{0pt} -\setlength{\parskip}{6pt plus 2pt minus 1pt} -\setlength{\emergencystretch}{3em} % prevent overfull lines - -% -% -% Listings -% -% - -$if(listings)$ - -% -% general listing colors -% -\definecolor{listing-background}{HTML}{F7F7F7} -\definecolor{listing-rule}{HTML}{B3B2B3} -\definecolor{listing-numbers}{HTML}{B3B2B3} -\definecolor{listing-text-color}{HTML}{000000} -\definecolor{listing-keyword}{HTML}{435489} -\definecolor{listing-keyword-2}{HTML}{1284CA} % additional keywords -\definecolor{listing-keyword-3}{HTML}{9137CB} % additional keywords -\definecolor{listing-identifier}{HTML}{435489} -\definecolor{listing-string}{HTML}{00999A} -\definecolor{listing-comment}{HTML}{8E8E8E} - -\lstdefinestyle{eisvogel_listing_style}{ - language = java, -$if(listings-disable-line-numbers)$ - xleftmargin = 0.6em, - framexleftmargin = 0.4em, -$else$ - numbers = left, - xleftmargin = 2.7em, - framexleftmargin = 2.5em, -$endif$ - backgroundcolor = \color{listing-background}, - basicstyle = \color{listing-text-color}\linespread{1.0}$if(code-block-font-size)$$code-block-font-size$$else$\small$endif$\ttfamily{}, - breaklines = true, - frame = single, - framesep = 0.19em, - rulecolor = \color{listing-rule}, - frameround = ffff, - tabsize = 4, - numberstyle = \color{listing-numbers}, - aboveskip = 1.0em, - belowskip = 0.1em, - abovecaptionskip = 0em, - belowcaptionskip = 1.0em, - keywordstyle = {\color{listing-keyword}\bfseries}, - keywordstyle = {[2]\color{listing-keyword-2}\bfseries}, - keywordstyle = {[3]\color{listing-keyword-3}\bfseries\itshape}, - sensitive = true, - identifierstyle = \color{listing-identifier}, - commentstyle = \color{listing-comment}, - stringstyle = \color{listing-string}, - showstringspaces = false, - escapeinside = {/*@}{@*/}, % Allow LaTeX inside these special comments - literate = - {á}{{\'a}}1 {é}{{\'e}}1 {í}{{\'i}}1 {ó}{{\'o}}1 {ú}{{\'u}}1 - {Á}{{\'A}}1 {É}{{\'E}}1 {Í}{{\'I}}1 {Ó}{{\'O}}1 {Ú}{{\'U}}1 - {à}{{\`a}}1 {è}{{\'e}}1 {ì}{{\`i}}1 {ò}{{\`o}}1 {ù}{{\`u}}1 - {À}{{\`A}}1 {È}{{\'E}}1 {Ì}{{\`I}}1 {Ò}{{\`O}}1 {Ù}{{\`U}}1 - {ä}{{\"a}}1 {ë}{{\"e}}1 {ï}{{\"i}}1 {ö}{{\"o}}1 {ü}{{\"u}}1 - {Ä}{{\"A}}1 {Ë}{{\"E}}1 {Ï}{{\"I}}1 {Ö}{{\"O}}1 {Ü}{{\"U}}1 - {â}{{\^a}}1 {ê}{{\^e}}1 {î}{{\^i}}1 {ô}{{\^o}}1 {û}{{\^u}}1 - {Â}{{\^A}}1 {Ê}{{\^E}}1 {Î}{{\^I}}1 {Ô}{{\^O}}1 {Û}{{\^U}}1 - {œ}{{\oe}}1 {Œ}{{\OE}}1 {æ}{{\ae}}1 {Æ}{{\AE}}1 {ß}{{\ss}}1 - {ç}{{\c c}}1 {Ç}{{\c C}}1 {ø}{{\o}}1 {å}{{\r a}}1 {Å}{{\r A}}1 - {€}{{\EUR}}1 {£}{{\pounds}}1 {«}{{\guillemotleft}}1 - {»}{{\guillemotright}}1 {ñ}{{\~n}}1 {Ñ}{{\~N}}1 {¿}{{?`}}1 - {…}{{\ldots}}1 {≥}{{>=}}1 {≤}{{<=}}1 {„}{{\glqq}}1 {“}{{\grqq}}1 - {”}{{''}}1 -} -\lstset{style=eisvogel_listing_style} - -% -% Java (Java SE 12, 2019-06-22) -% -\lstdefinelanguage{Java}{ - morekeywords={ - % normal keywords (without data types) - abstract,assert,break,case,catch,class,continue,default, - do,else,enum,exports,extends,final,finally,for,if,implements, - import,instanceof,interface,module,native,new,package,private, - protected,public,requires,return,static,strictfp,super,switch, - synchronized,this,throw,throws,transient,try,volatile,while, - % var is an identifier - var - }, - morekeywords={[2] % data types - % primitive data types - boolean,byte,char,double,float,int,long,short, - % String - String, - % primitive wrapper types - Boolean,Byte,Character,Double,Float,Integer,Long,Short - % number types - Number,AtomicInteger,AtomicLong,BigDecimal,BigInteger,DoubleAccumulator,DoubleAdder,LongAccumulator,LongAdder,Short, - % other - Object,Void,void - }, - morekeywords={[3] % literals - % reserved words for literal values - null,true,false, - }, - sensitive, - morecomment = [l]//, - morecomment = [s]{/*}{*/}, - morecomment = [s]{/**}{*/}, - morestring = [b]", - morestring = [b]', -} - -\lstdefinelanguage{XML}{ - morestring = [b]", - moredelim = [s][\bfseries\color{listing-keyword}]{<}{\ }, - moredelim = [s][\bfseries\color{listing-keyword}]{}, - moredelim = [l][\bfseries\color{listing-keyword}]{/>}, - moredelim = [l][\bfseries\color{listing-keyword}]{>}, - morecomment = [s]{}, - morecomment = [s]{}, - commentstyle = \color{listing-comment}, - stringstyle = \color{listing-string}, - identifierstyle = \color{listing-identifier} -} -$endif$ - -% -% header and footer -% -$if(beamer)$ -$else$ -$if(disable-header-and-footer)$ -$else$ -\usepackage{fancyhdr} - -\fancypagestyle{eisvogel-header-footer}{ - \fancyhead{} - \fancyfoot{} - \lhead[$if(header-right)$$header-right$$else$$date$$endif$]{$if(header-left)$$header-left$$else$$title$$endif$} - \chead[$if(header-center)$$header-center$$else$$endif$]{$if(header-center)$$header-center$$else$$endif$} - \rhead[$if(header-left)$$header-left$$else$$title$$endif$]{$if(header-right)$$header-right$$else$$date$$endif$} - \lfoot[$if(footer-right)$$footer-right$$else$\thepage$endif$]{$if(footer-left)$$footer-left$$else$$for(author)$$author$$sep$, $endfor$$endif$} - \cfoot[$if(footer-center)$$footer-center$$else$$endif$]{$if(footer-center)$$footer-center$$else$$endif$} - \rfoot[$if(footer-left)$$footer-left$$else$$for(author)$$author$$sep$, $endfor$$endif$]{$if(footer-right)$$footer-right$$else$\thepage$endif$} - \renewcommand{\headrulewidth}{0.4pt} - \renewcommand{\footrulewidth}{0.4pt} -} -\pagestyle{eisvogel-header-footer} -$endif$ -$endif$ - -%% -%% end added -%% - -\begin{document} - -%% -%% begin titlepage -%% -$if(beamer)$ -$else$ -$if(titlepage)$ -\begin{titlepage} -$if(titlepage-background)$ -\newgeometry{top=2cm, right=4cm, bottom=3cm, left=4cm} -$else$ -\newgeometry{left=6cm} -$endif$ -$if(titlepage-color)$ -\definecolor{titlepage-color}{HTML}{$titlepage-color$} -\newpagecolor{titlepage-color}\afterpage{\restorepagecolor} -$endif$ -$if(titlepage-background)$ -\tikz[remember picture,overlay] \node[inner sep=0pt] at (current page.center){\includegraphics[width=\paperwidth,height=\paperheight]{$titlepage-background$}}; -$endif$ -\newcommand{\colorRule}[3][black]{\textcolor[HTML]{#1}{\rule{#2}{#3}}} -\begin{flushleft} -\noindent -\\[-1em] -\color[HTML]{$if(titlepage-text-color)$$titlepage-text-color$$else$5F5F5F$endif$} -\makebox[0pt][l]{\colorRule[$if(titlepage-rule-color)$$titlepage-rule-color$$else$435488$endif$]{1.3\textwidth}{$if(titlepage-rule-height)$$titlepage-rule-height$$else$4$endif$pt}} -\par -\noindent - -$if(titlepage-background)$ -% The titlepage with a background image has other text spacing and text size -{ - \setstretch{2} - \vfill - \vskip -8em - \noindent {\huge \textbf{\textsf{$title$}}} - $if(subtitle)$ - \vskip 1em - {\Large \textsf{$subtitle$}} - $endif$ - \vskip 2em - \noindent {\Large \textsf{$for(author)$$author$$sep$, $endfor$} \vskip 0.6em \textsf{$date$}} - \vfill -} -$else$ -{ - \setstretch{1.4} - \vfill - \noindent {\huge \textbf{\textsf{$title$}}} - $if(subtitle)$ - \vskip 1em - {\Large \textsf{$subtitle$}} - $endif$ - \vskip 2em - \noindent {\Large \textsf{$for(author)$$author$$sep$, $endfor$}} - \vfill -} -$endif$ - -$if(logo)$ -\noindent -\includegraphics[width=$if(logo-width)$$logo-width$$else$100$endif$pt, left]{$logo$} -$endif$ - -$if(titlepage-background)$ -$else$ -\textsf{$date$} -$endif$ -\end{flushleft} -\end{titlepage} -\restoregeometry -$endif$ -$endif$ - -%% -%% end titlepage -%% - -$if(has-frontmatter)$ -\frontmatter -$endif$ -$if(title)$ -$if(beamer)$ -\frame{\titlepage} -$endif$ -$if(abstract)$ -\begin{abstract} -$abstract$ -\end{abstract} -$endif$ -$endif$ - -$if(first-chapter)$ -\setcounter{chapter}{$first-chapter$} -\addtocounter{chapter}{-1} -$endif$ - -$for(include-before)$ -$include-before$ - -$endfor$ -$if(toc)$ -$if(toc-title)$ -\renewcommand*\contentsname{$toc-title$} -$endif$ -$if(beamer)$ -\begin{frame} -$if(toc-title)$ - \frametitle{$toc-title$} -$endif$ - \tableofcontents[hideallsubsections] -\end{frame} -$if(toc-own-page)$ -\newpage -$endif$ -$else$ -{ -$if(colorlinks)$ -\hypersetup{linkcolor=$if(toccolor)$$toccolor$$else$$endif$} -$endif$ -\setcounter{tocdepth}{$if(toc-depth)$$toc-depth$$else$3$endif$} -\tableofcontents -$if(toc-own-page)$ -\newpage -$endif$ -} -$endif$ -$endif$ -$if(lot)$ -\listoftables -$endif$ -$if(lof)$ -\listoffigures -$endif$ -$if(linestretch)$ -\setstretch{$linestretch$} -$endif$ -$if(has-frontmatter)$ -\mainmatter -$endif$ -$body$ - -$if(has-frontmatter)$ -\backmatter -$endif$ -$if(natbib)$ -$if(bibliography)$ -$if(biblio-title)$ -$if(has-chapters)$ -\renewcommand\bibname{$biblio-title$} -$else$ -\renewcommand\refname{$biblio-title$} -$endif$ -$endif$ -$if(beamer)$ -\begin{frame}[allowframebreaks]{$biblio-title$} - \bibliographytrue -$endif$ - \bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$} -$if(beamer)$ -\end{frame} -$endif$ - -$endif$ -$endif$ -$if(biblatex)$ -$if(beamer)$ -\begin{frame}[allowframebreaks]{$biblio-title$} - \bibliographytrue - \printbibliography[heading=none] -\end{frame} -$else$ -\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$ -$endif$ - -$endif$ -$for(include-after)$ -$include-after$ - -$endfor$ -\end{document} \ No newline at end of file